This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

On glibc's resolver

Hello list,

I was trying to write a patch for glibc so hopefully this is the appropriate list, please let me know otherwise.

I have been tracing weird behaviour of my mail client (alpine) and ended up in getaddrinfo() calls, which are handled by glibc's resolver. In particular, when I connect my laptop to different networks and the previous DNS server is unreachable, resolver never re-reads its cache and all queries timeout after several retries.

Apparently this is a known issues, and a web search reveals discussions from as early as 2003. I'd appreciate your opinions, I was thinking of writing a patch but I can't figure out where it should go, alpine or glibc, code or documentation! Here are the replies I gathered from a web search:

1) Use a caching daemon (nscd maybe, some argue that it does not provide a solution) which should be restarted/reloaded when changing networks.

2) Call res_init() if getaddrinfo() fails.

3) Patch glibc to stat() /etc/resolv.conf, checking for changes. Debian, Ubuntu are patched.

4) Use a custom DNS library, glibc is unsuitable for this purpose.

Here is my take. About nscd, I'm having the problem on a major distro (Fedora) so I can only guess there are good reasons for not using it by default.

On (2), res_init() is a BSD non-standard function, and its man page doesn't mention such a purpose. In fact I can't be sure if it's safe to call it multiple times and I see no guarantee that it will re-initialise the resolver more than once. If it's the proposed way shouldn't it be mentioned in both res_init() and getaddrinfo()'s man pages, or otherwise a big warning that resolv.conf is never reparsed?

On (3) I don't have a Debian system to check it, but the overhead of stat'ing on every request is probably unacceptable. I was thinking of writing a patch that would stat() and reparse after a single request timeout, so that following retries (unless RES_DFLRETRY is reached) will automatically connect to the new servers. Would that be acceptable?

Finally using a custom library sounded logical, until I started reading glibc's resolver. Really, with such size and complexity and even asynchronous interface provided, shouldn't we also provide the simplest facilities?

And a related question, is there a way to setup resolver behaviour (timeout, retries) for a process programmatically, instead of changing the system-wide resolv.conf?

Thank you in advance, Dimitris

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]