|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Repotting report
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].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
|