Erik Nygren <[email protected]> wrote:
> As the DNS is the primary mechanism for translating from hostnames to
> IP addresses, it is a logical place to signal that endpoints are
> IPv6-only. It is thus also a logical place to signal that legacy
> endpoints supporting IPv4 are being deprecated. This specification
> introduces two SvcParams for SVCB-compatible RR types that signal
> IPv6-only endpoints (ipv6only) as well as deprecated endpoints
> (deprecated).
>
> The "ipv6only" SvcParam touches on V6OPS and HAPPY. I see this not as
> something we desperately need now/yet but as something we will want in a few
> years and thus should standardize sooner so that the implementations are there
> for when we need it.
I have to admit that my experience so far with the
adoption of SVCB and HTTPS records makes me wonder
whether this will be a practically useful approach.
Right now, browsers[1] are racing all three lookups
(HTTPS, A, and AAAA), and any findings from HTTPS
records are, if supported or implemented by browsers
at all, advisory at best.
>From a browser (or happy eyeballs) perspective, that
makes sense: waiting for the HTTPS result before then
having to possibly do another two sequential lookups
leads to a bad user experience.
But that also means that the "ipv6only" param would
not be particularly useful in practice so long as
browsers still race the A and AAAA lookups. I
anticipate browsers will continue to do that for as
long as IPv4 and IPv6 records are both widely
used[2].
As for the "deprecated" param, I also don't quite know
what I am to do with it when I observe it, given that
I "SHOULD NOT provide special treatment".
I fear that the idea behind the proposal ("make it
easier for people to migrate off IPv4 and to
IPv6-only") is a solution in search of a problem: I'm
not convinced the technical ability to migrate is
hampered by the lack of a method to signal to clients
your intention; what's missing is the intention to
migrate.
As an entirely naive alternative, I would expect an
IPv6-only service to be one that has only AAAA records
(and includes ipv6hint params, but no ipv4hint params
in any SVCB records, which browsers may or may not
race at the same time).
Perhaps it would be useful to include in the draft a
brief description why that is insufficient and whether
the anticipation is that browsers will (eventually)
_not_ race HTTPS and A/AAAA lookups but _only_ use
HTTPS lookups (or use those as blocking prior to any
A/AAAA lookups).
Sorry, this got longer than I initially set out to.
-Jan
[1] And it really is browsers we have to care about
here, since those are effectively setting much of the
direction of the Web.
[2] Which, in turn, I anticipate to remain the case
throughout the rest of my lifetime, at least.
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
