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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 07 Dec 2009 02:15:40 -0500
    From:        "Greg A. Woods" <woods%planix.ca@localhost>
    Message-ID:  <m1NHXot-000kn4C%most.weird.com@localhost>

  | 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.

No, DNS classes are an ill-defined botch, it isn't clear what they are
for, or how they're intended to work, originally anyway, it is clear
that they don't work as things are implemented.

And there are already a host of different address type resource records
defined (SNAP, X.25, ...) which co-exist with IPv4 (perhaps mostly
as no-one has ever bothered with them to any extent anyone notices),
but there's no reason for IPv6 to be diffeent.

  | 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.

That has been considered, very seriously, the classification problem
doesn't really exist, but it has the same kinds of problems as ...

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

because it doesn't work, ANY queries don't operate the way you'd think
they might at first glance, and they're useless for reliable data fetching
(on the other hand, they're great for debugging cache problems).

sendmail tried using ANY queries (to fetch MX and A, or whichever of
those was available, rather than AAAA and A, but the DNS doesn't care
much about one RR type compared to another - or not in the answer section)
which failed miserably in certain cases - sendmail no longer does that,
nor does anything else written by anyone who understands the DNS.

  | 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).

The reply size is not the problem, but spurious failures certainly are.

  | 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.

A good "addr" tool would look for NSAP, X.25, and other "address" RR types as
well, probably.   I certainly agree that any kind of diagnostic of
information gathering tool should not just be using getaddrinfo() and
assuming it will necessarily return everything.

kre