Repotting report

Wed Feb 6 05:11:07 UTC 2008

In article <75cb24520802051931y398474aja16999bdf86b995b at mail.gmail.com> you write:
>
>On Feb 5, 2008 2:10 AM, Pekka Savola <pekkas at 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