== 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.conf_ weren't
  responding, and Firefox was having to wait for lookups against each
  to time out. But straight lookups with _dig_ weren'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 _dig_ and
Firefox's lookups, the penny dropped: because _dig_ is a tool for
direct DNS queries, it ignores _search_ directives in
_/etc/resolv.conf_.

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 _search_ directive,
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.)