At Sat, 5 Dec 2009 16:18:31 -0500 (EST), der Mouse
<mouse%Rodents-Montreal.ORG@localhost> wrote:
Subject: Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before
T_AAAA lookups, was: Resolver problems
>
> 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.
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.
Perhaps it was a mistake to jam IPv6 hostnames into the DNS in such a
way that we ended up with two different record types with the exact same
purpose.
Perhaps instead we should have created a new protocol family type in the
DNS (eg. IN6) and used that instead of "IN" for all IPv6-related records.
Or maybe we should have added a new query type to the DNS that could be
used to ask for all available address-type records, though this would be
seem to be inventing an ad-hoc record classification scheme which is not
clearly defined in the DNS protocol.
You'll note from the source that getaddrinfo(3) doesn't send queries for
T_ANY records -- when it is not given any desired address family it has
to decide which type of address record to ask for (first). That's
essentially the problem which started this thread -- along with local
system conditions which cause the initially queried type to fail with a
timeout. This combination will cause consternation for users no matter
what the default search order is.
Unfortunately there isn't the DNS query I suggested which will return
all types of address records suitable for any address family and I
suspect that using T_ANY will further cause spurious failures of various
kinds when there are too many addresses to fit in a UDP reply (though
the calling code should be smart enough to retry with TCP when
necessary).
Even on a system where timeouts do not cause problems, there is
potential for unnecessary overhead should the unusable type be queried
for first.
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. By
iterating over all AF_* values your code might then eventually request
all address records suitable for all address families, regardless of
whether any or all of those addresses are suitable for use in forming a
connection from the host running the program. Unfortunately the
apparent design of the getaddrinfo(3) API defers the decision making
about which address family might "work" until after the overhead and
potential delays of requesting records for a non-"working" address
family have been incurred.
Even with AF_* iteration your code would be at the mercy of the library
implementation since there is no guarantee that any given implementation
of these APIs will support all commonly used address families.
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.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpprxelmfcLl.pgp
Description: PGP signature