In article <mailman.538.1351627843.11945.bind-us...@lists.isc.org>, Martin McCormick <mar...@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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
