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.)