From: Mark Andrews (no email)
Date: Wed Feb 06 2008 - 00:11:07 EST
In article <> you write:
>
>On Feb 5, 2008 2:10 AM, Pekka Savola <> 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
|
|
|