On Fri, Aug 26, 2022 at 11:54 AM Tommy Pauly <tpauly= 40apple....@dmarc.ietf.org> wrote:
> > > On Aug 26, 2022, at 4:29 AM, Ben Schwartz <bemasc= > 40google....@dmarc.ietf.org> wrote: > > > > > On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > >> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote: >> >> > 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. >> >> This is why my suggested client behaviour was cognisant of this >> impediment. >> >> - If the client's *initial* SVCB lookup succeeds, *then* fallback is >> no longer an option. >> >> - If initial SVCB resolution fails (SERVFAIL, timeout, ...) >> then the client behaves as though the SVCB record does not exist. >> >> This results in more predictable behaviour, without optimising for >> failure. > > > I don't think "more predictable" is really a desirable or achievable > outcome in this case. Sophisticated clients (e.g. web browsers for HTTP, > iterative resolvers for DNS) tend to develop highly tuned heuristics and > state machines in pursuit of performance and reliability within their > particular constraints. I think an instruction not to fall back in this > case would likely be ignored. > > > I definitely agree with all the points that Ben is making here and > elsewhere. The practical realities of dealing with new record types, and > the evolving heuristics on clients, will determine how the records are > used. > > It makes sense for informational documents to talk about techniques and > best practices—like an updated Happy Eyeballs algorithm to include SVCB > logic, but that shouldn’t block anything in the base specification or add > overly restrictive requirements today. > > Tommy > > I don't disagree with your comment about "overly restrictive requirements".. However, if you can take a look at one of my responses, I go into how/why *fallback is itself an overly restrictive requirement.* This draft, with fallback, asserts/requires that apex A/AAAA records, if they exist, MUST be used to serve the same service and content as the corresponding HTTPS record. This assertion/requirement is also exclusive of other potential SVCB-compatible apex records' potential requirement for their own fallback to A/AAAA records. Legacy support really needs to be stated as a "MAY", explicitly, and zone owners MUST be able to publish A/AAAA records used for other purposes (as indeed they may already be doing.) Legacy support is good, but cannot be a strict requirement for deployment of HTTPS, IMNSHO. (The current draft, with fallback, makes it a strict conditional requirement.) Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
