NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



ingolf.steinbach%googlemail.com@localhost (Ingolf Steinbach) writes:

>Please excuse my naive question: Why would the resolver want to issue
>AAAA queries at all when it could (for example by investigating some
>/kern setting) determine that the v6 will be useless?

With the same argument you could say that a 'nslookup' or 'dig'
should fail to query AAAA records when your kernel cannot handle
IPv6.

getaddrinfo() is pretty agnostic. You tell it you want IPv4, you get
IPv4. You tell it you want IPv6, you get IPv6. You don't tell it anything,
you will get either.

getaddrinfo() is only used by programs that can handle IPv6 and that
should handle a fallback to other addresses including IPv4. This is
not a problem for most people. If the machine has no IPv6 connectivity
then the IPv6 address returned by getaddrinfo() will fail immediately
and the next adress is used.

It is a problem for people with a broken IPv6 setup. I.e. the machine
is configured for an IPv6 network but the network doesn't function
because of things like unstable tunnels or unreliable ipv6 providers.

The solution is: change provider/tunnel or don't configure your host
for IPv6.

It is also a problem for a much smaller group (like you) with a broken
DNS server that fails to answer AAAA queries correctly.

The solution is: junk that broken DNS server.


We are here just talking about workarounds. Workarounds shouldn't
happen automatically. If you are in a situation where you need the
workaround, you should make the decision to enable it.

I don't think that such a workaround should depend on the kernel
because the need for the workaround has little to do with the kernel
and the functionality that needs to be adjusted is embedded in
libc.

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.

- an environment variable would be sufficient for me but there
  are issues to make this a system wide setting. There are always
  other parties that tweak the environment and break such a setup.

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

- 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? :)

- a new file/symlink like /etc/malloc.conf (which BTW is the system
  wide configuration for something controlled by an environment
  variable).

- something else.

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.
Solaris sorts the answers according to RFC3484.

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). IMHO this is too complex, in particular
because you can easily run a default kernel (with IPv6) in
an IPv4-only environment. It also relies on all programs
doing the right thing and use a system-specific flag.

So I propose /etc/addrinfo.conf with an associated environment
variable ADDRINFO_CONF. And please paint it in pink.

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


Home | Main Index | Thread Index | Old Index