Re: Question about name resolution delay when using lynx

On Wed, 03 Oct 2007 19:51:28 +0000, Joachim Schipper wrote:

Mark South <mark.south@xxxxxxxxxxxx> wrote:
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.

But you should get a response even for sites that do not have AAAA
records; your story (and particularly point 1) made me wonder if your
DNS server did that.

The transaction logs show that when there is no AAAA record, no response
is received. (See below.) The sheer persistence of some applications
(lynx!!) in attempting to get AAAA records makes the whole situation much
worse.

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.

Could you post the output of the command above when lynx'ing to
www.openbsd.org?

I can and will:

# tcpdump -i rtw0 -vvvv -n -e port 53
tcpdump: listening on rtw0, link-type EN10MB
13:27:53.450391 0:d:88:3f:72:5d 0:d:88:3e:fc:17 0800 75:
192.168.0.114.3777 > 192.168.0.1.53: [udp sum ok] 61778+ AAAA?
www.openbsd.org. (33) (ttl 64, id 5520, len 61)
13:27:58.459157 0:d:88:3f:72:5d 0:d:88:3e:fc:17 0800 75:
192.168.0.114.24605 > 192.168.0.1.53: [udp sum ok] 61778+ AAAA?
www.openbsd.org. (33) (ttl 64, id 3792, len 61)
13:28:08.469892 0:d:88:3f:72:5d 0:d:88:3e:fc:17 0800 75:
192.168.0.114.33590 > 192.168.0.1.53: [udp sum ok] 61778+ AAAA?
www.openbsd.org. (33) (ttl 64, id 27304, len 61)
13:28:28.481538 0:d:88:3f:72:5d 0:d:88:3e:fc:17 0800 75:
192.168.0.114.19123 > 192.168.0.1.53: [udp sum ok] 61778+ AAAA?
www.openbsd.org. (33) (ttl 64, id 53768, len 61)
13:29:08.495012 0:d:88:3f:72:5d 0:d:88:3e:fc:17 0800 75:
192.168.0.114.24415 > 192.168.0.1.53: [udp sum ok] 54880+ A?
www.openbsd.org. (33) (ttl 64, id 52647, len 61)
13:29:08.516042 0:d:88:3e:fc:17 0:d:88:3f:72:5d 0800 91:
192.168.0.1.53 > 192.168.0.114.24415: [udp sum ok] 54880 q: A?
www.openbsd.org. 1/0/0 www.openbsd.org. A 129.128.5.191 (49) (ttl 64,
id 15787, len 77)
13:29:08.525285 0:d:88:3f:72:5d 0:d:88:3e:fc:17 0800 75:
192.168.0.114.30372 > 192.168.0.1.53: [udp sum ok] 63344+ AAAA?
www.openbsd.org. (33) (ttl 64, id 40727, len 61)
13:29:13.535237 0:d:88:3f:72:5d 0:d:88:3e:fc:17 0800 75:
192.168.0.114.6658 > 192.168.0.1.53: [udp sum ok] 63344+ AAAA?
www.openbsd.org. (33) (ttl 64, id 47155, len 61)
13:29:23.546068 0:d:88:3f:72:5d 0:d:88:3e:fc:17 0800 75:
192.168.0.114.38759 > 192.168.0.1.53: [udp sum ok] 63344+ AAAA?
www.openbsd.org. (33) (ttl 64, id 55547, len 61)
13:29:43.557703 0:d:88:3f:72:5d 0:d:88:3e:fc:17 0800 75:
192.168.0.114.16937 > 192.168.0.1.53: [udp sum ok] 63344+ AAAA?
www.openbsd.org. (33) (ttl 64, id 57393, len 61)
13:30:02.192891 0:d:88:3f:72:5d 0:d:88:3e:fc:17 0800 74:
192.168.0.114.46856 > 192.168.0.1.53: [udp sum ok] 34468+ AAAA?
yyy.zzzzzz.lan. (32) (ttl 64, id 42230, len 60)
13:30:02.210410 0:d:88:3e:fc:17 0:d:88:3f:72:5d 0800 74:
192.168.0.1.53 > 192.168.0.114.46856: [udp sum ok] 34468 NXDomain- q:
AAAA? yyy.zzzzzz.lan. 0/0/0 (32) (ttl 64, id 15795, len 60)
13:30:02.210929 0:d:88:3f:72:5d 0:d:88:3e:fc:17 0800 85:
192.168.0.114.46698 > 192.168.0.1.53: [udp sum ok] 57636+ AAAA?
yyy.zzzzzz.lan.zzzzzz.lan. (43) (ttl 64, id 41685, len 71)
13:30:02.230369 0:d:88:3e:fc:17 0:d:88:3f:72:5d 0800 85:
192.168.0.1.53 > 192.168.0.114.46698: [udp sum ok] 57636 NXDomain- q:
AAAA? yyy.zzzzzz.lan.zzzzzz.lan. 0/0/0 (43) (ttl 64, id 15797, len 71)
13:30:23.572556 0:d:88:3f:72:5d 0:d:88:3e:fc:17 0800 75:
192.168.0.114.27377 > 192.168.0.1.53: [udp sum ok] 56794+ A?
www.openbsd.org. (33) (ttl 64, id 64798, len 61)
13:30:23.594462 0:d:88:3e:fc:17 0:d:88:3f:72:5d 0800 91:
192.168.0.1.53 > 192.168.0.114.27377: [udp sum ok] 56794 q: A?
www.openbsd.org. 1/0/0 www.openbsd.org. A 129.128.5.191 (49) (ttl 64,
id 15799, len 77)

It's clear that no AAAA records are being returned.

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.

Just hack on /etc/resolv.conf after DHCP has been initialized. That's a
fragile hack, of course, but it works well enough for one-off testing.

One can hack around in /etc/resolv.conf.tail, which overrides the
corresponding lines in /etc/resolv.conf. That's how I began
experimenting, and as I said earlier in the thread, I did put the ISP's
external DNS servers in there to make sure it wasn't my local caching
server. No difference though.

It would be useful in situations like this to be able to turn off a
protocol which is causing difficulties.

Anyway, I am still grateful for all the replies that I have received, and
appreciate the guidance and hints that you have given.

I have raised a support ticket with my ISP to check that their DNS servers
should be returning no-result responses. I was pleased to note that they
(a) appeared to understand the question, and (b) did not simply bounce me
off with "we don't support BSD".

Mark
--
signature has gone off in search of its very own AAAA record
.

Relevant Pages

  • Re: Replication issues
    ... I wanted to say Zone Transfers not Zone Forwarding. ... AD-Integrated DNS does not do zone transfers between the ... your DNS server will bypass ...
    (microsoft.public.windows.server.active_directory)
  • Re: W2k DNS limitationload
    ... responsibility of the resolver to determine the kind of response it ... added sometime after W2k release in order to harden the DNS server ... >> William Stacey, MVP ...
    (microsoft.public.windows.server.dns)
  • Re: DNS forwarders
    ... I appreciate your update and response, and I am glad to hear that the ... >Although DNS resolution has been working fine on my network up to this ... >servers would "know" to look to another DNS server on the domain. ... Remove the ISP forwarder entries from all the remote sites and replace ...
    (microsoft.public.windows.server.dns)
  • Re: Servers hang on boot
    ... The last DC at that site (not a DNS server). ... EventID: 0x00000457 ... (Event String could not be retrieved) ...
    (microsoft.public.windows.server.networking)
  • Re: DNS Redesign Issue
    ... set the new child domain DNS server as primary for the domain controllers? ... -If you are going to create a new AD Integrated Zone in each child domain, ...
    (microsoft.public.windows.server.dns)