North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Repotting report
In a message written on Mon, Feb 04, 2008 at 07:50:50PM -0500, Kevin Loch wrote: > There is an interesting variation in what records are returned for a > standard 512 byte request (dig ns . @[x].root-servers.net): > > A,C,D,E,F,G,I,J: return the same 10 A records and 4 AAAA records in the > same order every time. They never return A records for K,L,M and never > get AAAA records for K,M. > > B: returns all 13 A records in random order and then two AAAA records > in random order. This allows all records to be returned with equal > weight within each record type. > > H,K,L,M: return all 13 A records in static order and then A and F AAAA > records so H,J,K,M AAAA records are never returned. > > Tested with dig 9.4.1-p1 on a v6 enabled system. I concur. An interesting thing I noticed that doesn't really cause an operational problem but may confuse some people is their behavior is also quite different when queried for "any". If your a lazy admin like me who is used to typing "dig any foo" for testing you 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. -- Leo Bicknell - [email protected] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Attachment:
pgp00003.pgp
|