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. The logic is simple: this draft does not make "HTTPS Record" support mandatory for HTTP clients. Thus, HTTP servers are still required to publish functional address records on the origin hostname, as usual. (Similar logic applies to any other pre-existing protocol that may be used with SVCB.) Since these records are required to be present and working, we can hardly forbid clients from using them. Relatedly, the results presented by EKR [1] at the most recent DNSOP meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS records through their local resolver. To me, this implies that functional origin endpoints are likely to be required even if client software gains SVCB/HTTPS support. Brian proposes a use case of serving only a warning message on the origin endpoint, in order to minimize the load on IP addresses that are likely hardcoded into a customer's zone. I understand the appeal of this configuration, but for the above reasons it is deliberately not supported in this draft. Instead, the draft attempts to ensure that deploying and implementing the HTTPS record "does no harm", by giving participating clients no worse reliability than legacy clients. (Also, Brian's analysis indicates that the origin hostname's address record TTL would bias the endpoint selection, but this is not correct.) I believe this balance could be revisited in several years' time, if "HTTPS Record" support becomes sufficiently universal. For example, post-deployment data from browsers may show that we could eliminate the final fallback without reducing reliability. For now, I think it's better to keep the current guidance, in order to minimize the risk of disruptions as these new RR types begin to be deployed. Viktor notes with concern that AliasMode is a "non-deterministic redirect". Instead, the draft attempts to model the client behavior as a preference ordered stack of endpoints: 1. Basic: the origin endpoint (status quo ante) 2. Better: the endpoint at the end of the AliasMode chain 3. Best: the ServiceMode records I think it's best to think of AliasMode as an alias that is optional when SVCB is optional, and mandatory when SVCB is mandatory. This seems natural enough to me, and allows it to be used in environments like the web where "fail fast" is not an appealing option. --Ben Schwartz
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
