I'm sure this is a clueless newbie question, so please feel free to be
vicious in your condemnations. However, it would still be useful to me if
those condemnations included chapter and verse of the docs.... :-)

That said, the situation: fresh vanilla OBSD 4.1 install on a machine
intended for desktop use. Machine is on a LAN behind a commercial ADSL
router and getting its IP address from an internal DHCP server on
192.168.0.1. If I do "lynx openbsd.org" then lynx pauses for a few minutes
with a "looking up openbsd.org" message. The page eventually loads, and
following a link on that page to elsewhere on the same site leads to the
same message and the same delay. This behaviour is site independent.

At the same time, if I do "nslookup openbsd.org" it returns the IP address
instantly, and "lynx 199.185.137.3" everything runs at warp speed.

/etc/resolv.conf:
-----------------
search mylan.int
nameserver 192.168.0.1
lookup file bind

Putting my ISP's nameserver addresses into /etc/resolv.conf.tail makes no
difference.

Other machines on the same LAN running Linux and MacOS, also getting
addresses by DHCP, have no such difficulties, except that I've seen
similar delays on those machines from Firefox when it tries to use IPv6.

So, my question is, can I change something to get better lookup behaviour
from lynx? And a related question, can this be done in a site-independent
way?

To reiterate, the fact that I'm sure I deserve a thorough beating for
asking a question, the answer to which is obvious to the rest of the
world, in no way reduces my appreciation of any help that may be given in
spite of my cluelessness.

Thanks in advance for everything,
Mark
--
signature still absent

Mark South <mark.south@null.invalid> writes:

> On Wed, 26 Sep 2007 19:06:13 +0800, dhg wrote:
>
> First, thanks very much for your reply.
>
>> Mark South <mark.south@null.invalid> writes:
>
>> check if you have such enviroment variables as 'http_proxy' or 'HTTP_PROXY'
>> set. if set, check if its values are correct.
>
> They aren't set, and shouldn't be needed.
>
>>> At the same time, if I do "nslookup openbsd.org" it returns the IP address
>>> instantly, and "lynx 199.185.137.3" everything runs at warp speed.
>>>
>>> /etc/resolv.conf:
>>> -----------------
>>> search mylan.int
>>> nameserver 192.168.0.1
>>> lookup file bind
>>
>> normally, you do not need 'search mylan.int' present in your /etc/resolv.conf.
>> and, make sure there IS a name server running on 192.168.0.1.
>
> That line is written by DHCP, but even taking it out manually doesn't fix
> the problem.
>
> There is a functioning nameserver at 192.168.0.1, all non-OBSD machines on
> the LAN are resolving rapidly and accurately.
>
>>> Putting my ISP's nameserver addresses into /etc/resolv.conf.tail makes
>>> no difference.

i've checked the man pages of 'resolv.conf', it says
'resolv.conf.tail' is not necessary on a desktop box with a
internet connection that does not change frequently. i don't know
if it's a concern?

>
> Note, BTW, that a nameserver line in /etc/resolv.conf.tail overrides the
> line in /etc/resolv.conf.

i'm not sure if it will *override* or just be appended to your
'resolv.conf'. you can remove 'resolv.conf.tail' and have another try.

>
> Some further info: since posting this query it occurred to me (duhhh!) to
> run tcpdump to monitor the network interface on port 53. As well as lynx,
> I have also tried using opera installed from ports.
>
> The timeouts seem to be because the applications are asking for AAAA
> records before falling back and doing A record requests. Opera has a
> noticeably shorter induced delay than lynx, but it's still there.
>
> So, I suppose I should be asking: how to stop the system asking for AAAA
> records and get it to request A records directly?
>
> Thanks again,
> Mark
> --
> where did that blasted .sig get to now?

--
Wherefore thus saith the LORD God of hosts, Because ye speak this
word, behold, I will make my words in thy mouth fire, and this
people wood, and it shall devour them.
-- Jeremiah 5:14

On Thu, 27 Sep 2007 02:39:12 +0800, dhg wrote:

Thanks for replying again.

> Mark South <mark.south@null.invalid> writes:
>
>> On Wed, 26 Sep 2007 19:06:13 +0800, dhg wrote:
>>
>> First, thanks very much for your reply.
>>
>>> Mark South <mark.south@null.invalid> writes:
>>
>>> check if you have such enviroment variables as 'http_proxy' or 'HTTP_PROXY'
>>> set. if set, check if its values are correct.
>>
>> They aren't set, and shouldn't be needed.
>>
>>>> At the same time, if I do "nslookup openbsd.org" it returns the IP address
>>>> instantly, and "lynx 199.185.137.3" everything runs at warp speed.
>>>>
>>>> /etc/resolv.conf:
>>>> -----------------
>>>> search mylan.int
>>>> nameserver 192.168.0.1
>>>> lookup file bind
>>>
>>> normally, you do not need 'search mylan.int' present in your /etc/resolv.conf.
>>> and, make sure there IS a name server running on 192.168.0.1.
>>
>> That line is written by DHCP, but even taking it out manually doesn't fix
>> the problem.
>>
>> There is a functioning nameserver at 192.168.0.1, all non-OBSD machines on
>> the LAN are resolving rapidly and accurately.
>>
>>>> Putting my ISP's nameserver addresses into /etc/resolv.conf.tail makes
>>>> no difference.
>
> i've checked the man pages of 'resolv.conf', it says
> 'resolv.conf.tail' is not necessary on a desktop box with a
> internet connection that does not change frequently. i don't know
> if it's a concern?

When I said "putting my ISP's...." I meant that I've tried it with and
without resolv.conf.tail.

>> Note, BTW, that a nameserver line in /etc/resolv.conf.tail overrides
>> the line in /etc/resolv.conf.
>
> i'm not sure if it will *override* or just be appended to your
> 'resolv.conf'. you can remove 'resolv.conf.tail' and have another try.

As I said, it makes no difference.

>> Some further info: since posting this query it occurred to me (duhhh!)
>> to run tcpdump to monitor the network interface on port 53. As well as
>> lynx, I have also tried using opera installed from ports.
>>
>> The timeouts seem to be because the applications are asking for AAAA
>> records before falling back and doing A record requests. Opera has a
>> noticeably shorter induced delay than lynx, but it's still there.
>>
>> So, I suppose I should be asking: how to stop the system asking for
>> AAAA records and get it to request A records directly?

And I might also need to ask whether there is a way to do that with a
configuration setting, a sysctl variable, or do I need to rebuild bind()?

I'm sure OpenBSD makes a great desktop system even for a machine with
poor-to-nonexistent IPv6 connectivity, and that I'm simply missing
something absolutely bleeding obvious.

On Wed, 26 Sep 2007 21:36:14 +0200, Mark South wrote:

> I'm sure OpenBSD makes a great desktop system even for a machine with
> poor-to-nonexistent IPv6 connectivity, and that I'm simply missing
> something absolutely bleeding obvious.

Normally there are a whole bunch of clueful people in here, but I've only
seen replies from dhg so far. Anyone have any other suggestions?

Mark South <mark.south@null.invalid> wrote:
> On Wed, 26 Sep 2007 21:36:14 +0200, Mark South wrote:
>
>> I'm sure OpenBSD makes a great desktop system even for a machine with
>> poor-to-nonexistent IPv6 connectivity, and that I'm simply missing
>> something absolutely bleeding obvious.
>
> Normally there are a whole bunch of clueful people in here, but I've only
> seen replies from dhg so far. Anyone have any other suggestions?

[Sorry for dragging up this almost-dead thread.]

No, but it appears (tcpdump) that my system also tries to resolve
AAAA first (and fails, and falls back to A).

Do you use a DNS server that does not reply to AAAA queries, or
somesuch? 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.

Joachim

On Tue, 02 Oct 2007 20:49:26 +0000, Joachim Schipper wrote:

On Tue, 02 Oct 2007 20:49:26 +0000, Joachim Schipper wrote:

> Mark South <mark.south@null.invalid> wrote:
>> On Wed, 26 Sep 2007 21:36:14 +0200, Mark South wrote:
>>
>>> I'm sure OpenBSD makes a great desktop system even for a machine with
>>> poor-to-nonexistent IPv6 connectivity, and that I'm simply missing
>>> something absolutely bleeding obvious.
>>
>> Normally there are a whole bunch of clueful people in here, but I've only
>> seen replies from dhg so far. Anyone have any other suggestions?

I'd just like to slip in a word of apology to dhg here. Rereading what I
wrote, it could have looked like I was implying that dhg is clueless,
whereas I only meant that I was surprised to have received responses from
only a single person. Sorry for my clumsy words, dhg.

> [Sorry for dragging up this almost-dead thread.]

No, on the contrary, I'm grateful to you for your reply.

> No, but it appears (tcpdump) that my system also tries to resolve
> AAAA first (and fails, and falls back to A).

It's obviously doing what it was designed to do. One could argue whether
the design decision was justified, but I'm really just interested in
knowing how to apply a reasonably efficient solution make it work better
on the present Internet as opposed to a future one that doesn't yet exist.

> 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. The timeouts vary from about
1 or 2 seconds with Opera to over 2 minutes with Lynx(***). An example is
www.openbsd.org :-(

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.
Effectively instantaneous. An example is mirror.switch.ch.

> 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.

(***) 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.

Thanks again for responding, Joachim.

Mark
--
signature retrieval timed out.

Mark South <mark.south@null.invalid> 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. 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 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.

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.

>> 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.

Joachim

On Wed, 03 Oct 2007 06:42:15 +0000, Joachim Schipper wrote:

> Mark South <mark.south@null.invalid> 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

Mark South <mark.south@null.invalid> wrote:
> On Wed, 03 Oct 2007 06:42:15 +0000, Joachim Schipper wrote:
>
>> Mark South <mark.south@null.invalid> 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.

>> 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?

>> 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.

Joachim

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

> Mark South <mark.south@null.invalid> wrote:
>> On Wed, 03 Oct 2007 06:42:15 +0000, Joachim Schipper wrote:
>>
>>> Mark South <mark.south@null.invalid> 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