Dig question

[Mark_Andrews at isc.org]

> 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