Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 2 Nov 2002 14:41:05 +0000
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        freebsd-questions@FreeBSD.ORG
Subject:   Re: Resolving hostnames takes "forever"
Message-ID:  <20021102144105.GA1116@happy-idiot-talk.infracaninophi>
In-Reply-To: <200211021432.19756.freebsd.nospam@mekanix.dk>
References:  <200211021432.19756.freebsd.nospam@mekanix.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 02, 2002 at 02:32:19PM +0100, Bjarne Wichmann Petersen wrote:

> I've got an annoying problem when surfing. The browsers (both konq. and 
> phoenix/mozilla) needs a very long time (30-60 sec.) to resolve hostnames and 
> I'm out of clues to why. My setup is something like:
> 
> Cable-modem -> Router (speedstream 2601) -> switch -> FBSD-box
> 
> I've enabled "Hostmapping" in the router to point to my FBSD-box. My firewall 
> denies no packages. /etc/resolv.conf shows the the correct IP's for the 
> nameservers.

The first thing you need to do to track down the problem is to trace
the DNS queries your system makes while you attempt to browse the net.

Supposing that your ethernet interface is fxp0, then you need to run
commands like the following:

    # tcpdump -i fxp0 port 53 -w /tmp/dns-packets 
        [ do some browsing in another window, then hit Ctrl-C ]

This will record all the DNS traffic in the file in /tmp.  You can
view the transactions by:

    # tcpdump -r /tmp/dns-packets

The reason for not just reading the DNS traffic directly is that
tcpdump tends to generate and pick up it's own DNS traffic, which
tends to lead to a massive feedback loop.

You will see something like this:

    happy-idiot-talk:/home/matthew:# tcpdump -r /tmp/dns-traffic
    14:07:37.213359 happy-idiot-talk.infracaninophile.co.uk.1024 > ns1.thdo.bbc.co.uk.domain:  17249 [1au] AAAA? www.bbc.co.uk. (42)
    14:07:37.232462 ns1.thdo.bbc.co.uk.domain > happy-idiot-talk.infracaninophile.co.uk.1024:  17249 FormErr-% [0q] 0/0/0 (12) (DF)
    14:07:37.232633 happy-idiot-talk.infracaninophile.co.uk.1024 > ns1.thdo.bbc.co.uk.domain:  11354 AAAA? www.bbc.co.uk. (31)
    14:07:37.259156 ns1.thdo.bbc.co.uk.domain > happy-idiot-talk.infracaninophile.co.uk.1024:  11354- 1/13/13 CNAME[|domain] (DF)
    14:07:37.259790 happy-idiot-talk.infracaninophile.co.uk.1024 > ns0.thdo.bbc.co.uk.domain:  38445 AAAA? www.bbc.net.uk. (32)
    14:07:37.277551 ns0.thdo.bbc.co.uk.domain > happy-idiot-talk.infracaninophile.co.uk.1024:  38445*- 0/0/0 (32) (DF)
    14:07:37.278683 happy-idiot-talk.infracaninophile.co.uk.1024 > ns0.thdo.bbc.co.uk.domain:  43751 A? www.bbc.net.uk. (32)
    14:07:37.300223 ns0.thdo.bbc.co.uk.domain > happy-idiot-talk.infracaninophile.co.uk.1024:  43751*- 1/0/0 A www21.thdo.bbc.co.uk (48) (DF)
    14:07:37.952371 happy-idiot-talk.infracaninophile.co.uk.1024 > ns1.thdo.bbc.co.uk.domain:  12930 AAAA? news.bbc.co.uk. (32)
    14:07:38.260928 ns1.thdo.bbc.co.uk.domain > happy-idiot-talk.infracaninophile.co.uk.1024:  12930- 1/13/13 CNAME[|domain] (DF)
    14:07:38.261551 happy-idiot-talk.infracaninophile.co.uk.1024 > ns0.thdo.bbc.co.uk.domain:  19630 AAAA? newswww.bbc.net.uk. (36)
    14:07:38.284503 ns0.thdo.bbc.co.uk.domain > happy-idiot-talk.infracaninophile.co.uk.1024:  19630*- 0/0/0 (36) (DF)
    14:07:38.300385 happy-idiot-talk.infracaninophile.co.uk.1024 > ns0.thdo.bbc.co.uk.domain:  37743 A? newswww.bbc.net.uk. (36)
    14:07:38.330831 ns0.thdo.bbc.co.uk.domain > happy-idiot-talk.infracaninophile.co.uk.1024:  37743*- 1/0/0 A 212.58.226.30 (52) (DF)
    14:07:38.359932 happy-idiot-talk.infracaninophile.co.uk.1024 > h.gtld-servers.net.domain:  18008 AAAA? server-uk.imrworldwide.com. (44)
    14:07:38.431801 h.gtld-servers.net.domain > happy-idiot-talk.infracaninophile.co.uk.1024:  18008- 0/2/2 (120)
    14:07:38.432311 happy-idiot-talk.infracaninophile.co.uk.1024 > 62.189.244.232.domain:  53753 [1au] AAAA? server-uk.imrworldwide.com. (55)
    14:07:38.660494 62.189.244.232.domain > happy-idiot-talk.infracaninophile.co.uk.1024:  53753* 0/1/1 (121)
    14:07:38.661695 happy-idiot-talk.infracaninophile.co.uk.1024 > 203.166.18.106.domain:  24698 [1au] A? server-uk.imrworldwide.com. (55)
    14:07:38.994836 203.166.18.106.domain > happy-idiot-talk.infracaninophile.co.uk.1024:  24698* 1/2/3 (147)

You'll see that your web browsers make quite a few attempts to lookup
IPv6 AAAA addresses.  This is according to the current standards, but
in most sites won't achieve very much.  Unfortunately, some sites are
still running broken DNS software that doesn't respond correctly to
AAAA requests, resulting in your DNS client hanging for 30s or so
before it tries an IPv4 A request.  It's particularly bad if the
caching nameservers at your ISP are broken in this way.

Use the timestamps in the first column to pinpoint exactly where the
delay is occurring.  Then try to replicate the problem by performing
the same lookup using dig:

    # dig www.bbc.co.uk IN AAAA
    
    ; <<>> DiG 8.3 <<>> www.bbc.co.uk IN AAAA 
    ;; res options: init recurs defnam dnsrch
    ;; got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
    ;; QUERY SECTION:
    ;;      www.bbc.co.uk, type = AAAA, class = IN
    
    ;; ANSWER SECTION:
    www.bbc.co.uk.          18m18s IN CNAME  www.bbc.net.uk.
    
    ;; Total query time: 26 msec
    ;; FROM: happy-idiot-talk.infracaninophile.co.uk to SERVER: default -- 127.0.0.1
    ;; WHEN: Sat Nov  2 14:19:19 2002
    ;; MSG SIZE  sent: 31  rcvd: 57

(Note, I'm running my own DNS cache here, which is why the default
server is on localhost)

Now, tools like dig and tcpdump have many more options than there is
space to discuss here and interpreting the results can be an artform
in it's own right.  However, these methods should let you narrow down
what and where the problem is.  It's also exactly the sort of evidence
you should pass to any support line or DNS admin if you think the
problem is at their end.

One other thing: try temporarily turning off any web cache you may
have configured in your browsers, if you can.  Just to eliminate that
as a possible cause of the delay.  If you are with an ISP that
implements a transparent web cache, then of course, you can't do that.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
                                                      Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021102144105.GA1116>