Date: Sun, 4 May 2014 08:42:38 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Resolver overhaul concepts Since resolver overhaul is up on the roadmap for 1.1.2, targetted for sometime this month, I'd like to get a discussion of the proposed design/behavior changes going. The current behavior: 1. Determine a single matching port/protocol (if the protocol is unspecified, only tcp is matched). 2. Special-case passive/local address requests (no host arg). 3. Try host as ip literal. 4. Parse hosts file and return a single (first matching) result from it. (This will fail to produce multiple results, even in AF_UNSPEC case where both v4 and v6 addresses are in the hosts file.) 5. DNS query (in parallel with multiple nameservers and possibly v4/v6, but only a single name lookup) with results going into DNS packet buffers. 6. Count results with a DNS packet pre-parse phase and allocate space. Then parse the packet(s) and fill in the results. (Note: only in the case where this step is reached can multiple results even be returned.) The new behavior: 1. From the beginning, have moderately large fixed-size automatic (stack-based) buffers to store both service and address results into. 2. Find all matching services and store them into the service list. 3. If host is null or an ip literal, store a single address, as appropriate, in the address list. 4. If address list is empty, try hosts file, inserting each matching record into the address list. (A record only matches if the address family matches, possibly with AF_V4MAPPED applied, or if the request is for AF_UNSPEC.) 5. Transform hostname for IDN, if necessary. 6. If the address list is empty, perform DNS queries, but with a new DNS query backend that's more flexible (to be described later) and store results directly to the address list. 7. Possibly filter, transform, or sort address results. (e.g. applying AI_V4MAPPED). 8. Allocate space for cross-product of service list and address list, and if successful, copy the results into the allocated space. 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. Rich
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.