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:        Thu, 03 Dec 2009 15:13:28 -0800
    From:        Chuck Swiger <cswiger%mac.com@localhost>
    Message-ID:  <42608C26-262F-4D8D-A726-0C5829892128%mac.com@localhost>

  | Yes, it might.  I've yet to see a situation where that actually
  | was the case, however, but it's conceivable.

I certainly have, I haven't seen it in the past 6 months or so, but
before that, NAT table full was a daily occurrence (you stick a university
behind a single NAT router, and no matter how big the router's tables
are, the students will manage to fill them up...)   On the other hand, IPv6
simply works, almost always - the vast majority of the e-mail I actually read
I receive via IPv6 (as distinct from the vast majority of e-mail I receive,
which comes via IPv4, and mostly goes straight to the bit bucket).

  | A few years back, when I was [...] (this was in metro NYC area),

Yes, as I understand it, in much of the US, you're still pretty much
living in the past - outside the US, at least in some areas, things are
much much better (and it seems to be improving inside the US too, at
least a little.)

  | For that matter, with 0.16% of routable networks IPv6-only,
  | 5.29% dual-protocol capable, and 94.54% of IPv4-only, I don't feel it
  | is arbitrary to choose to perform A before AAAA by default.

It depends whether you want to plan for the future or not - what you're
distributing now is likely to still be running 4, 5, or more, years from
now, and then the v4 first policy might start being backwards.

It sounds as if FreeBSD took the chicken way out - as in, we know we're
right, and what we are doing is OK, and the fault is with some other
site(s), but we cant fix them, we can only change us, and we look better
if we hide their problem, so let's do that...

Personally, I prefer to emphasise the faults, get complaints, direct the
complaints to where the problems really are (like the bogus router with
the broken DNS proxy that (re-)started this discussion, in the past day or so)
so that there's a better chance of getting the real problems fixed (after
all, the people with the ads want their ads seen, unlike some others who
simply don't care, they have an incentive to fix things, if they're informed
by enough people that they are broken).

On the other hand, I certainly agree that if an IPv6 address would not be
useful at all (if you're running a kernel with no IPv6 support) then it
is pointless asking for one (unless explicitly requested by the application),
and if others agree, I'd certainly be willing to make and submit a patch
that would turn off the AAAA query when the running kernel doesn't support
using the returned address (that's not all that difficult to achieve).

The same patch, would, of course, turn off the default A query if the
running kernel doesn't support IPv4 (again, if the application doesn't
explicitly request it).   That's not likely to be noticed by anyone in the
immediate future, but a little further away, it might help a bit, and it
is also the right thing to do.

I also have patches to the kernel to allow protocol support to be dynamically
turned on/off, so it isn't necessary to recompile the kernel to disable
IPv6 (or IPv4, or in theory anything else, but no-one really cares about
the others any more anyway.)   Naturally, you can't enable a protocol that
way if it wasn't compiled into the kernel initially (this isn't LKM's
or anything...) but it is trivial to disable one, or re-enable it again.

A few applications have problems with the and need application config
updates (sendmail likes to bitch if it is configured to use IPv6, and
then can't get an IPv6 socket, for example) but most stuff just works
fine (if the protocol is disabled after an application has grabbed sockets
using it, it is optional whether those sockets get to continue working,
or whether they all just hang - as in no more data in/out - that is the
normal operation is just to prevent creating of a socket in the disabled
protocol, but let everything else operate normally - but it is also possible
to block packet sending/reception, and if I remember correctly, to block
packets except those on established TCP connections, so an incoming SYN
would be blocked, but existing connections get to run to completion - and
for blocked packets, whether they're treated as "this protocol is unknown
here" (ie: the incoming packet is simply discarded) or "this protocol is
known but no-one wants it" (ie: a TCP RST, or ICMP port unreachable, as
appropriate, is returned).

Full support for this is only for the IP protocols, disabling something like
appletalk would prevent a socket being created, but none of the other hooks
are in the code I have to do more than that (I don't even recall if anything
got added to create the sysctl nodes for protocols other than IP to allow
the disable to happen - though fixing that would be trivial, or trivial
multiplied by N protocols.)

If this stuff looks useful, I'll find it, and upgrade it to current current
(it was done a couple of years ago). and send it someplace...

kre