Re: [v6ops] New draft at dnsop a bis for DNS IPv6 Transport Operational Guidelines

[Havard Eidnes <[e-mail]>]

> Go read https://www.potaroo.net/ispcol/2023-11/dns-ipv6.html to
> get a clearer explanation of the issues here about the DNS, UDP
> and IPv6.

OK, I've done that, and I'm not entirely certain that I fully
agree.


If I understand correctly, the gist of the argument is that too
many IPv6 resolvers run with pre-DNS-flag-day-2020 values for
EDNS0 buffer size (typically 4K), and too many of these actually
fail to receive fragmented IPv6/UDP responses, and the argument
is that this together should hold us back from issuing a blanket
recommendation to use IPv6 for DNS transport at the publishing
side.


I personally think that this would put too much power in the
hands of those who do not follow long-since issued advice.  Those
affected by "announcing too high EDNS0 buffer size", or
"inability for an IPv6 resolver to receive IPv6 fragments" are
both the users of that particular resolver, and it's the
responsibility of the resolver operator or his network provider
to fix those problems.

Why "too high EDNS0 buffer size" is announced could be for
multiple reasons, e.g. "install once, never upgrade", or
"slow-paced propagation of vendor-provided defaults through the
software delivery/update chain", or, as you implicitly suggested,
statically configured EDNS0 buffer size, and noone in the
vicinity heard about the DNS flag day 2020 or lifted a finger to
do anything about it.  Either way, those affected by such mis-
configuration are primarily the users of the affected resolver
node, and it's the responsibility of the operator of that node to
take care of that.

And ... if I'm not entirely mistaken, DNS resolvers typically
keep track of which publishing name servers (at which address)
respond, and within which time, and tend to prefer responsive and
quick-to-respond publishing name servers's addresses.  So, in a
sense, such recursive resolvers don't behave entirely similar to
the "happy eyeballs" algorithm, but rather as "happy eyeballs
with a memory of past performance", and thus tend to adapt to the
prevailing conditions.

One possible counter-argument could be that one *might* see an
increase in DNS traffic from such now considered to be
"mis-configured resolver setups", but given the "happy eyeballs
with a memory" functionality I think that this will be far less
than a doubling.


So, in sum, I am not so worried about recommending that DNS zones
should be served by at least 2 IPv6-capable publishing name
servers (which seems to be the gist of the revised
recommendation, though I agree that the wording could be better).


Regards,

- Håvard