odd output from dig
Timothy Holtzen
tah at NebrWesleyan.edu
Wed Feb 13 22:47:12 UTC 2008
Sorry for the confusion. Querying against the A root server as you
suggest is indeed how I updated my root.hints file. However what I'm
trying to figure out is what is going on with my system and why it is
returning a truncated response. My understanding is my system should
give me the same response that I get from the root servers after it has
been running a while and has a chance to grab the latest records from
the root servers.
Mark Andrews 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.
>
>
>
>> 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
>>
--
Timothy A. Holtzen
Campus Network Administrator
Nebraska Wesleyan University
More information about the bind-users
mailing list