[Bug 777855] Re: resolver failures without even sending queries, break Postfix

Wed May 25 14:53:36 UTC 2011

Launchpad has imported 7 comments from the remote bug at
http://sourceware.org/bugzilla/show_bug.cgi?id=12734.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2011-05-05T13:31:15+00:00 Matthias Andree wrote:

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.

Reply at: https://bugs.launchpad.net/glibc/+bug/777855/comments/0

------------------------------------------------------------------------
On 2011-05-05T16:02:24+00:00 Petr Baudis wrote:

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

Reply at: https://bugs.launchpad.net/glibc/+bug/777855/comments/5

------------------------------------------------------------------------
On 2011-05-05T16:35:47+00:00 Matthias Andree wrote:

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.

Reply at: https://bugs.launchpad.net/glibc/+bug/777855/comments/6

------------------------------------------------------------------------
On 2011-05-05T16:56:00+00:00 Petr Baudis wrote:

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

Reply at: https://bugs.launchpad.net/glibc/+bug/777855/comments/7

------------------------------------------------------------------------
On 2011-05-05T18:25:18+00:00 Matthias Andree wrote:

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

Reply at: https://bugs.launchpad.net/glibc/+bug/777855/comments/8

------------------------------------------------------------------------
On 2011-05-07T17:06:31+00:00 Drepper-fsp wrote:

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

Reply at: https://bugs.launchpad.net/glibc/+bug/777855/comments/9

------------------------------------------------------------------------
On 2011-05-07T22:03:51+00:00 Matthias Andree wrote:

(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?

Reply at: https://bugs.launchpad.net/glibc/+bug/777855/comments/10

** Changed in: glibc
       Status: Unknown => Fix Released

** Changed in: glibc
   Importance: Unknown => Critical

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to postfix in Ubuntu.
https://bugs.launchpad.net/bugs/777855

Title:
  resolver failures without even sending queries, break Postfix