Spotty Lookups on One of Our Networks

Barry Margolin barmar at alum.mit.edu
Tue Oct 30 20:38:02 UTC 2012


In article <mailman.538.1351627843.11945.bind-users at lists.isc.org>,
 Martin McCormick <martin at dc.cis.okstate.edu> wrote:

> 	I don't thing this is a bind problem because this
> particular network has some Microsoft DNS's that are doing
> exactly the same thing.
> 
> 	There are several domains names that are broken in this
> network and the symptome is always the same:
> 
> 	Dig +trace @localhost one.bad.domain.com.
> 
> 	We see all the root name servers listed. We get the TLD
> servers next and, from one of them, we get authoritative DNS's
> from bad.domain.com where we should get the IP address from
> one.bad.domain.com. That is where it breaks. It times out with

I'm not sure what you mean by that sentence about getting authoritative 
DNSs from X when it sbould be from Y. Can you post the actual dig?

BTW, @servername doesn't mean much when using +trace, since +trace 
queries the servers listed in NS records, not a resolver.

> no authoritative servers that will talk to us. One site is
> noaa.gov which is the National Oceanic and Atmospheric
> Administration in the United States.
> 
> 	We have no trouble at all resolving them from our
> network so I filled in the missing information for the
> authoritative domain name servers and hard-coded one or two of
> them in lookups on the problem network and, no surprise, the
> lookup still times out.

What happens if you try to telnet to port 53 on the auth nameservers 
from your local resolvers? What about traceroute?

> 
> 	One really good lead evaporated when I discovered that
> this network still had a 512-byte limit on its firewall so we
> thought this might be the problem but no such luck. The firewall
> now passes edns packets just fine, but nothing has really
> changed.
> 
> 	Any ideas as to what prevents some lookups from
> resolving. Others do resolve.
> 
> 	We have been kicking this problem around for about a
> week and the customers, there, are getting a bit restless. They
> are connected to the same ISP we are and we are not having any
> problems like this. 
> 
> 	There seems to be no reason  why some remote domains
> work and others don't. I am asking on this list in hopes that
> somebody has seen something like this somewhere else and found
> the cause.
> 
> Thank you.
> 
> Martin McCormick WB5AGZ  Stillwater, OK 
> Systems Engineer
> OSU Information Technology Department Telecommunications Services Group

-- 
Barry Margolin
Arlington, MA



More information about the bind-users mailing list