Re: Repotting report

[Mark Andrews <Mark_Andrews () isc org>]

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