On Tue, 2007-07-31 at 00:29 +0200, Tomas Pospisek wrote:
>
> I was trying to say that I had been bitten by the "libc's name resolver
> does by default an AAAA name lookup before it does an A lookup" before and
> am asking whether that's still a problem as [1] suggest that it was for
> Ubuntu at least until Dec 06 and whether someone can confirm it. As told I
> can not reproduce it on my systems any more since I removed ipv6 as soon
> as it started causing me trouble and as such cannot file a bug report
> against libc.
From reading this thread, and the Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828
in some detail it seems that the *primary* problem occurring where IPv6
is enabled is due to a combination of circumstances:
1) glibc does queries for AAAA records where "IPv6 enabled"
is only localhost or link local addresses.
2) many cheap routers / DSL modems / ... are broken, and
*ignore* AAAA queries entirely, rather than returning a
negative response.
To have problems with having the IPv6 module loaded *both* these
circumstances need to be true.
The first problem would appear to be solvable with the patch that
Tolleff wrote for glibc, ensuring that the AAAA queries don't occur
unless you are actually using the IPv6. It seems quite an elegant
approach, in fact, but perhaps I have misread it. The patch is here:
http://err.no/patches/glibc-only-lookup-ipv6-if-it-makes-sense.diff
no doubt this, or something like it, will make it's way into the
upstream code.
You can perhaps identify whether #2 is a problem for you personally
(without enabling IPv6), by doing AAAA queries against your router, your
ISP, and so on until you identify which one doesn't respond. You can,
of course, still do AAAA queries over IPv4, so you should get a response
from:
dig @192.168.1.1 AAAA andrew.mcmillan.net.nz
where you replace 192.168.1.1 with the actual IP address of your router.
If you get a timeout response from your router, but not from your ISP,
then you should perhaps look for new firmware from the manufacturer.
In recent glibc installations the second problem *can* also be worked
around by editing /etc/gai.conf to give the highest priority to IPv4
responses. This will mean that the call to the resolver will return
when it receives the IPv4 address, without waiting to see if a higher
priority address may yet be received.
> And arguably ipv6 is such a change (since it breaks applications). So
> arguing that applications don't "behave properly" or "behave wrong" is
> IMHO not correct. They break with ipv6 but not without. ipv6 is a new
> fundamental property of the system to deal with that came after the apps.
I think that IPv6 is something which is older than most applications,
though support for it is taking considerable time to roll out. As
others have pointed out there are many circumstances where IPv6 is
normal, and *disabling* it will also annoy people.
> Or one could ask why does Debian break perfectly well running systems by
> enabling a new feature?
When I upgrade a system from Sarge to Etch I don't blindly expect
everything to work. Minor upgrades, sure, but major ones? It would be
nice, but I'll watch closely just to be sure.
> You're right that it'd be good if the apps would get improved so that they
> gracefully deal with ipv6 too.
>
> But the question for me is: how high is the price? Does it mean that the
> part of the users that plug in the Debian install CD and happen to sit
> behind a ISP's DNS server that doesn't care about ipv6 will have
> multi-second lookup delays? Does it mean that one has to tweak every
> second daemon?
No it doesn't. What it *does* mean is that sometimes the problems with
a particular approach don't become obvious until they hit a wider
audience. Etch is released now, and we can't change the way it works
for *exactly* the reasons that you want us to: it would unexpectedly
break working systems. And it would be even worse, because we *promise*
not to make such changes during a stable release series.
What we *can* do, is uncover the problems, file bugs, identify solutions
and apply them in order to make the next major release a better product.
I certainly don't want to have Lenny *not* support IPv6 by default.
That would be a step backwards.
On the other hand I certainly don't want Lenny's IPv6 support to
inconvenience people behind broken DNS resolver infrastructure, no
matter how tempting it might be to say "Someone Else's Problem".
It seems to me that the patch Tolleff has written should remove that
inconvenience, so the effects of problem #2 will become invisible
(except to the poor people in such situations who try and actually use
IPv6 :-)
So rather than berating the release team about the goals for something
that has already happened, why not file a bug and attach the solution?
> Also have a look at:
>
> http://bugs.debian.org/343140
>
> And if you do also at RFC3484 wrt #343140.
The particular problem described at the start of this bug is mitigated
by the /etc/gai.conf mechanism which is already in Debian since at least
April. The bug report itself seems to have wandered off to never-never
land of discussing the exact meanings of various specifications.
Regards,
Andrew McMillan.
-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267
Facts do not cease to exist because they are ignored.
-- Aldous Huxley, "Proper Studies", 1927
-------------------------------------------------------------------------
Attachment:
signature.asc
Description: This is a digitally signed message part