On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz <bem...@google.com> wrote:
> Thanks to Brian, Viktor, and others for the very close review, as always. > While I disagree with many of the claims made here, it's clear that some of > the text has proven confusing. I'm not familiar with the process rules > given the draft's current state, but perhaps we can improve clarity with > some modest revisions. I'll try to keep that discussion separate. > > The key text for this discussion is in Section 3: > > If the client is SVCB-optional, and connecting using this list of > endpoints has failed, the client now attempts to use non-SVCB > connection modes. > > I believe most reviewers correctly understood this to mean that, if all > else fails, you can connect to https://www.example.com/ using the AAAA or > A records on www.example.com, as usual. > One of the problems here is that the term "connection mode" is somewhat ambiguous. Does that refer to the HTTP mode, or DNS queries? It could mean, "connect via HTTP using no SvcParameter" elements, i.e. connects using vanilla HTTPS, using the last $QNAME. It does not explicitly identify the connection target address. (e.g. if there was not a DNS resolution failure, the connection failure should be "hard" rather than "soft", and only the final $QNAME should be used, vs explicitly stating "non-SVCB connection to addresses found by resolving A/AAAA records at <specified location relative to $origin>"). > The logic is simple: this draft does not make "HTTPS Record" support > mandatory for HTTP clients. > What the current version of the draft does, is it asserts HTTP ownership of any apex A/AAAA records, something that was not the case prior to this draft. - The fallback logic assumes that A/AAAA address records MUST serve the same content as the HTTPS record - This effectively forces the owner to choose between "no A/AAAA record", or "have A/AAAA records that require maintenance (if the are the result of doing DNS resolution on the HTTPS target)", or "do some other thing that serves the same HTTP content". - This means that for as long as the current draft is published as-is, and until it is given a -bis treatment or is deprecated, no other use of apex A/AAAA records is possible (without impacting HTTPS-aware clients) - This also means no OTHER SVCB-compatible apex RRTYPE can be used that also requires fallback to A/AAAA records, as those would conflict with the HTTPS usage The "www" name under any given domain, is by convention the owner name of HTTP and HTTPS services, but is not strictly required. The expectation that "www" is a web server is reasonable, and that CNAME and AliasMode records would be interchangeable. Other (non-HTTPS) SVCB-compatible records would not be expected to co-exist at the "www" name. The same is not true for the apex name, recent trends to the contrary notwithstanding. > Thus, HTTP servers are still required to publish functional address > records on the origin hostname, as usual. > This is *only* true if the HTTPS record is added to a pre-existing address record's origin hostname. There is no requirement for a pre-existing address; it is possible (indeed likely) that a significant proportion of HTTPS records are published where no pre-existing address records existed. There might be a simultaneous deployment of A/AAAA records for the purposes of serving (some kind of content) to legacy clients, which is a distinct use case from the pre-existing same-content A/AAAA use case. > (Similar logic applies to any other pre-existing protocol that may be used > with SVCB.) > I don't follow this logic, could you explain, please? Suppose (at some future point) there are half a dozen SVCB-compatible RRTYPEs, all published at a zone apex. Which service (corresponding to which RRTYPE) is the pre-existing protocol served at the apex A/AAAA address(es)? There can be ONLY one protocol attached to an address, unless the address is forced to serve many protocols simultaneously (not an ideal situation at all). > Since these records are required to be present and working, we can hardly > forbid clients from using them. > Except, they aren't *required* to be present and working, at least not within the scope of this draft. What is true, is that IF they are present, they are *expected* (not required) to be working. (The logic is backwards; it is B->A, not A->B. Plus, the negation of X->Y is (!Y)->(!X), rather than (!X)->(!Y).) This pre-existence assumption omits an entirely different logic branch: green-field deployments using HTTPS (where no current records of any type existed, or existed for other services, including "parking" generic pages, "cash parking", etc.). GoDaddy provides managed DNS hosting (which in some cases involves add-on services that are provisioned into the customer's zone), for tens of millions of domains. A significant portion of those will be updated to use HTTPS in the near future, presuming what gets published will work correctly. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
