[Bug libc/984] Respond to changed resolv.conf in gethostbyname

[Bug libc/984] Respond to changed resolv.conf in gethostbyname

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

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

[Bug libc/984] Respond to changed resolv.conf in gethostbyname

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matthias.andree at gmx dot de

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
*** Bug 3675 has been marked as a duplicate of this bug. ***

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

[Bug libc/984] Respond to changed resolv.conf in gethostbyname

[karl at thefrenches dot us]

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

karl at thefrenches dot us changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |karl at thefrenches dot us
         Resolution|WONTFIX                     |---

--- Comment #5 from karl at thefrenches dot us ---
nscd does not resolve the resolver issue.

I have verified with sendmail.  Sendmail caches the resolver information and
will not accept updates, even with nscd running.  I have verified it will still
attempt to communicate with the old name severs after updating the resolv.conf.

Another issue with the nscd solution is that it interferes with freeipa/IDM as
they require sssd and all referenced documentation states not to have nscd
intalled/running with sssd.

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

[Bug libc/984] Respond to changed resolv.conf in gethostbyname

[fweimer at redhat dot com]

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

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Karl from comment #5)
> nscd does not resolve the resolver issue.
> 
> I have verified with sendmail.  Sendmail caches the resolver information and
> will not accept updates, even with nscd running.  I have verified it will
> still attempt to communicate with the old name severs after updating the
> resolv.conf.

Indeed, this is a very good point.  Thanks.

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

[Bug libc/984] Respond to changed resolv.conf in gethostbyname

[carlos at redhat dot com]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #7 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Karl from comment #5)
> nscd does not resolve the resolver issue.
> 
> I have verified with sendmail.  Sendmail caches the resolver information and
> will not accept updates, even with nscd running.  I have verified it will
> still attempt to communicate with the old name severs after updating the
> resolv.conf.

How is that a problem in glibc if sendmail caches the resolver? Or are you
saying something else? That libc.so.6 caches the resolvers and fails to call
out to nscd? That would be a real bug, and we'd like to see some kind of
reproducer for that if possible, so we can fix the issue.

> Another issue with the nscd solution is that it interferes with freeipa/IDM
> as they require sssd and all referenced documentation states not to have
> nscd intalled/running with sssd.

This documentation is wrong. I have worked closely with the SSSD team at Red
Hat and I can get more concrete evidence to prove this if we need to. You can
run SSSD with NSCD without any problem. Can you provide a reference to the
documentation so I can talk to the SSSD team about this?

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

[Bug libc/984] Respond to changed resolv.conf in gethostbyname

[fweimer at redhat dot com]

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

--- Comment #8 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Carlos O'Donell from comment #7)

> How is that a problem in glibc if sendmail caches the resolver? Or are you
> saying something else? That libc.so.6 caches the resolvers and fails to call
> out to nscd? That would be a real bug, and we'd like to see some kind of
> reproducer for that if possible, so we can fix the issue.

sendmail needs to do MX lookups, so it uses res_query (and res_search,
depending on the context) and not one of the getaddrinfo/get*by* functions. 
It's also a forking daemon.  It initializes the glibc resolver before forking,
and I assume all the child processes inherit the cached list of name servers.

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

[Bug libc/984] Respond to changed resolv.conf in gethostbyname

[carlos at redhat dot com]

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

--- Comment #9 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #8)
> (In reply to Carlos O'Donell from comment #7)
> 
> > How is that a problem in glibc if sendmail caches the resolver? Or are you
> > saying something else? That libc.so.6 caches the resolvers and fails to call
> > out to nscd? That would be a real bug, and we'd like to see some kind of
> > reproducer for that if possible, so we can fix the issue.
> 
> sendmail needs to do MX lookups, so it uses res_query (and res_search,
> depending on the context) and not one of the getaddrinfo/get*by* functions. 
> It's also a forking daemon.  It initializes the glibc resolver before
> forking, and I assume all the child processes inherit the cached list of
> name servers.

Correct, the res_* functions are designed specifically to talk directly to
Internet domain name servers, and as such bypass nscd and sssd.

You are also correct, that once you initialize the resolver state the state is
static, this is all well known. All children and threads will have the same
resolver state if created after initialization.

It is also well known that calling res_init() again will cause any underlying
configuration files to be reloaded (atomic increment of __res_initstamp does
this).

Therefore the bug is entirely in sendmail. If you use this API you must have a
side-channel to notify the application that it should call res_init again. This
is a push process. For example it might be with systemd integration that you
discover the network has changed and call res_init() again.

There have been patches floated that add stat() calls to *all* of the res_*
functions, but the performance implications of that change have never been
analyzed and that's why the patch keeps getting rejected. Is it within the
noise to do stat() on /etc/resolv.conf to reload the resolvers if they change?
It seems a heavy handed approach for systems which are less dynamic and have
more stable configurations. At first blush it seems the stat has to be less
costly than the upcoming network traffice, but it's still a non-zero cost paid
in the hot-path of all these functions.

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

[Bug network/984] Respond to changed resolv.conf in gethostbyname

[jsm28 at gcc dot gnu.org]

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

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |philipp@redfish-solutions.c
                   |                            |om

--- Comment #10 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
*** Bug 18279 has been marked as a duplicate of this bug. ***

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

[Bug libc/984] New: Respond to changed resolv.conf in gethostbyname

[Martin dot vGagern at gmx dot net]

I've got a notebook and start an OpenVPN daemon at boot time, but lacking a dns
server it cannot connect. When I get some kinf of network connection by plugging
in an ethernet cable or coming near some WLAN access point, my network is
reconfigured and all newly started processes work well enough. But processes
started before the resolv.conf was changed have to be restarted by root which is
really annoying, especially if they maintain some kind of state while running.

This was just one example, I believe there might be many more programs around
with this kind of problem, e.g. nscd. So I make this a feature request. I'm
suprised I could not find this around already.

Possible solutions:
* reread resolv.conf every time some name is resolved
* check modification time of resolv.conf every time a name is resolved
* reread resolv.conf if a nameserver does not respond
* reread resolv.conf if cached dns ip is more than t seconds old
* include some explicit "reread now" command for such daemons
* ... to be combined and continued

-- 
           Summary: Respond to changed resolv.conf in gethostbyname
           Product: glibc
           Version: 2.3.5
            Status: NEW
          Severity: enhancement
          Priority: P3
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: Martin dot vGagern at gmx dot net
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://sources.redhat.com/bugzilla/show_bug.cgi?id=984

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/984] Respond to changed resolv.conf in gethostbyname

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2005-05-31 14:40 -------
There is a solution, already implemented.
Use nscd and nscd -i hosts in the script that rewrites your resolv.conf
(or nsswitch.conf etc.).

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


http://sources.redhat.com/bugzilla/show_bug.cgi?id=984

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/984] Respond to changed resolv.conf in gethostbyname

[dearvoid at 263 dot net]

------- Additional Comments From dearvoid at 263 dot net  2006-02-07 07:56 -------
I met the same problem. Is there any way to let gethostbyname() reread
'/etc/resolv.conf'?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/984] Respond to changed resolv.conf in gethostbyname

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2006-04-25 17:59 -------
Use nscd.  There will be no support for this is libc routines themselves.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.