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