Can't communicate with certain nameservers

[Kevin Darcy]

Wait, these UDP *responses* are coming back to port 53? I assume you have
"query-source" in effect, then, right?

If you've locked down your query port to port 53 and the responses are coming
back to the right address and port, then I'm at a loss as to why named wouldn't
be seeing these packets. Maybe you'll need to manually decode the packets after
all, to see if maybe the NAT is mangling them somehow...


- Kevin

js wrote:

> Kevin Darcy wrote:
> >
> > Yes, most of those appear to be coming from some sort of load balancer,
> > probably a Distributed Director, judging by the low (in some cases
> > 0) TTL values, and the frequent absence of an Authority or Additional
> > section to the response. I can't imagine why this would cause a query
> > timeout, though. Was the sniffer on the same segment as the nameserver, or
> > on the other side of the router? Were the responses coming back to the
> > correct port # as well as address (you'd have to scour the debug output to
> > see what port numbers those should be)?
>
> The sniffer is on the same segment as the nameserver. The packets are
> destined for the correct IP address, udp port 53 as I'd expect. I have
> not attempted to do a byte-by-byte analysis of the contents of a
> response. I'd like to avoid that if at all possible, so I'm trying to
> find out what is special about the responses generated by the servers I
> listed.
>
> I could easily be overlooking something, but it seems like the responses
> must be being discarded at a lower networking level, before they even
> get to BIND. AFAICT, the main recvfrom() call in ns_main.c does not even
> return when the response is received.
>
> > js wrote:
> >
> > > There are certain hostnames that my BIND nameserver cannot resolve. It
> > > seems to be totally unable to communicate with certain other nameservers
> > > (although 99.8% of them work fine). It just hangs and eventually times
> > > out. Some that don't work are:
> > >
> > > 205.180.59.31   dd1-ca.su-colo.bbnplanet.com  (psw.fidelity.com)
> > > 207.46.138.6    dd.microsoft.com  (download.microsoft.com)
> > > 208.158.245.135 ddcw1.barnesandnoble.com  (www.bn.com)
> > > 141.242.9.50    OCR.FREEDOM.COM  (www.freedom.com)
> > > 192.193.195.247 md38-01-i-dd1.citicorp.com  (www.accountonline.com)
> > > 192.151.11.205  paldd1.external.hp.com  (register.hp.com)
> > >
> > > With a packet sniffer, I can see a packet returning from the remote
> > > server, but BIND does not seem to see the packet at all, and doesn't log
> > > anything even at the highest debug level.
> > >
> > > I can't help but notice that most of the hostnames contain "dd". Does
> > > that suggest they are using Cisco's "DistributedDirector" product?
> > >
> > > The router between my nameserver and the internet does not do
> > > firewalling, but it does do address translation for the nameserver,
> > > using static NAT. As far as I can tell, that is the only thing even
> > > slightly unusual about my configuration.
> > >
> > > I've tried several versions of BIND (8.x and 4.x) on several different
> > > Unix and Linux systems, with exactly the same result.
> > >
> > > Any idea what is going on here? A nameserver behind NAT does not
> > > necessarily cause problems, does it? Could my router be mishandling
> > > something that DistributedDirector depends on? If so, what?