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

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Sat, Dec 05, 2009 at 05:44:43PM +0700, Robert Elz wrote:

>   | getaddrinfo() is only used by programs that can handle IPv6
> 
> Typically yes, but not necessarily

To clarify this, a program that uses getaddrinfo() has to know
that not everything is IPv4 (and thus 'handle it') wether it
wants to use IPv6 connections or not. It either has to tell
getaddrinfo() to restrict itself to some answers or it has to
check the result for answers that it does understand.


> Yes, it is (or should be) a real problem only in those cases, but it is
> a waste of network resources in others - just asking for a v6 address
> you're never going to use is a packet out, a packet back, and the back
> end resolver being made to do (and then cache) data that's useless.
> It shouldn't be a problem, but it is pretty stupid and unnecessary.

It is how the coexistence of IPv4 and IPv6 has been designed. The
alternative is to use a T_ANY query and filter the results.


>   | So please, add a knob to control libc behaviour.
> 
> For this, I'd do that, but I'd also not query for addresses that we
> can tell cannot possibly be useful

How would you know? I can easily imagine a program analyzing
logfiles, resolving host names or addresses without using
these to create a network connection. The program would behave
differently wether you give the machine IPv6 connectivity or not.

As I said in my previous mail. This is about a workaround that
should be enabled by a decision. Magically deriving this from
something else is going to fail.


>   | - resolv.conf is not my first choice, because this is used by
>   |   the resolver code, not the high level functions like getaddrinfo().
> 
> Here I disagree (mildly at least) - I consider getaddrinfo() (and
> gethostbyname()) to just be the programmer friendly interfaces to the
> resolver - they're part of it.

Neither regarding history of development nor the actual code.

resolver is about DNS queries, it doesn't deal with files, nis,
ldap or anything else and it uses resolv.conf as its configuration
file.

getaddrinfo() is about name and address translations, it may use
the resolver subsystem as one of its data sources and it uses
nsswitch.conf as its configuration file.


> That's not the right bit to use (even though I couldn't find any place
> NetBSD's code actually uses it - in libc anyway) but the analogy is a
> reasonable one.    And we have practice of other systems.

Do we?


>   | - nsswitch.conf would be a natural choice if it allowed to pass
>   |   options to the backends (e.g. hosts: files dns[v4only]). But
>   |   who dares to touch nsswitch code? :)
> 
> Well, maybe, I guess we could allow dns4only and dns6only as alternatives
> to dns in there, but that looks to be a bit of a stretch.

nsswitch.conf determines who provides the name translations. Using
it to provide options on how the names are translated seems to be
logical. An argument against this is the fact that this would be
the first and so far only option.


>   | This would help with the broken DNS server only when you also
>   | create a kernel without IPv6 (so far we cannot disable IPv6
>   | link local addresses).
> 
> Ingolf already did the former, and it didn't help

The reasoning was: a special flag to getaddrinfo() would deduce
how names are translated from the network configuration, but
we need to rebuild the system for this. Rebuilding the kernel
alone obviously doesn't help, but it shouldn't be necessary
to control some other aspect of the system.

If you can make this a boot option instead this might be
useful to some, but see above that creating an automatic
dependency between getaddrinfo() behaviour and kernel
configuration is still questionable at least.

Following that logic the next might be to filter out
DNS answers that point to addresses that have no routing
table entry.


>   | So I propose /etc/addrinfo.conf with an associated environment
>   | variable ADDRINFO_CONF. And please paint it in pink.
> 
> I think resolv.conf is better, it is where resolver config goes, it
> already has the ability to specify options, and is a reasonable home
> for this kind of config.

Tell that the person who has to augment the parser and data structures
of the DNS resolver library for things controlling getaddrinfo().


> I also don't think we need an env var at all,

Very few people will consider it, it's more a debug help (like
MALLOC_OPTIONS) that can be used to override libc behaviour per
process.

I don't say we need it, but just took malloc as a model for how
to control a libc function. If we use this model then we might
want all of it for consistency.


> most applications already
> have options that say whether they should use v4 or v6 (defaulting to whatever
> works usually) and complicating that by adding yet another way wouldn't
> help, just make everything messier, after all, what is telnet (or anything)
> to do if you say "telnet -4 ..." when your ADDRINFO_CONF says "v6 only"
> (or vice versa).

It will behave correctly. Just like telnet -4 to a v6 only host:

henery% telnet -4 pussyfoot.ipv6.local
pussyfoot.ipv6.local: No address associated with hostname


Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."