At Sun, 6 Dec 2009 08:39:40 +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
>
> woods%planix.com@localhost ("Greg A. Woods") writes:
>
> >> - 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.
>
> That doesn't make it a good thing.
I think that's a rather specious argument -- at least it is without
valid and relevant points showing why you think it is so.
Here kern.hostname is an example of how sysctl can be used to replace
custom system calls, such as gethostname(2), here moving a former
stand-alone special-purpose system call into a common framework intended
for storing and managing system configuration items.
In other cases sysctl eliminates the need for creating new system calls
when the goal is to reduce or eliminate the need for regular operational
access to /dev/kmem.
The sysctl function retrieves system information and allows processes
with appropriate privileges to set system information.
So, to the extent that some kind of configuration data is "system
information", i.e. referring to kernel information, it can, and very
likely should, be stored and retrieved through sysctl.
My point of referring to kern.hostname was to show that even that value
useful enough to be stored and retrieved through sysctl. In comparison
the information about IPv6 (or any other protocol) usability is even
more relevant as kernel information -- indeed it can even be a compiled
in value which is not ever set from user-land, nor consistently in
existence anywhere in user-land.
In both cases however reference to the value may be frequent enough that
"caching" it in the kernel and retrieving it from there with sysctl is
indeed highly desirable, both from a reliability and availability
standpoint, as well as from an efficiency standpoint.
> Controlling the name resolution however has nothing to do with
> the kernels capabilities of handling IPv6 traffic.
You seem to have missed the _requirements_ which started the whole
thread from which this PR sprung to life.
Indeed it is the kernel's configuration w.r.t. handling of IPv6 traffic
(including perhaps whether or not there are any IPv6 addresses
configured on any interfaces, separate from, but also related to,
whether or not the kernel itself can support IPv6 traffic) is VERY MUCH
a determining factor on whether or not the _DEFAULT_ action of various
libc interfaces, including getaddrinfo(3), should be to look first for
AAAA records, or whether only A records should be queried for BY DEFAULT.
> The name
> resolution can be used and is used for other things than
> binding sockets and the kernel is perfectly capable of telling
> the application that one or the other address family is not
> usuable for a network connection.
Indeed, which is why I and others have practically been screaming that
the desire here is only to affect the _DEFAULT_ behaviour.
Take a look at my sample patch attached to this PR for an example of how
this _DEFAULT_ behaviour based on the compile-time INET6 option.
Nothing in my patch prevents any application from making a specific
request for AAAA records on demand. Indeed on my system which is
compiled without MKINET6 or USE_INET6 being defined in either kernel or
user-land I can still ask for, and successfully retrieve IPv6 addresses
from the DNS:
$ host -t AAAA www.netbsd.org
www.netbsd.org AAAA 2001:4F8:3:7:2E0:81FF:FE52:9A6B
> After all, we are talking about a workaround for systems with
> a broken environment and not about a gimmick for IPv6 haters.
> Do we?
No, in fact we are not -- at least not so long as NetBSD continues to
ship systems configured by default in such a way that they would not
function in the most optimal fashion in some large number of
environments where they are expected to work optimally.
In fact this is a classic catch-22 situation as choosing either action
by default causes non-optimal behaviour for some (significant) group of
users.
As many have called for already in this discussion, the best compromise
is to create a user configuration item which can be adjusted at runtime
to best suite the local environment.
I think most people in this discussion have also agreed that it is not
optimal for NetBSD to try to retrieve use addresses _BY_ _DEFAULT_ which
cannot possibly "work" for _normal_ use in a given runtime environment.
Note how my argument can be used for either IPv4-only or IPv6-only
environments.
> >in yet another newly invented configuration
> >mechanism (and one that at least for now appears to be single-purpose).
>
> It isn't newly invented. It is used by malloc().
It would be "newly invented" in the sense that it is yet another unique
source of configuration information.
Indeed the technique would not be newly invented, but the symlink itself
would, necessarily, have to be a newly invented configuration item
separate from anything else relevant or related in the whole system as
it stands today.
Inventing a new symlink for this configuration item would be wrong.
Such information should be integrated with the most relevant current
information source for related items.
A new option flag in /etc/resolv.conf would be one relevant current
source of related configuration items. Here we have to be very careful
how we define this flag and its intended behaviour since, as we agree,
we do not want to limit libc or any applications from making explicit
queries for records of a given type.
A node somewhere in the sysctl tree would be another relevant current
source of related configuration items. Here we could give total
discretion to libc (and any applications) on how this information would
be used, and of course we would design at least libc in such a way that
it only used this information to decide which record type to query for
BY DEFAULT when a hostname is looked up.
/etc/nsswitch.conf would not really be relevant because the
configuration items it presents are indeed unrelated in that they exist
at a different level and for a different purpose. nsswitch doesn't
really deal with different address families for a single information
type -- it deals only with different information types and their
sources. Any information source for hostnames could, should, and must,
provide, or at least be able to provide, all relevant records for all
relevant address families for a given hostname.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpArlkCJpPCx.pgp
Description: PGP signature