odd output from dig

[Barry Margolin]

In article <fovo9c$30dr$1 at sf1.isc.org>,
 Mark Andrews <Mark_Andrews at isc.org> wrote:

> > I've been going around updating the root.hints files on my servers to 
> > account for the new Ipv6 addresses and I ran into something I've never 
> > seen before.  When I run the command:
> > 
> > dig @127.0.0.1 +bufsize=4096 ns .
> 
> 
> 	dig @a.root-servers.net +bufsize=1200 ns .
> 
> 	Is the recommended way to do this.

That depends on what "this" is.  If you're trying to see what your local 
server is doing, how could querying a root server be the recommended way?

> 
>  
> > on one of the servers I get the following output:
> > 
> >   ; <<>> DiG 9.4.1 <<>> @127.0.0.1 +bufsize=4096 ns .
> > ; (1 server found)
> > ;; global options:  printcmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10757
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 3
> > 
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;.                              IN      NS
> > 
> > ;; ANSWER SECTION:
> > .                       460853  IN      NS      B.ROOT-SERVERS.NET.
> > .                       460853  IN      NS      I.ROOT-SERVERS.NET.
> > .                       460853  IN      NS      M.ROOT-SERVERS.NET.
> > .                       460853  IN      NS      E.ROOT-SERVERS.NET.
> > .                       460853  IN      NS      L.ROOT-SERVERS.NET.
> > .                       460853  IN      NS      K.ROOT-SERVERS.NET.
> > .                       460853  IN      NS      C.ROOT-SERVERS.NET.
> > .                       460853  IN      NS      H.ROOT-SERVERS.NET.
> > .                       460853  IN      NS      F.ROOT-SERVERS.NET.
> > .                       460853  IN      NS      D.ROOT-SERVERS.NET.
> > .                       460853  IN      NS      G.ROOT-SERVERS.NET.
> > .                       460853  IN      NS      J.ROOT-SERVERS.NET.
> > .                       460853  IN      NS      A.ROOT-SERVERS.NET.
> > 
> > ;; ADDITIONAL SECTION:
> > J.ROOT-SERVERS.NET.     547253  IN      A       192.58.128.30
> > J.ROOT-SERVERS.NET.     547253  IN      AAAA    2001:503:c27::2:30
> > 
> > ;; Query time: 0 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: Wed Feb 13 08:37:15 2008
> > ;; MSG SIZE  rcvd: 283
> > 
> > As you can see it only lists the glue records for the J root server.  At 
> > first I thought maybe responses from the root servers during the pump 
> > phase after startup where getting truncated but I was able to determine 
> > via wireshark that the server is receiving all the glue records from the 
> > root servers.  I then dumped the cache and was able to find all the glue 
> > records listed in the cache. More snooping with wireshark reveals that 
> > the server does seem to be using the records that are not getting 
> > listed.  So why won't this server list those records?  I have another 
> > server running the identical version of bind which works as I would expect.
> > 
> > I certainly don't claim to be a bind expert but this just seems odd. 
> > I'm running version 9.4.1 under CentOS 5.1 on x86_64.  I'd appreciate it 
> > if someone can shed some light on what might be happening or I might be 
> > doing wrong.
> > -- 
> > Timothy A. Holtzen
> > Campus Network Administrator
> > Nebraska Wesleyan University

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***