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.