Re: Question about name resolution delay when using lynx
- From: Mark South <mark.south@xxxxxxxxxxxx>
- Date: 3 Oct 2007 09:18:35 +0200
On Wed, 03 Oct 2007 06:42:15 +0000, Joachim Schipper wrote:
Mark South <mark.south@xxxxxxxxxxxx> wrote:
On Tue, 02 Oct 2007 20:49:26 +0000, Joachim Schipper wrote:
Do you use a DNS server that does not reply to AAAA queries, or
somesuch?
Nope. I don't have IPv6 connectivity, BUT, if the DNS system has a AAAA
record I do see it returned. The two situations go like this:
1. No AAAA record: system waits for AAAA record, times out, asks for A
record, receives A record, hits IP address.
2. Has AAAA record: system gets AAAA record immediately, recognises there
is no IPv6 route, requests A record, gets A record, and hits IP address.
(***) Amazingly, tcpdump shows lynx requesting AAAA records repeatedly at
longer and longer intervals. After a couple of minutes, it finally occurs
to it to ask for an A record. It gets the A record, and then _requests_
_the_ _AAAA_ _record_ _again_. It only uses the A record under the most
extreme duress. So if I try to use
lynx www.openbsd.org
to read the FAQ pages from a fresh install, I get no luck: each page goes
through the same rigmarole. But nslookup falls back from AAAA to A very
quickly, so I can surf the site at lightning speed with
lynx `nslookup www.openbsd.org`
...until I hit an offsite link, of course.
Yes, that's what I thought - a DNS server that doesn't reply *at all* to
AAAA queries.
But I _do_ get AAAA records back for sites that _have_ AAAA records: like I
said, mirror.switch.ch is an example.
Requesting AAAA first is `normal', but should look like
this:
# tcpdump -vvvi rl0 port 53
08:26:48.858043 192.168.14.2.40881 > 194.134.5.5.53: [udp sum ok] 48832+ AAAA? www.openbsd.org. (33) (ttl 64, id 35529, len 61)
08:26:49.060141 194.134.5.5.53 > 192.168.14.2.40881: 48832 q: AAAA? www.openbsd.org. 0/1/0 ns: openbsd.org. SOA[|domain] (ttl 56, id 56031, len 116)
08:26:49.060303 192.168.14.2.47125 > 194.134.5.5.53: [udp sum ok] 54736+ A? www.openbsd.org. (33) (ttl 64, id 36284, len 61)
08:26:49.068205 194.134.5.5.53 > 192.168.14.2.47125: [udp sum ok] 54736 q: A? www.openbsd.org. 1/0/0 www.openbsd.org. A 129.128.5.191 (49) (ttl 56, id 56363, len 77)
08:26:49.089734 192.168.14.2.15802 > 194.134.5.5.53: [udp sum ok] 43610+ AAAA? www.openbsd.org. (33) (ttl 64, id 42136, len 61)
08:26:49.099192 194.134.5.5.53 > 192.168.14.2.15802: 43610 q: AAAA? www.openbsd.org. 0/1/0 ns: openbsd.org. SOA[|domain] (ttl 56, id 56071, len 116)
08:26:49.099297 192.168.14.2.7971 > 194.134.5.5.53: [udp sum ok] 33019+ A? www.openbsd.org. (33) (ttl 64, id 41346, len 61)
08:26:49.294026 194.134.5.5.53 > 192.168.14.2.7971: [udp sum ok] 33019 q: A? www.openbsd.org. 1/0/0 www.openbsd.org. A 129.128.5.191 (49) (ttl 56, id 34403, len 77)
That's pretty much what I get. (Sorry, not on an OpenBSD machine at the
moment). Except with lynx, the dialogue is far longer because it does not
easily give up requesting AAAA records.
That is, any AAAA record should return an immediate `no-such-domain'
response (0/1/0 means `0 records found, I have final authority to say
so, 0 additional records added'; 1/0/0 means `1 record found, there is
another server that has final authority, 0 additional records added').
It appears this is not happening in your case, which would indeed cause
timeouts. In other words, your ISP has a broken setup, but might be
willing to fix this for you.
I'll take the suggestion and talk to them, even though I'm pretty sure
that I'm going to get the "it's not our fault if they don't have AAAA
records" kind of repsonse....
If they are not willing, and you can find some DNS server that will
correctly answer your queries, use that. I suppose there must be some on
the whole wide internet.
I shall have a look. Sadly, this will bust my (otherwise working very
well) DHCP setup.
If this is the case, you might want to look into setting up a
local DNS server that immediately replies with 'no such domain' to AAAA
queries, although that's not quite the right solution.
Heh. That's not a bad idea (thus proving that something can be a totally
evil kludge and not a bad idea at the same time :-) and I will give it a
try some time.
If you cannot find a non-broken DNS server, this hack might work. I
cannot find any obvious way to make BIND do that, though.
Thanks once more for looking.
Mark
--
signature: no route to host
.
- Follow-Ups:
- Re: Question about name resolution delay when using lynx
- From: Steve at fivetrees
- Re: Question about name resolution delay when using lynx
- From: Joachim Schipper
- Re: Question about name resolution delay when using lynx
- References:
- Re: Question about name resolution delay when using lynx
- From: Joachim Schipper
- Re: Question about name resolution delay when using lynx
- From: Mark South
- Re: Question about name resolution delay when using lynx
- From: Joachim Schipper
- Re: Question about name resolution delay when using lynx
- Prev by Date: Re: Question about name resolution delay when using lynx
- Next by Date: ksh command line problem
- Previous by thread: Re: Question about name resolution delay when using lynx
- Next by thread: Re: Question about name resolution delay when using lynx
- Index(es):
Relevant Pages
|
Loading