At Sat, 5 Dec 2009 09:10:07 +0000 (UTC), mlelstv%serpens.de@localhost (Michael
van Elst) wrote:
Subject: Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before
T_AAAA lookups, was: Resolver problems
>
> So please, add a knob to control libc behaviour.
>
> - sysctl is out of the question. It controls kernel behaviour and
> the kernel shouldn't be a storage for configuration data.
I don't believe that -- in fact I think it's flat-out-wrong for at least
two cases now and for as long as sysctl has existed. Consider
"kern.hostname" and "kern.domainname". Their values are not used
anywhere else in the kernel (except for the relatively recent
introduction of symlink substitution magic) and yet the kernel stores
them (mostly) on behalf of userland via their sysctl values.
But in any case the key trigger here is the question of whether the
kernel is, or is not, supporting IPv6 so it makes sense for libc to use
a sysctl to learn this fact from the kernel and thus behave sanely in
either the presence or absence of kernel support for IPv6.
In fact if the kernel gains the sysctl feature already discussed in this
thread to dynamically control it's protocol support (and I hope it does)
then a sysctl with the necessary configuration information will come
into existence anyway, so I think it would be ideal for libc to make use
of it.
> - resolv.conf is not my first choice, because this is used by
> the resolver code, not the high level functions like getaddrinfo().
> But since there already is a bit that controls the resolver library
> in a similar way, this might be an option. The particular bit
> (RES_USE_INET6) however, has a completely different meaning
> because it is supposed to return IPv4 adresses as IPv6 adresses
> to simplify application code.
Indeed -- it would make more sense to add a new resolv.conf option that
could be additionally used to restrict libc from asking for IPv6
addresses even if the kernel does (claim to) support IPv6.
> Solaris has an AI_ADDRCONFIG flag to getaddrinfo() that filters
> according to the current configuration of the machine. If it has
> IPv6 configuration, then IPv6 addresses are queried. If it has
> IPv4 configuration, then IPv4 addresses are queried. My guess
> is that the system utilities all specify this flag.
OK, so how the heck does libc determine the current configuration of the
machine for the purpose of this feature? Perhaps it has to use a
sysctl? :-)
Also that kind of features doesn't seem to be very API/ABI friendly.
It seems glibc also supports AI_ADDRCONFIG, but various discussions I've
read about it suggest it's not well liked and folks don't think it is as
useful as they had hoped -- clearly at this level it's something that
the application shouldn't really have to be aware of and then be forced
to always use if/when it's available. It really does cause an enormous
API/ABI mess, a load of portability problems, and confusion for all
programmers who use getaddrinfo(). Witness the 59,000+ results for
searching for it on Google, many of them pointing at posts about these
issues, and many more pointing at patches to code which now have to use
this flag by default. If all applications are going to use it by
default anyway then it should be the default all the time.
I think this is the worst idea possible.
> 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).
and in the case our kernel gains dynamic protocol control sysctls....
> So I propose /etc/addrinfo.conf with an associated environment
> variable ADDRINFO_CONF.
I think that's the second worst idea possible. Well, maybe not actually
worse than the symlink idea -- but equally bad. This is gratuitous
replication of information in yet another newly invented configuration
mechanism (and one that at least for now appears to be single-purpose).
> And please paint it in pink.
That would indeed be _necessary_ :-)
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgphR0qVbG0Bv.pgp
Description: PGP signature