[Bug libc/12350] New: Resolver doesn't save RES_SNGLKUP/RES_SNGLKUPREOP state in getaddrinfo

[Bug libc/12350] New: Resolver doesn't save RES_SNGLKUP/RES_SNGLKUPREOP state in getaddrinfo

[foom at fuhm dot net]

http://sourceware.org/bugzilla/show_bug.cgi?id=12350

           Summary: Resolver doesn't save RES_SNGLKUP/RES_SNGLKUPREOP
                    state in getaddrinfo
           Product: glibc
           Version: 2.12
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: foom@fuhm.net


If you have a broken nameserver which can't deal with multiple requests sent at
the same time (like I have just now discovered that I do after upgrading glibc:
a broken load balancer actually), then glibc attempts to work around the
problem with the single-lookup and single-lookup-reopen code (thanks!).

Unfortunately, the way the fallback is working, every single time a dns query
is made, it has a 5 second timeout before it tries the fallback single-lookup
mode. It looks like the code is attempting to save the fact that you have a
broken resolver so that only the first name resolution in a process is delayed
by 5 seconds. In resolv/res_send.c:send_dg:
 statp->options |= RES_SNGLKUP;

Unfortunately, that modification of options is defeated by the code in
sysdeps/posix/getaddrinfo.c:gaih_inet that surrounds the (eventual) call to
send_dg:

          old_res_options = _res.options;
          _res.options &= ~RES_USE_INET6;
          [...]
          _res.options = old_res_options;

So, the modification to the resolver parameters only takes effect during a
single call to getaddrinfo. Perhaps the code in gaih_inet should save/restore
only the RES_USE_INET6 flag, and not the entirety of options?

On the other hand, it might not be the best idea to permanently set the
RES_SNGLKUP flag just by ever having lost a single dns packet during the time
an app has been running (when talking to a working nameserver), even if the
code was originally intended to. So maybe it'd be better to simply remove the
modification of statp->options entirely?

Certainly I hope to have my nameserver setup fixed sooner rather than later, so
this bug is more of an "FYI" than something that I'd ever use the fix for.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12350] Resolver doesn't save RES_SNGLKUP/RES_SNGLKUPREOP state in getaddrinfo

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12350

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Ulrich Drepper <drepper.fsp at gmail dot com> 2011-05-30 03:53:16 UTC ---
I've fixed this now.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12350] Resolver doesn't save RES_SNGLKUP/RES_SNGLKUPREOP state in getaddrinfo

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12350

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.