In article <75cb24520802051931y398474aja16999bdf86b995b@mail.gmail.com> you write:
On Feb 5, 2008 2:10 AM, Pekka Savola <pekkas@netcore.fi> wrote:
On Mon, 4 Feb 2008, Leo Bicknell wrote:
may try "dig any . @[a-m].root-servers.net."
When I do that, I get the following response:
a, c, d e, f, g, i and j return 1 SOA, 8 A, and 3 AAAA's (the first 3). b, h, l, k, and m return 1 SOA, 13 A, no AAAA records.
If you make this mistake you might think b, h, l, k and m have no IPv6 data, which is wrong. Querying with NS (as nameserver would do) clearly shows that.
While a cosmetic problem, I fear it may confuse a number of admins as the troubleshoot problems in the near future.
It certainly will. Section 1.4 of RFC 4472 may be helpful here, though it mainly talks about this from the viewpoint of caching, not root servers.
So, how will this sort of thing affect traffic levels to the servers in question? Will this affect stability on a v6only or v4-limited site/network? (13 v4 servers, 4 v6 servers...)
How does a cache-resolver know that it's time to issue a query with edns0?
cache-resolver that support EDNS0 will make EDNS0 queries by default. They will fallback to plain DNS if the query fails or they get a response that indicated the authoritative server doesn't support EDNS. BIND's been making EDNS0 queries for ~8 years now. If your cache-resolver doesn't support EDNS it is long past time to upgrade. Mark
Having inconsistent information seems like it might cause more than just troubleshooting headaches...
-Chris