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. If the origin zone directs the service elsewhere, and there
are no last-mile DNS lookup roadblocks, then the protocol becomes
"reliable" (optimises for success and predictability, over fallback
recovery leading to potentially/eventually undesirable outcomes).
> I believe this balance could be revisited in several years' time, if "HTTPS
> Record" support becomes sufficiently universal.
Indeed it is a possible position to say that the Internet is not yet
ready for semantically distinct services seen by SVCB-aware and legacy
clients. But I think that latching on success of the initial lookup
largely addresses the present impediments to reliance on SVCB.
> 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:
>
I also noted an issue around the initial $QNAME having prefix labels (in
the case of SVCB rather than HTTPS), and so this is likely not the name
you want appended as a fallback to the target list.
Similarly, if an AliasMode target has attrleaf labels, RFC1123 seems to
preclude publishing A/AAAA records there, making some of the example
configurations in the draft impractical.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
