[dns-wg] v6 ns/glue naming bcp

>>>>> "Peter" == Peter Koch <pk at TechFak.Uni-Bielefeld.DE> writes:

    >> Could we just say "use EDNS0" and be done with it?

    Peter> Legacy, i.e. EDNS-unaware, clients will continue to use the
    Peter> 512 byte limit, so the servers - unless they call for more
    Peter> load - should be conservative and the zone administrators
    Peter> should be as well.

Indeed. However I wonder how much legacy IPv6 stuff exists and whether
we're allowing that to unduly influence things. Suppose an EDNS0
header bit was set aside for a resolver to say "give me all the AAAA
or A6 records you have for this query". And of course, the resolver
would provide a buffer large enough to receive the reply. Meanwhile,
legacy stuff would continue with 512 byte payloads. It would see the
largely IPv4 internet just as they do right now, unless those clients
explicitly queried for (say) a AAAA record.

There's some hand-waving going on here. An RFC would be needed to
document server behaviour along the lines of "don't throw in IPv6 glue
unless you *know* the client (a) said they wanted it; (b) provided a
buffer big enough for the extra data without causing truncation.

I think this should work without breaking anything. New resolvers could
use this hypothetical EDNS0 bit if they care about IPv6. Legacy stuff
would be unchanged. However legacy IPv6 stuff would be no better off
than it is at present. That deployed base might not be large enough to
worry about anyway. IMO it won't be big enough to justify protocol
tweaks or changes in operational practice.

What I'm really saying is fix this for the millions of IPv6 hosts that
will be joining the internet and not get too obsessed with backwards
compatibility for the probably small installed base of existing IPv6
devices with resolvers that can't or won't be upgraded.

    Peter> Related to this, IPv6 already has an impact on server
    Peter> load. On our system we already see large amounts of AAAA
    Peter> and A6 type queries (each roughly 85% of the type A count),
    Peter> so I'd really favor a conservative approach.

Aha! Interesting numbers. Do you have any idea what it is that's
generating these AAAA and A6 queries? 85% of the A query count seems
very high. I wonder if there are some idiot clients out there in a
tight loop who just keep asking for AAAA or A6 even when they are told
there aren't any? Maybe it's something like that which accounts for
the high AAAA and A6 query rate you're seeing.