Dig question
Mark_Andrews at isc.org
Mark_Andrews at isc.org
Tue Aug 19 23:04:12 UTC 2003
> Mark,
>
> Thanks for your answer on this. I understand that BIND sometimes uses TCP
> when a response is too big to fit in the UDP 512 byte limit. Clearly it
> didn't do that here, so what conditions would cause BIND to use TCP for a
> query response?
A nameserver will set TC when the truncation falls in the answer or
authority sections. The client will then re-try with TCP.
> Thanks.
>
> John Tobias
>
> -----Original Message-----
> From: Mark.Andrews at isc.org [mailto:Mark.Andrews at isc.org]
> Sent: Sunday, August 17, 2003 8:14 PM
> To: John Tobias
> Cc: comp-protocols-dns-bind at isc.org
> Subject: Re: Dig question
>
>
> > Hi all,
> >
> > I am bit confused about the answers I get when "dig-ing" for ns records
> for
> > my zone. Here are the results I get:
> >
> >
> > [achilles] /usr/home/jtobias# dig @10.20.4.96 ns example.com
> >
> > ; <<>> DiG 8.3 <<>> @10.20.4.96 ns example.com
> > ; (1 server found)
> > ;; res options: init recurs defnam dnsrch
> > ;; got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
> > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 8
> > ;; QUERY SECTION:
> > ;; example.com, type = NS, class = IN
> >
> > ;; ANSWER SECTION:
> > example.com. 1D IN NS mbapdc01.ap.example.com.
> > example.com. 1D IN NS sdnadc01.na.example.com.
> > example.com. 1D IN NS ukeudc01.eu.example.com.
> > example.com. 1D IN NS ukeudc02.eu.example.com.
> > example.com. 1D IN NS fcrootdc01.example.com.
> > example.com. 1D IN NS sdrootdc01.example.com.
> > example.com. 1D IN NS ukrootdc01.example.com.
> > example.com. 1D IN NS cobra.example.com.
> > example.com. 1D IN NS fcdns01.example.com.
> > example.com. 1D IN NS fcdns02.example.com.
> > example.com. 1D IN NS tpi-ad2.example.com.
> > example.com. 1D IN NS dhnadc01.na.example.com.
> > example.com. 1D IN NS fcapdc01.ap.example.com.
> > example.com. 1D IN NS fcnadc01.na.example.com.
> > example.com. 1D IN NS fcrasdns.example.com.
> >
> > ;; ADDITIONAL SECTION:
> > cobra.example.com. 1D IN A 172.18.0.1
> > fcdns01.example.com. 1D IN A 10.1.1.1
> > fcdns02.example.com. 1D IN A 10.1.1.2
> > tpi-ad2.example.com. 1D IN A 192.168.1.10
> > dhnadc01.na.example.com. 40m1s IN A 10.34.0.11
> > fcapdc01.ap.example.com. 40m5s IN A 10.20.4.12
> > fcrasdns.example.com. 1D IN A 10.1.0.105
> > ukeudc02.eu.example.com. 46m10s IN A 10.26.0.12
> >
> > ;; Total query time: 1 msec
> > ;; FROM: achilles.example.com to SERVER: 10.20.4.96 10.20.4.96
> > ;; WHEN: Fri Aug 15 12:48:06 2003
> > ;; MSG SIZE sent: 28 rcvd: 510
> >
> > The problem I see is with the "additional records section". To me it is
> > incomplete. As you can see there are 15 NS records in the zone, but only 8
> > additional records. I have A records configured for all my NS, so why
> > doesn't dig give me back 15 "additional records" to match? The zone seems
> to
> > work perfectly; all the secondaries receive updates, etc. But the dig
> > results are leaving me a little uneasy. Any ideas about what's happening.
>
> There was no room to fit more additional records into the
> answer w/o overflowing the UDP message size limit of 512
> bytes. Dropping additional records that do not fit is
> standard practice.
>
> > Thanks for any clues.
> >
> > John
> >
> --
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews at isc.org
>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews at isc.org
More information about the bind-users
mailing list