[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <536665C5.7060302@skarnet.org>
Date: Sun, 04 May 2014 17:07:33 +0100
From: Laurent Bercot <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: Resolver overhaul concepts
I believe the very first thing to address is what exactly you call
a resolver.
getaddrinfo() is a horrible interface, and one of the reasons why
is that it is loosely designed. Not much is standardized, and it's up
to you to decide exactly what to do with it; it's important to be
clear about what is implemented, and to document it, because not all
applications have the same expectations, and it's very easy to get
confused when the resolution path is unexpected.
glibc's getaddrinfo() is the entry point to the NSS layer, which
can basically implement *any* kind of "name resolution". AFAICT,
it's not a goal of musl to reimplement the whole NSS spaghetti
monster, but some applications will depend on /etc/nsswitch.conf
or something similar; even without supporting /etc/nsswitch.conf,
it would be nice to provide a mechanism to selectively enable/disable
at least /etc/hosts lookup and DNS lookup. The current resolution
policy is hardcoded as "/etc/hosts, then DNS, and nothing else",
which is a very sensible default, but probably shouldn't be the only
alternative - or if it is, it should be made abundantly clear.
> The concepts of the new DNS query backend are not really solid yet.
> One idea is that it should support the "search"/"domain" functionality
> of resolv.conf to allow querying multiple seach suffixes in parallel
> and returning as soon as there's a (possibly zero-length) initial run
> of negative results followed immediately by a positive result. The
> cleanest way to implement this kind of thing may be using a callback
> function for writing each packet and for reading the responses;
> otherwise, storing all the queries and responses as full DNS packets
> would take an unwantedly-large amount of space.
This is the approach I used in s6-dns (src/libs6dns/s6dns_resolveq.c)
and it has worked fine for me so far.
I don't think the amount of space is a concern here: the typical
search line is very short - 3 to 4 suffixes at most. You will have
to store the queries anyway to check the responses against them.
Another question that comes to mind is the timeout and retry policy.
This is network, it's going to suck; this is DNS, it's going to suck
even more. getaddrinfo() doesn't allow the user to specify a timeout
(yay for unboundedly synchronous network-facing interfaces), so it's
up to musl to decide what to do: do you resend a query after a soft
timeout ? do you have a hard timeout after which you report failure ?
or do you block indefinitely ?
Doing network communications the right way (especially with an old
and ugly protocol) is complex. It should be way outside the scope of
a libc. glibc people have it easy: the DNS part of NSS directly ties
into libresolv, so they have a full-fledged resolver to use. I say
we should do the same and tie musl to libs6dns. :P
--
Laurent, forhttp://skarnet.org/software/s6-dns/getaddrinfo.html
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
