Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups, was: Resolver problems

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> One of my programs (I call it addr) simply prints out the list of
>> addresses a name resolves to.  There is no implication that any of
>> those addresses are going to be used to aim network traffic;
> Interesting word, that word "addresses", especially in this context.

Indeed.

> Once upon a time the ubiquity of IPv4 addresses was so firmly
> entrenched that all we had was gethostbyname(3) and it firmly used
> only AF_INET internally with no option for anything else but yet we
> were all happy and blissful.

...until we happened to, say, use Ultrix, and had to deal with
AF_DECNET.  (Or did they spell it AF_DECnet?  I forget; it's been too
long.)  I dealt with DECnet sockets, back in the days when IP
connectivity was a rare thing in Canada, building IP-over-DECnet
tunnels among the Montreal universities - but it was too long ago for
me to remember details, and I doubt I still have the code (I've started
a find looking for it, but it'll take a while).

> You'll note from the source that getaddrinfo(3) doesn't send queries
> for T_ANY records --

True.  The semantics are wrong.  In particular, if some cache along the
way happens to contain some record for the node in question, T_ANY will
get that data and nothing else, even if other records actually do exist
in the authoritative data for that node.  (This can happen if the cache
in question was previously queried for a specific record type, like T_A
or T_MX.)

> Unfortunately there isn't the DNS query I suggested which will return
> all types of address records suitable for any address family

...probably in part because it would have much the same problem as
T_ANY, in its interaction with caches.

> Personally I think the likes of your "addr" tool should be required
> to iterate through all relevant "valid" address families when it does
> its query using getaddrinfo(3), and that AF_UNSPEC not be a valid
> hint.

But this then renders it incapable of handling address families it
doesn't specifically know about, eg when built on a system with an
address family not yet written into the code.  Between getaddrinfo()
and inet_ntop (which really should not have the "inet_" prefix;
consider AF_BLUETOOTH or AF_DECNET, neither of which is an "inet"
protocol but each of which could and arguably should be supported by
inet_ntop or something like it), there is no reason addr needs to have
any AF-specific code in it at all.  I think losing that would be a
significant regression.

If getaddrinfo() supported some kind of "bitmask of address families of
interest" rather than the current "either one family or everything"
design, this might be more palatable.

> So, for your code to be portable and useful in any environment
> perhaps it should avoid using high-level name resolution APIs and
> delve directly into the desired sources using the lowest reasonable
> APIs for the necessary protocols or databases.

Perhaps.  Indeed, from one point of view it already does - just for
values of "lowest reasonable" you disagree with.

Hmm, I should check what interface addr actually does use...it's been a
long time since I wrote it.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B