Fun with DNS: a semi-obscure problem
I just helped a friend troubleshoot a DNS problem he was having on one of his home Linux machines. The specific problem was that Firefox was taking a long time to start connecting to web sites; he believed it was DNS problems.
I ran down some standard guesses:
- maybe one or more nameservers in
/etc/resolv.confweren't responding, and Firefox was having to wait for lookups against each to time out. But straight lookups with
digweren't delayed, so it wasn't that.
- he wasn't using a proxy, so it wasn't the proxy server's machine having DNS problems not shared by his workstation. (Don't laugh; this can happen, and when it does it can be head-scratching territory. It's even more fun if you're using transparent proxying.)
When I thought about what could be different between
Firefox's lookups, the penny dropped: because
dig is a tool for
direct DNS queries, it ignores
search directives in
Lo and behold, there was a
search directive that pointed to an
obsolete ISP subdomain, roughly '
search gone.b.isp.com'. While the
nameservers for 'isp.com' were fine, about half the listed DNS servers
for 'b.isp.com' didn't respond. So Firefox's lookups for 'foo.com'
started by looking up 'foo.com.gone.b.isp.com', and at least some of
the time this would try to query the non-responding DNS servers for
b.isp.com. Hence, timeouts.
Today's moral: if you put someone's domain in a
you're at the mercy of their DNS competence for all your lookups
(not just ones for their domains). And, unfortunately, people screw up
DNS records and nameservers all the time.
(My friend didn't actually need any
search directives, so we solved
the problem by just taking it out.)