Resolver overhaul concepts

[Rich Felker <dalias@libc.org>]

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