resolver failures without even sending queries, break Postfix

Created attachment 5707
code to demonstrate the bug

(I've observed this on eglibc 2.13 and glibc 2.11.3 and confirmed it's still present in Git.)

Problem: res_search() can return -1 with h_errno == HOST_NOT_FOUND without ever having attempted a nameserver query even when it should have sent one.

In particular, this affects hostname resolution of "localhost" (without dots) if RES_DEFNAMES isn't set. (Use case: a security-sensitive application strips this flag to avoid the domain search and to avoid getting bogus localhost.example.org results that might not point to 127.0.0.1/::1.)

Pseudo code, without error checking:

res_init();
_res.options &= ~RES_DEFNAMES;
int result = res_search("localhost", C_IN, T_A, buf, sizeof buffer);

This is an important portability issue from BSD or Solaris to Linux and affects, for instance, Postfix 2.8.X.

Compare the glibc source code lines 323 ff. <http://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/res_query.c;h=5ff352e2fc6056bad92238df1fb0c826f48a2f51;hb=HEAD#l323> against FreeBSD, lines 371 ff. in <http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/resolv/res_query.c?annotate=1.6;only_with_tag=MAIN>.

I've attached a test program, show-resolv.c, to demonstrate the problem.

To compile: gcc -ggdb3 -O -std=gnu99 -pedantic -Wall -o show-resolv show-resolv.c -lresolv

To run: strace -e recv,send,recvfrom,sendto ./show-resolv

You will see that no DNS packets are sent to the nameserver configured in /etc/resolv.conf.

Actual output (no send/recv stuff!):

$ strace -e recv,send,recvfrom,sendto ./show-resolv
default _res.options = 802C1
stripped _res.options = 80241
res search result: -1, h_errno: 1 (Unknown host)

Expected output:

$ strace -e recv,send,recvfrom,sendto ./show-resolv
default _res.options = 802C1
stripped _res.options = 80241
sendto(3, "\34\264\1\0\0\1\0\0\0\0\0\0\tlocalhost\0\0\1\0\1", 27, MSG_NOSIGNAL, NULL, 0) = 27
recvfrom(3, "\34\264\205\200\0\1\0\1\0\0\0\0\tlocalhost\0\0\1\0\1\300\f\0\1\0"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.0.4")}, [16]) = 43
res search result: 43

Of course the recvfrom details may differ with /etc/resolv.conf configuration.
And instead of 43, any positive number that makes it plausible we've received a successful reply to a DNS query for localhost IN A is valid, should there be gratuitious other records returned from the name server.

Please fix the resolver so that it actually sends a query for bare hostnames (without any dots, inner or trailing), localhost is a valid TLD.

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

There is a massive upstream resolver error that causes "HOST_NOT_FOUND" errors without every trying to resolve a valid host.

res_init();
_res.options &= ~RES_DEFNAMES;
int result = res_search("localhost", C_IN, T_A, buf, sizeof buffer);

Upstream report: http://sourceware.org/bugzilla/show_bug.cgi?id=12734

Flagging major because in combination with Postfix 2.8 this can cause legit mail to be rejected (i. e. somewhat of a "data loss", probably not warranting critical)

Reproducible: Always

Steps to Reproduce:
see upstream report, has a test program and instructions

I'm looking at

 479 /*
 480 * If the name has any dots at all, and no earlier 'as-is' query
 481 * for the name, and "." is not on the search list, then try an as-is
 482 * query now.
 483 */
 484 if (dots && !(tried_as_is || root_on_list)) {

I wonder why the dots check is there?

(However, I also wonder, if you want to ensure no search, wouldn't it be much more natural to use a FQDN rather than a one-off disabling of RES_DEFNAMES?)

I haven't checked where the source or the dots check originated.

Using a "fully-qualified domain name" would sidestep the bug but let's not introduce workarounds if we can fix the bug and I contend that localhost by itself arguably already is a FQDN.

I have not found Internet standards prohibiting single-level domain names (unlikely though they may be), but I have found RFC 1912 and RFC 2606 that sanction localhost.

FQDN has a clear definition - it ends with a dot. Otherwise, it may be by default subject to various relative searches.

(Not disputing that there is a bug, I just wanted to clarify this.)

Let's not go hair splitting about FQDN or not: suppressing the relative searches along the "search" list from /etc/resolv.conf is what this is all about. And if it were working, the difference between "localhost" and "localhost." were entirely theoretical, because either way we'd look up "localhost" in the root (".") zone. :-)

Pointing to any *BSD is irrelevant. Code like that is in BIND, too, though and that I backported as far as necessary.

(In reply to comment #5)
> Pointing to any *BSD is irrelevant. Code like that is in BIND, too, though and
> that I backported as far as necessary.

In order to assist distributors with cherry-picking the fix:
Is the patch in <http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f87dfb1f11c01f2ccdc40d81e134cd06b32e28e8> all that's needed?

Apparent upstream fix:
<http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f87dfb1f11c01f2ccdc40d81e134cd06b32e28e8;hp=47c3cd7a74e8c089d60d603afce6d9cf661178d6>

openSUSE 11.4 is no longer supported and the bug was fixed in openSUSE 12.1.