Troubleshooting BIND on RHEL3 Update 3

Mark Andrews Mark_Andrews at isc.org
Wed Nov 24 22:46:06 UTC 2004


> BIND 9.2.4 on RHEL3 (Update 3) recompiled from a source rpm w/
> --disable-ipv6 added in the configure flags.
> 
> Background - named runs fine for a while then quits resolving external
> names as illustrated below. When I issue # rndc dumpdb then grep for
> www.yahoo.com in named_dump.db there is no answer. If I wait about 15
> minutes www.yahoo.com will resolve OK - no action taken - it's found in
> the named_dump.db. Recursion is turned on for the nameserver 172.16.8.4
> (my.nameserver), the client is 172.17.217.55 trying to resolve
> www.yahoo.com and the secondary nameserver is 172.16.8.104
> (2nd.nameserver).
> 
> Finally, we have a hunch this may be related to bandwidth issues as
> executing $ dig +trace www.yahoo.com does resolve ... after 20 seconds.
> Any thoughts are greatly appreciated.
> 
> # tcpdump -vvvnnttttXs 1512 host 172.17.217.55 
> 
> 11/23/2004 23:13:21.233812 172.17.217.55.32890 > 172.16.8.4.53: [udp
> sum ok]  50298+ AAAA? my.nameserver.. (37) (DF) (ttl 63, id 50678, len
> 65)
> 0x0000   4500 0041 c5f6 4000 3f11 3c58 ac11 d937       
> E..A.. at .?.<X...7
> 0x0010   ac10 0804 807a 0035 002d 4a86 c47a 0100       
> .....z.5.-J..z..
> 0x0020   0001 0000 0000 0000 0362 7732 096a 6566       
> .........my.name
> 0x0030   6665 7273 6f6e 0263 6f02 7573 0000 1c00       
> server..........
> 0x0040   01                                             .
> 11/23/2004 23:13:21.233955 172.16.8.4.53 > 172.17.217.55.32890: [bad
> udp cksum 948a!]  50298* q: AAAA? my.nameserver. 0/1/0 ns:
> my.domain.name. SOA my.nameserver. root.my.nameserver. 2004112202 14400
> 3600 3600000 3600 (78) (DF) (ttl 64, id31953, len 106)
> 0x0000   4500 006a 7cd1 4000 4011 8454 ac10 0804       
> E..j|. at .@..T....
> 0x0010   ac11 d937 0035 807a 0056 39c5 c47a 8580       
> ...7.5.z.V9..z..
> 0x0020   0001 0000 0001 0000 0362 7732 096a 6566       
> .........my.name
> 0x0030   6665 7273 6f6e 0263 6f02 7573 0000 1c00       
> server..........
> 0x0040   01c0 1000 0600 0100 000e 1000 1dc0 0c04       
> ................
> 0x0050   726f 6f74 c00c 7774 534a 0000 3840 0000       
> root..wtSJ..8 at ..
> 0x0060   0e10 0036 ee80 0000 0e10                       ...6......
> 11/23/2004 23:13:21.234153 172.17.217.55.32890 > 172.16.8.4.53: [udp
> sum ok]  50299+ A? my.nameserver. (37) (DF) (ttl 63, id 50678, len 65)
> 0x0000   4500 0041 c5f6 4000 3f11 3c58 ac11 d937       
> E..A.. at .?.<X...7
> 0x0010   ac10 0804 807a 0035 002d 6585 c47b 0100       
> .....z.5.-e..{..
> 0x0020   0001 0000 0000 0000 0362 7732 096a 6566       
> .........my.name
> 0x0030   6665 7273 6f6e 0263 6f02 7573 0000 0100       
> server..........
> 0x0040   01                                             .
> 11/23/2004 23:13:21.234311 172.16.8.4.53 > 172.17.217.55.32890: [bad
> udp cksum 953c!]  50299* q: A? my.nameserver. 1/2/1 my.nameserver. A
> 172.16.8.4 ns: my.domain.name. NS 2nd.nameserver., my.domain.name. NS
> my.nameserver. ar: 2nd.nameserver. A 172.16.8.104 (103) (DF) (ttl 64, id
> 31954, len 131)
> 0x0000   4500 0083 7cd2 4000 4011 843a ac10 0804       
> E...|. at .@..:....
> 0x0010   ac11 d937 0035 807a 006f 39de c47b 8580       
> ...7.5.z.o9..{..
> 0x0020   0001 0001 0002 0001 0362 7732 096a 6566       
> .........my.name
> 0x0030   6665 7273 6f6e 0263 6f02 7573 0000 0100       
> server..........
> 0x0040   01c0 0c00 0100 0100 0151 8000 04ac 1008       
> .........Q......
> 0x0050   04c0 1000 0200 0100 0151 8000 0805 6973       
> .........Q....2n
> 0x0060   6161 63c0 10c0 1000 0200 0100 0151 8000       
> d.nameserver.Q..
> 0x0070   02c0 0cc0 4100 0100 0100 0151 8000 04ac       
> ....A......Q....
> 0x0080   1008 68                                        ..h
> 11/23/2004 23:13:21.235059 172.17.217.55.32890 > 172.16.8.4.53: [udp
> sum ok]  33145+ A? www.yahoo.com. (31) (DF) (ttl 63, id 0, len 59)
> 0x0000   4500 003b 0000 4000 3f11 0255 ac11 d937       
> E..;.. at .?..U...7 
> 0x0010   ac10 0804 807a 0035 0027 fd08 8179 0100       
> .....z.5.'...y..
> 0x0020   0001 0000 0000 0000 0377 7777 0579 6168       
> .........www.yah
> 0x0030   6f6f 0363 6f6d 0000 0100 01                    oo.com.....
> 11/23/2004 23:13:26.233446 172.17.217.55.32890 > 172.16.8.4.53: [udp
> sum ok]  33145+ A? www.yahoo.com. (31) (DF) (ttl 63, id 1, len 59)
> 0x0000   4500 003b 0001 4000 3f11 0254 ac11 d937       
> E..;.. at .?..T...7 
> 0x0010   ac10 0804 807a 0035 0027 fd08 8179 0100       
> .....z.5.'...y..
> 0x0020   0001 0000 0000 0000 0377 7777 0579 6168       
> .........www.yah
> 0x0030   6f6f 0363 6f6d 0000 0100 01                    oo.com.....
> 11/23/2004 23:13:51.253575 172.16.8.4.53 > 172.17.217.55.32890: [bad
> udp cksum f042!]  33145 ServFail q: A? www.yahoo.com. 0/0/0 (31) (DF)
> (ttl 64, id 32144, len 59)
> 0x0000   4500 003b 7d90 4000 4011 83c4 ac10 0804       
> E..;}. at .@.......
> 0x0010   ac11 d937 0035 807a 0027 3996 8179 8182       
> ...7.5.z.'9..y..
> 0x0020   0001 0000 0000 0000 0377 7777 0579 6168       
> .........www.yah
> 0x0030   6f6f 0363 6f6d 0000 0100 01                    oo.com.....
> 11/23/2004 23:13:51.253592 172.16.8.4.53 > 172.17.217.55.32890: [bad
> udp cksum f042!]  33145 ServFail q: A? www.yahoo.com. 0/0/0 (31) (DF)
> (ttl 64, id 32145, len 59)
> 0x0000   4500 003b 7d91 4000 4011 83c3 ac10 0804       
> E..;}. at .@.......
> 0x0010   ac11 d937 0035 807a 0027 3996 8179 8182       
> ...7.5.z.'9..y..
> 0x0020   0001 0000 0000 0000 0377 7777 0579 6168       
> .........www.yah
> 0x0030   6f6f 0363 6f6d 0000 0100 01                    oo.com.....

	I would be looking at a broken / misconfigured firewall.

	The following two queries should return a referral to the
	COM servers from A.ROOT-SERVERS.NET (198.41.0.4).  The first
	one is plain DNS, the second is EDNS and the answer size will
	exceed the 512 bytes supported by plain DNS.

	dig soa com +norec @198.41.0.4
	dig soa com +norec @198.41.0.4 +bufsize=4096

	Your firewall should be capable of supporting EDNS as it has been
	on the Standards Track for 5 years now.

Network Working Group                                            P. Vixie
Request for Comments: 2671                                            ISC
Category: Standards Track                                     August 1999


                  Extension Mechanisms for DNS (EDNS0)

	If you upgrade to 9.3.0 you can use "edns-udp-size 512;"
	to work around the firewall but the extra answer space
	provided by EDNS *is* required for correct DNS operation.  We
	knew 5 years ago that it would be required, we just didn't
	know when we would exceed the capabilities of plain DNS.
	That time has now come.

	Mark
--
Mark Andrews, ISC
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