A flaw in the default behaviour of glibc's getaddrinfo() results in a way to hijack failed NXDOMAIN domain lookups has been reported [1],[2].  If the local domain name has only two components (e.g. "foo.com" rather than "host.foo.com"), due to how resolution is performed, a failed lookup of "bar.com" will be retried as "bar.com.com", as noted in resolv.conf(5):

  domain Local domain name.

    Most queries for names within this domain can use short names relative
    to the local domain.  If no domain entry is present, the domain is
    determined from the local hostname returned by gethostname(2); the domain
    part is taken to  be  everything  after the first '.'.  Finally, if the
    hostname does not contain a domain part, the root domain is assumed.

This is being used by the owners of the com.com domain by using a wildcard A record for "*.com.com" which redirects to an ad-heavy site.  The problem is most visible when the hostname only has two components, and the TLD is ".com", but there may be others (for instance having "foo.org" as the system's hostname and being "bar.org" failing and being looked up as "bar.org.org" (currently org.org does not capture undefined subdomains).

This can be mitigated by using a local hostname in conjunction with the domain name (such as using "host123.foo.com" rather than simply "foo.com"), rather than using (essentially) a NULL hostname with the domain name.

The suggested resolution is to set the default of "ndots" to 0, or to not use the default domain for searches unless it has more than a TLD (e.g. ".com").

John Nagle also has noted some good information [3] regarding RFC 1535 [4] "A Security Problem and Proposed Correction With Widely Deployed DNS Software".

[1] http://serverfault.com/questions/341383/possible-nxdomain-hijacking
[2] http://sourceware.org/bugzilla/show_bug.cgi?id=13935
[3] http://sourceware.org/bugzilla/show_bug.cgi?id=13935#c2
[4] http://www.ietf.org/rfc/rfc1535.txt