Dig question

[John Tobias]

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?

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