Date: Wed, 24 Jul 2002 20:33:41 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: jinmei@isl.rdc.toshiba.co.jp Cc: dl-freebsd@catspoiler.org, net@FreeBSD.ORG Subject: Re: disabling IPv6 *without* recompiling the kernel Message-ID: <200207250333.g6P3Xfwr052669@gw.catspoiler.org> In-Reply-To: <y7vr8htgqex.wl@ocean.jinmei.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24 Jul, JINMEI Tatuya / ^TÉ wrote: >>>>>> On Sat, 20 Jul 2002 20:33:10 -0700 (PDT), >>>>>> Don Lewis <dl-freebsd@catspoiler.org> said: > >> I've run into the same problems with Mozilla that many other people have >> reported. > > (...snip) > > Thanks for the careful check and suggestions. I think we should take > them seriously. But before that, please let me check something: > >> Even though I'm on an IPv4 only network, I'm seeing DNS >> lookups for AAAA records, many of which are timing out due to problems > > Does the DNS servers have A records for the same name? Yes. > If so, it > should not take a long time out to resolve the corresponding AAAA > records. The authoritative server should just return a response with > the empty answer section. Or, are you talking about an unreachable > server that even cannot return the A records, and the AAAA query > doubles the total delay? The problem I'm seeing is with servers that return answers for A record queries, but seem to totally ignore queries for AAAA records. % dig vanguard.com ns ; <<>> DiG 8.3 <<>> vanguard.com ns ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0 ;; QUERY SECTION: ;; vanguard.com, type = NS, class = IN ;; ANSWER SECTION: vanguard.com. 4H IN NS ns2.vanguard.com. vanguard.com. 4H IN NS ns3.vanguard.com. vanguard.com. 4H IN NS ns.vanguard.com. ;; AUTHORITY SECTION: vanguard.com. 4H IN NS ns2.vanguard.com. vanguard.com. 4H IN NS ns3.vanguard.com. vanguard.com. 4H IN NS ns.vanguard.com. ;; Total query time: 150 msec ;; FROM: gw.catspoiler.org to SERVER: default -- 192.168.101.1 ;; WHEN: Wed Jul 24 20:17:46 2002 ;; MSG SIZE sent: 30 rcvd: 137 % dig www.vanguard.com a @ns.vanguard.com ; <<>> DiG 8.3 <<>> www.vanguard.com a @ns.vanguard.com ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; www.vanguard.com, type = A, class = IN ;; ANSWER SECTION: www.vanguard.com. 0S IN A 192.175.173.8 ;; AUTHORITY SECTION: www.vanguard.com. 4H IN NS wsdds2.vanguard.com. www.vanguard.com. 4H IN NS wsdds1.vanguard.com. ;; ADDITIONAL SECTION: wsdds1.vanguard.com. 4H IN A 192.175.173.5 wsdds2.vanguard.com. 4H IN A 192.175.182.5 ;; Total query time: 122 msec ;; FROM: gw.catspoiler.org to SERVER: ns.vanguard.com 192.175.173.31 ;; WHEN: Wed Jul 24 20:23:18 2002 ;; MSG SIZE sent: 34 rcvd: 124 % dig www.vanguard.com aaaa @ns.vanguard.com ; <<>> DiG 8.3 <<>> www.vanguard.com aaaa @ns.vanguard.com ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_nsend to server ns.vanguard.com 192.175.173.31: Operation timed out Eventually the resolver seems to give up on the AAAA query and tries an A record query, but it can take a *long* time. Even after Mozilla discovers the IPv4 address, it seems to time out this information after a while and later accesses to a web site may get stuck looking up the IP address again. Even when things are working correctly, doubling the DNS lookup time could be painful for users with slow network connections. > Some DNS servers behave very badly; they responds to AAAA queries with > the NXDOMAIN code, and, as a result, suppress further queries even > when they have an A record. We should fix such servers, but, IMHO, > we do not have to change the resolver side behavior just due to this. I haven't seen this problem. >> I'm also seeing long pauses when >> Mozilla attempts to connect to various web sites which I suspect are >> caused by Mozilla's attempts to connect to unreachable IPv6 addresses. > > Regarding this issue, what do you mean by "an IPv4 only network"? > More specifically, > > - do you have any non-link-local IPv6 addresses? No. > - do you have an IPv6 default router? No. > If the answer is "no" for both, then the connection attempts to the > IPv6 destinations should immediately fail with EHOSTUNREACH and the > delay should not matter in usual operation. > > So, basically even if you have some link-local IPv6 addresses and the > IPv6 loopback address, neither of the AAAA queries nor the connection > attempts to IPv6 destinations should matter. If you saw exceptions, > I'd like to know more details. Unfortunately I don't have any trace information that might point out the cause. All I know was that I was sometimes seeing some very long pauses (tens of seconds or more) in Mozilla, and the status line at the bottom of the Mozilla window said it was attempting to connect. Both problems went away when I hacked my copy of the Mozilla source to cause it to always fail the IPv6 test. If I can find some spare time I'll turn the IPv6 stuff back on and look at the second problem some more. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207250333.g6P3Xfwr052669>