North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Repotting report

  • From: Mark Andrews
  • Date: Wed Feb 06 00:18:23 2008

In article <[email protected]> you write:
>On Feb 5, 2008 2:10 AM, Pekka Savola <[email protected]> wrote:
>> On Mon, 4 Feb 2008, Leo Bicknell wrote:
>> > may try "dig any . @[a-m]"
>> >
>> > 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


>Having inconsistent information seems like it might cause more than
>just troubleshooting headaches...