Spotty Lookups on One of Our Networks

Mark Andrews marka at isc.org
Tue Oct 30 22:18:28 UTC 2012


In message <201210302010.q9UKAYTL064902 at x.it.okstate.edu>, Martin McCormick wri
tes:
> 	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
> 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.

Newer versions of dig turn on +dnssec with +trace (you can do +trace
+nodnssec +noedns to get the old behaviour back) as that better
reflects what the nameserver does.  The nameserver will retry with
a lower EDNS UDP buffer size, dig won't.

They are most probably dropping IP fragments at the firewall.  Fixing
the 512 byte limit (below) is only the first step.

> 	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.
> 
> 	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
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



More information about the bind-users mailing list