Date: Fri, 2 May 2003 03:01:15 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: bsder@allcaps.org Cc: daniel+bsd@pelleg.org Subject: Re: IPv6 Resolver (or: Slow rendering of Webpages using Konqueror) Message-ID: <200305021001.h42A1FM7015060@gw.catspoiler.org> In-Reply-To: <Pine.LNX.4.44.0305011620270.14590-100000@mail.allcaps.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1 May, Andrew P. Lentvorski, Jr. wrote:
> On 1 May 2003, Dan Pelleg wrote:
>
>> For me, running linux-mozilla under the Linux emulation "solved" the
>> problem. IIRC there was a discussion either here on on questions@ regarding
>> this a few months ago. I didn't follow the details, but I think the problem
>> was determined to be in libc.
>
> Okay, there are several things being mushed together here. Let me see if
> I can sort them out:
>
> 1) ad.doubleclick.net doesn't handle AAAA requests properly
>
> Solution: complain to ad.doubleclick.net
>
> 2) There is no global way to make IPv6 go away in kernel, world, and ports
>
> This seems to be a FreeBSD bug. The intent with the ability to remove
> IPv6 from the kernel config and set ipv6_enable to no would seem to
> indicate that somebody wants to be able to shut off IPv6. The fact that
> the resolver still executes an IPv6 request would appear to be breakage.
I'm pretty sure that removing INET6 from the kernel configuration will
"fix" the performance problem. Both the resolver code in the FreeBSD
libc and the Mozilla source seem to execute
socket(AF_INET6, SOCK_STREAM, 0)
to decide whether or not to do AAAA lookups. If INET6 is removed from
the kernel configuration, this socket() call will fail, and the resolver
will skip the AAAA lookups.
Reconfiguring, rebuilding, and reinstalling the kernel seems like too
much of a burden for casual users. Think of a reviewer writing an
article for the typical computer rag. If it doesn't work well right out
of the box, they probably won't spend a lot of time futzing around with
things and we'll get poor reviews.
> 3) Mozilla/Konquerer/whatever completely hangs during the timeout period
> on the AAAA record request
>
> *Whose* bug is this? Is this a FreeBSD bug or a Gecko bug? Or both?
> And, if it is a FreeBSD bug, where is the bug? The main dns resolver or
> the ports makefile?
Mozilla is using a wrapper around the resolver code which can use
various vintages of library resolver routines, such as gethostbyname(),
gethostbyname2(), getipnodebyname(), etc., or built-in implementations
of these. It's very difficult to figure out what is actually happening
because of the mass of cpp macros and #ifdefs. If Mozilla uses
gethostbyname() and gethostbyname2(), it will do the lookups
sequentially, and do the AAAA lookup first.
The wrapper has it's own emulation of the getipnodebyname()
AI_ADDRCONFIG flag, and it also passes this flag to getipnodebyname() if
it decides to use that library routine. This would do the "right" thing
except for one little problem ... The man page for getipnodebyname()
says:
o The AI_ADDRCONFIG flag specifies that a query for AAAA records should
occur only if the node has at least one IPv6 source address config-
ured and a query for A records should occur only if the node has at
least one IPv4 source address configured.
The problem is that there presently isn't a knob to totally eliminate
IPv6 interface addresses other than rebuilding the kernel without INET6.
By default, all the network interfaces are configured with IPv6
link-local addresses if the kernel was built with the INET6 option.
This even happens if the obvious ipv6_enable rc.conf knob is set to
"NO". At least in 4-stable there is a way to mostly get rid of the IPv6
link-local addresses. If you set the obscure
net.inet6.ip6.auto_linklocal sysctl variable to 0 in /etc/sysctl.conf,
link-local addresses won't be assigned to the network interaces at boot
time with one exception. The exception is lo0, which seems to get a
link-local address assigned no matter what. This is in contrast to its
IPv4 address, which doesn't get configured unless lo0 is listed in the
network_interfaces rc.conf variable (or if network_interfaces is set to
"auto").
Without a way of avoiding the configuration of IPv6 link-local addresses
on *all* the network interfaces, AI_ADDRCONFIG will cause AAAA queries
to be sent in the common case of a host that doesn't have IPv6
connectivity, and even worse, the AAAA query will be sent before the A
query.
I believe that if we could prevent the IPv6 link-local addresses from
being assigned in the ipv6_enable=NO case that Mozilla and our libc
resolver code would automagically do the right thing. That would solve
this problem for most people but not all. It would also improve the
performance for people who only have IPv4 connectivity, since the AAAA
query would be skipped and one RTT would be avoided when fetching the A
record from the DNS server, and it would avoid a attempt to make an IPv6
network connection if the server actually has an IPv6 address.
People who want to enable IPv6 support would still run into problems
when they encounter broken DNS servers. The solution to this problem is
to implement a better resolver library that can do both queries in
parallel when both IPv4 and IPv6 are enabled. This would also improve
the performance in the common case of accessing an IPv4 only server even
when the DNS server functions correctly and returns the proper response
to the initial AAAA request, since one RTT would be avoided in fetching
the the A record.
> 4) How is anyone short of guru status supposed to connect "Mozilla chokes
> on FreeBSD" with "the DoubleClick DNS server config is broken"?
>
> If this behavior is indeed deemed "not a bug", then some piece of
> prominent documentation needs to explain this for idiots like me.
>
> Have I missed anything? I am asking these questions so that I can file
> the appropriate bug reports.
>
> Thanks,
> -a
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305021001.h42A1FM7015060>