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
responding, and Firefox was having to wait for lookups against each
to time out. But straight lookups with
dig weren't delayed, so it
- 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.)