trouble with dns

[Mark_Andrews at isc.org]

> Me wrote:
> > Greetings,
> > 
> > I have a linux machine with bind and all seems fine locally. I can do 
> > nslookups, dig, host, all fine, but the windows machines on the lan 
> > cannot use it. Here are the error messages in the linux logfiles.
> > 
> > 
> >     client 192.168.0.206#1025: error sending response: host unreachable: 
> > 4 Time(s)
> >     client 192.168.0.206#1478: error sending response: host unreachable: 
> > 4 Time(s)
> >     client 192.168.0.206#1481: error sending response: host unreachable: 
> > 4 Time(s)
> > .............
> > 
> > the 192.168.0.206 is one of the windows machines on the lan, the log 
> > file shows similar errors for all the other windows machines as well...
> > 
> > I'm not sure were to start... Please Help :)
> > 
> > rick
> 
> 
> Rick,
> 
> 	I've been having this same problem since I upgraded BIND last spring 
> from what ships with Red Hat 7.1 to one of the errata RPMs.  I never saw 
> this message before that; but I've seen a lot of it since.
> 
> 	I've asked before about it and most of the responses were (1) you have 
> a route problem or (2) you have a firewall problem.  I knew those 
> weren't the case because (1) it happened between my DNS and hosts on the 
> same subnet and (2) I disabled firewalling on both ends.
> 
> 	The problem has never happened that I can tell on the DNS box that I 
> use only internally, which is singled-homed (which is to say it has only 
> one NIC and only one IP on that NIC).  My other 2 machines are 
> dual-homed, but one of the interfaces is only for management and no 
> clients point to those management interfaces for DNS.
> 
> 	Even though I've had this problem for a while, I never have complaints 
> about DNS being slow or not answering.  Since I wasn't satisfied with 
> most of the answers I got earlier, I recently decided to do run tcpdump 
> on both ends (which is not always possible, I know, but I was able to do 
> so on a few boxen) and do some more detailed investigating.  Here are my 
> findings and opinions.
> 
> First, my general observations:
> 1. when the problem occurs, it is generally with the same half dozen or 
so hosts; some are Windows, others Linux
> 2. in every case so far, the client sends out a request, then, 10 
> seconds later it sends out a 2nd identical request (same source port, as 
> well)
> 3. in every case, the server responds, but usually 60 seconds or more 
> after the original query
> 4. in every case so far, the server's answer has been SERVFAIL or 
> NXDOMAIN; it SEEMS like it doesn't happen when the server responds 
> quickly and with a positive answer; this also only happens when my 
> server has to do recursion and get an answer about a domain or IP it 
> doesn't serve out
> 5. the client then sends an 'icmp port unreachable' back to the server
> 6. the named daemon, then, logs that in /var/log/messages
> 
> 
> Here, then, is an excerpt from the log file at the time the error 
> occurred... (IPs masked)
> Feb 16 04:01:41 dns2 named[26153]: client client.IP#38766: error sending 
> response: host unreachable
> 
> Here is what tcpdump showed on the client end for that port # and time 
> stamp...
> 04:00:11.487669 client.IP.38766 > server.IP.53:  40480+ PTR? 
> 21.180.139.216.in-addr.arpa. (45) (DF)
> 04:00:21.506507 client.IP.38766 > server.IP.53:  40480+ PTR? 
> 21.180.139.216.in-addr.arpa. (45) (DF)
> 04:01:41.527446 server.IP.53 > client.IP.38766:  40480 ServFail 0/0/0 
> (45) (DF)
> 04:01:41.527472 client.IP > server.IP: icmp: client.IP udp port 38766 
> unreachable [tos 0xc0]
> 
> Server side tcpdump was identical to client side.
> 
> My thoughts...
> 1. this seems limited to the negative answers possibly because the 
> server has to wait so long to get an answer
> 2. the client sends 2 requests because it hasn't gotten its first answer 
> within 10 seconds
> 3. is there some way I can tell my dns to wait less time for its answers 
> so it doesn't have to wait so long to respond?
> 4. I'm going to keep watching this to see if it ever happens on a 
> positive answer; I somehow doubt it will
> 5. at the end of the day, it doesn't seem to hurt performance but it 
> sure is a nuisance
> 
> Any thoughts?
> --Brian C.

	It sounds like the kernel's not correctly handling the
	setsockopt(SO_BSDCOMPAT).   This option stops the kernel
	returning error messages for port unreachable on unconnected
	UDP sockets.  Under the BSD socket API these are only
	returned on connected sockets.

	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