BIND 9.2.1 and TCP
zack.nash at amd.com
zack.nash at amd.com
Thu Nov 7 17:58:31 UTC 2002
'dig +ignoretc +search <name>' :
; <<>> DiG 8.2 <<>> +ignoretc +search nash.amd.com @aus-la-ns1
; (1 server found)
;; res options: init igntc recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41812
;; flags: qr aa tc rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 22, ADDITIONAL: 0
;; nash.amd.com, type = A, class = IN
nash.amd.com. 0S IN A 139.95.99.116
amd.com. 1H IN NS ns2.amd.com.
amd.com. 1H IN NS ns5.amd.com.
amd.com. 1H IN NS ns6.amd.com.
amd.com. 1H IN NS ns7.amd.com.
amd.com. 1H IN NS ns8.amd.com.
amd.com. 1H IN NS ns9.amd.com.
amd.com. 1H IN NS fuji.amd.com.
amd.com. 1H IN NS ns10.amd.com.
amd.com. 1H IN NS ns11.amd.com.
amd.com. 1H IN NS ns12.amd.com.
amd.com. 1H IN NS ns13.amd.com.
amd.com. 1H IN NS f30ns1.amd.com.
amd.com. 1H IN NS f30ns2.amd.com.
amd.com. 1H IN NS vienna.amd.com.
amd.com. 1H IN NS bkkdns1.amd.com.
amd.com. 1H IN NS pngdns1.amd.com.
amd.com. 1H IN NS sgpdns1.amd.com.
amd.com. 1H IN NS suzdns1.amd.com.
amd.com. 1H IN NS suzdns2.amd.com.
amd.com. 1H IN NS nsmaster.amd.com.
amd.com. 1H IN NS seurdns1.amd.com.
amd.com. 1H IN NS shkgfile1.amd.com.
;; Total query time: 61 msec
;; FROM: qip-ent to SERVER: aus-la-ns1 163.181.250.235
;; WHEN: Thu Nov 7 09:55:00 2002
;; MSG SIZE sent: 30 rcvd: 492
'dig +search <name>':
; <<>> DiG 8.2 <<>> +search nash.amd.com @aus-la-ns1
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17504
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 24, ADDITIONAL: 25
;; nash.amd.com, type = A, class = IN
nash.amd.com. 0S IN A 139.95.99.116
amd.com. 1H IN NS pngdns1.amd.com.
amd.com. 1H IN NS sgpdns1.amd.com.
amd.com. 1H IN NS suzdns1.amd.com.
amd.com. 1H IN NS suzdns2.amd.com.
amd.com. 1H IN NS nsmaster.amd.com.
amd.com. 1H IN NS seurdns1.amd.com.
amd.com. 1H IN NS shkgfile1.amd.com.
amd.com. 1H IN NS slave-232-2.amd.com.
amd.com. 1H IN NS ns1.amd.com.
amd.com. 1H IN NS ns2.amd.com.
amd.com. 1H IN NS ns5.amd.com.
amd.com. 1H IN NS ns6.amd.com.
amd.com. 1H IN NS ns7.amd.com.
amd.com. 1H IN NS ns8.amd.com.
amd.com. 1H IN NS ns9.amd.com.
amd.com. 1H IN NS fuji.amd.com.
amd.com. 1H IN NS ns10.amd.com.
amd.com. 1H IN NS ns11.amd.com.
amd.com. 1H IN NS ns12.amd.com.
amd.com. 1H IN NS ns13.amd.com.
amd.com. 1H IN NS f30ns1.amd.com.
amd.com. 1H IN NS f30ns2.amd.com.
amd.com. 1H IN NS vienna.amd.com.
amd.com. 1H IN NS bkkdns1.amd.com.
ns1.amd.com. 1H IN A 139.95.53.235
ns2.amd.com. 1H IN A 139.95.6.235
ns5.amd.com. 1H IN A 139.95.27.235
ns6.amd.com. 1H IN A 139.95.1.235
ns7.amd.com. 1H IN A 163.181.1.2
ns8.amd.com. 1H IN A 163.181.9.235
ns9.amd.com. 1H IN A 163.181.52.235
fuji.amd.com. 1H IN A 139.95.100.1
ns10.amd.com. 1H IN A 163.181.88.235
ns11.amd.com. 1H IN A 163.181.234.235
ns12.amd.com. 1H IN A 172.28.4.253
ns13.amd.com. 1H IN A 139.95.144.235
f30ns1.amd.com. 1H IN A 172.20.3.235
f30ns2.amd.com. 1H IN A 172.20.13.235
vienna.amd.com. 1H IN A 163.181.61.42
bkkdns1.amd.com. 1H IN A 165.204.128.235
pngdns1.amd.com. 1H IN A 165.204.164.235
sgpdns1.amd.com. 1H IN A 101.2.0.235
suzdns1.amd.com. 1H IN A 165.204.224.33
suzdns2.amd.com. 1H IN A 165.204.224.2
nsmaster.amd.com. 1H IN A 172.28.13.229
nsmaster.amd.com. 1H IN A 172.28.4.229
seurdns1.amd.com. 1H IN A 165.204.82.235
shkgfile1.amd.com. 1H IN A 139.95.102.95
slave-232-2.amd.com. 1H IN A 163.181.232.109
;; Total query time: 164 msec
;; FROM: qip-ent to SERVER: aus-la-ns1 163.181.250.235
;; WHEN: Thu Nov 7 09:55:46 2002
;; MSG SIZE sent: 30 rcvd: 936
Thanks,
Zack
-----Original Message-----
From: Mark.Andrews at isc.org [mailto:Mark.Andrews at isc.org]
Sent: Wednesday, November 06, 2002 10:19 PM
To: Nash, Zack
Cc: bind-users at isc.org
Subject: Re: BIND 9.2.1 and TCP
>
> The request is for a single A record, ( nash 3600 IN A 192.168.0.1 ), would t
> his be too large to fit in a UDP packet. Also we have BIND 8 servers that se
> rve the same information and they do not revert to TCP for these records. Co
> uld this possibly be a misconfiguration on my part, or is there no way to res
> trict the server to only using udp?
> Thanks,
> Zack
Why don't you show us what 'dig +ignoretc +search <name>' returns
then 'dig +search <name>'.
Mark
>
> -----Original Message-----
> From: Mark.Andrews at isc.org [mailto:Mark.Andrews at isc.org]
> Sent: Wednesday, November 06, 2002 4:25 PM
> To: Nash, Zack
> Cc: bind-users at isc.org
> Subject: Re: BIND 9.2.1 and TCP
>
>
>
> > Hello,
> > I have noticed that my BIND 9.2.1 servers are requesting that my DNS Cl
> > ients use TCP rather than UDP to resolve hostnames, for all queries against
> t
> > his server.
> > My understanding is that UDP is used unless the packet is too large the
> > n the server will request a TCP connection from the client. I have seen th
> is
> > occur for queries of a single A record. Is this behavior a bug or is this
> a
> > new standard that is being implemented with the advent of BIND 9?
> > Thanks,
> > Zack
>
> Well the answers must be too big to fit in the space available in a
> UDP response. Remember the authority section can also trigger TC.
>
> Mark
> --
> 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