Hi,
I read draft-ietf-dnsop-svcb-httpssvc-01. Please find find some comments
(with my questions) below I had while reading linearly the document. I hope
this will help.
Yours,
Daniel
section 1.1
_8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net.
In my opinion, the mechanism that derives QNAME needs to be refined or maybe
the terminology being clarified.
a) The current document describes how to generate the QNAME from an URI. The
QNAME contains a port number while some scheme do not allow or specify port
subcomponent. Not having the port specified could be particularly useful to
provide secure transport for schemes that are not necessarily secure for
example. One the other hand, a scheme that specify a port, may not
necessarily
need to have it specified twined in the QNAME. I would be rather inclined to
have the port optional maybe at the expense of an additional RRset, but need
more thoughts.
b) It is also unclear to me why HTTPS:443 or HTTP:80 has a specific
convention.
The convention tales place for the DNS resolution of a authority as opposed
to
the DNS resolution of a FQDN. One possible reason I see could would be to
prevent having a distinction between http and https (which could be done
otherwise for example using alpn), but I am wondering if there are other
rationale. So far, I do not see the need for a exception for the derivation
of
the QNAME (nor for using a specific RRtype).
c) The current document, mentions several time HTTP service. The term
service
seems to me ambiguous as it has been defined for the DNS service based
discovery in which case it means a web page. It seems to me preferable we
keep
the scope of URI scheme and port authority. As a side note, when scheme is
thought as a service, the convention adopted by the document slightly
differs
from the DNS based service Discovery which would use _baz._udp or eventually
_baz._tcp. The current approach may be simpler. I would think this is
mostly a
terminology issue.
section 2.3
"""
Protocol mappings for SVCB MAY remove the port or replace it with
other protocol-specific information, but MUST retain the scheme in
the QNAME.
"""
I understand that for any scheme, a definition of how scheme and port
should be
defined when using SVBC. If that is correct, I would rather see that the
other
way around, that is SVBC defining from the scheme definition the QNAME
derivation. The term MAY also suggest different interpretation will be
permitted, which could affect interoperability.
"""
When a prior CNAME or SVCB record has aliased to an SVCB record, each
RR shall be returned under its own owner name.
"""
If I am not misinterpreting this, this seems to be the natural way CNAME
works
and I am wondering if the text should not be removed from this section. My
general comment is that the text refers too much to CNAME. Probably only the
fall back function of CNAME should be mentioned in the main text and other
considerations may be moved to the appendix to ease the reading. This is
obviously just a comment.
"""
As an example:
_8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.
svc4.example.net. 7200 IN SVCB 3 ( svc4.example.net. alpn="bar"
port="8004" esniconfig="..." )
"""
While many examples are useful for the understanding, they often provide the
impression RRsets are in the same zone file. I am wondering if that would
not
be clarifying to show and mention zone files are different. Note this is
just a
feed back and your ar efree to ignore it.
2.5. SVCB records: AliasForm
It seems strange to me to have a single RRset type associated to different
functionalities, i.e. Alias and Service. I suspect that it is more
convenient
to have the same RRtype while requesting among different administrative
domains, but I would be happy to know the rationals for this design. I have
the
impression that alias form is used to indicates the next RRtype (in our
case,
SVCB) while service form indicates a terminal request.
"""
The SvcDomainName MUST point to a domain name that contains another
SVCB record, address (AAAA and/or A) records, or both address records
and a ServiceForm SVCB record.
"""
I have some issue parsing the sentence with the AND and OR, but I also
suspect
that the first SVCB refers to an Alias form.
The sentence above could be read as the owner of api.example.com pointing to
svc4.example.net. need to check these conditions are met. I believe the
conditions need to be enforced by the owner of the SvcDomainName. The
confusion
may be due to the fact that SvcDomainName is both a key and an RDATA.
I have the impression "." or the owner domain MUST NOT be used, but I do not
see this being mentioned, though I see it later.
"""
The AliasForm's primary purpose is to allow aliasing at the zone
apex, where CNAME is not allowed. For example, if an operator of
https://example.com wanted to point HTTPS requests to a service
operating at svc.example.net, they would publish a record such as:
example.com. 3600 IN SVCB 0 svc.example.net.
"""
My understanding is that SVCB "solves" the apex issue by splitting the
query in
two parts with different RRtypes and a specific resolution. I have the
impression that SRV would have achieved this as well. I would suggest to
have
one annex section dedicated to this apex issue/discussion. The main reason
is
that it is recurrently being mentioned without really exposing the problem.
In
addition, I don't see this as the main motivation for SVCB.
"""
Note that the SVCB record's owner name MAY be the canonical name of a
CNAME record, and the SvcDomainName MAY be the owner of a CNAME
record. Clients and recursive resolvers MUST follow CNAMEs as
normal.
"""
I am not sure this is should be mentioned in the main part of the document
and
maybe annex would be more appropriated.
2.6.1. Special handling of "." for SvcDomainName in ServiceForm
"""
(The SvcDomainName of an SVCB RR in AliasForm MUST
NOT have this value.)
"""
It seems to me that section 2.5 is more adapted for this normative text.
This section is the first time HTTPSSVC is mentionned. My interpretation of
HTTPSSVC is that HTTPS is mentiond in the RRtype because that information is
not contained into the QNAME. My understanding is that using RRTypes was
discouraged though I might misinterpret 8556.
2.6.2. SvcFieldPriority
This field is also part of the AliasForm and a specific description may
also be
described in the aliasform as to specify how to handle SVCB RRsets with 0
and
non 0 SvcFieldPriority.
3. Client behavior
"""
1. Issue parallel AAAA/A and SVCB queries for the name HOST. The
answers for these may or may not include CNAME pointers before
reaching one or more of these records.
"""
While AAAA/A is well understood, I believe that AAAA and A is more
accurate.
I believe he sentence "The answers... is not necessary, but I made that
comment
earlier.
I have the impression that the behavior considers that either alias forms or
service form are returned, but not necessarily when both forms are returned.
Such scenario does not seems to me realistic for example to perform load
sharing/offload the traffic. It could also happen due to misconfiguration.
The
current text seems to state that as long as alias form are found,look for
the
alias form (transition from 2) to 3)). It probably end up in having all
different possibilities, but I am wondering if this is what we always want.
It
is likely that 2) and 3) can be processed in parallel.
"""
If the
connection fails, the client MAY try to connect using values from
a lower-priority record. If none of the options succeed, the
client SHOULD connect to the origin server directly.
"""
This seems to me more like an application policy rather than a DNS
resolution.
"""
Some important optimizations are discussed in Section 5 to avoid
additional latency in comparison to ordinary AAAA/A lookups.
"""
I think that reduced is more accurate than avoided as, if I understood
correctly, when an alias is returned most likely another request follows.
"""
When responding to a query that includes the DNSSEC OK bit
([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers
MUST accompany each RRSet in the Additional section with the same
DNSSEC-related records that it would send when providing that RRSet
as an Answer.
"""
This seems like the normal processing.
With DNSSEC and parameters that includes keys, it might happen that response
may be large and that the server may select some responses to put in the
additional data. Some selection algorithms could be provided and DNSSEC
protected RRsets should be given a preference - though this won't be the
only
criteria.
"""
If none of the SVCB records are consistent with any active or in-
progress connection, clients must proceed as described in Step 3 of
the procedure in Section 3.
"""
I think a normative MUST woudl be more accurate.
7. Using SVCB with HTTPS and HTTP
"""
Note that none of these forms alter the HTTPS origin or authority.
For example, clients MUST continue to validate TLS certificate
hostnames based on the origin host.
"""
Just to clarify for myself, the TLS certificate on svc4.example.net will use
example.com.
7.4. HTTP Strict Transport Security
I am wondering if that would be possible to make https the default scheme
and
considering http scheme as https with alpn set to null.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
