DNS resolver behavior on IPv6

_saiko · 2012-03-25 23:27:59

Hi,

I noticed a problem with the DNS resolver when app explicitly asks for IPv6 address (tried with ping6 and irsii connect -6).
It takes 5-6s for IPv6 address to resolve.

I captured this with tcpdump during ping6:

00:50:51.049142 IP 10.1.0.102.44312 > 8.8.8.8.53: 39194+ A? ip6.me. (24)
00:50:51.049160 IP 10.1.0.102.44312 > 8.8.8.8.53: 28792+ AAAA? ip6.me. (24)
00:50:51.097061 IP 8.8.8.8.53 > 10.1.0.102.44312: 39194 1/0/0 A 66.117.47.214 (40)
00:50:56.053167 IP 10.1.0.102.44312 > 8.8.8.8.53: 39194+ A? ip6.me. (24)
00:50:56.084708 IP 8.8.8.8.53 > 10.1.0.102.44312: 39194 1/0/0 A 66.117.47.214 (40)
00:50:56.084747 IP 10.1.0.102.44312 > 8.8.8.8.53: 28792+ AAAA? ip6.me. (24)
00:50:56.130288 IP 8.8.8.8.53 > 10.1.0.102.44312: 28792 1/0/0 AAAA 2001:4810::110 (52)

Both A and AAAA queries are made even with ping6. Apparently A and AAAA queries are too close to eachother so only A response reaches? There's only 0.00002s offset.
Another retry is made with both A/AAA queries .This time there's some greater offset (0.03s) and both A/AAAA responses arrive. Naturally only after AAAA query is resolved ping6 works....

Problem: in the end it takes 5-6s for IPv6 address to resolve (time between the first queries and the retried queries).

This is the latest -Syu on x86_64 (fresh install).

Got another arch install that hasn't been updated for a while - also A/AAAA queries are made but there aren't any retried queres as both A/AAAA are instantly resolved. Offset between A and AAAA queries is 0.0002s

Anyone noticed this?

Last edited by _saiko (2012-03-26 20:13:13)

_saiko · 2012-03-26 20:15:06

update - this isn't ping6 related but happens with other applications when ipv6 is explicitly asked eg. irssi with /connect -6
It's some underlaying problem - resolver?

fukawi2 · 2012-03-26 22:34:09

I can't say I've noticed it on any of my hosts (IPv4-only or dual stack hosts)... Can you replicate the issue with a different DNS server? Have you compared /etc/resolv.conf and /etc/nsswitch.conf on the 2 hosts?

I thought the Linux resolver tried AAAA before A (if enabled for IPv6), but your tcpdump appears to show them being done in parallel.

_saiko · 2012-03-26 22:45:02

It doesn't matter which DNS server I use. In this case i used google's 8.8.8.8 so i doubt it's server issue.
Tried with my local DNS caching server, same result.

Actually it's A query first, then AAAA.
The problem is timing i bet.
On rare occasions when IPv6 resolve works instantly (same box), there's a somewhat larger offset between queries.

fukawi2 · 2012-03-27 05:14:15

Have you tried adding "options inet6" to your /etc/resolv.conf?

_saiko · 2012-03-31 16:07:29

I added options inet6 and I see no different behaviour.

fukawi2 · 2012-04-01 23:26:24

I'm out of ideas then, sorry

chosig · 2012-04-02 17:50:02

You perhaps want to use the Google IPv6 DNS's if you want to resolv 6 before 4, just a long shot (I don't use IPv6 yet)

2001:4860:4860::8888
2001:4860:4860::8844

_saiko · 2012-04-02 19:45:30

I used the google 8.8.8.8 DNS server. It doesn't matter if the DNS server is reachable via IPv4 or v6, it only matters what it returns.

Actually I noticed this behavior during IPv4 resolve if the app implicitly requests both A/AAAA. For example while pacman resolves the repo, same thing happens. Both A/AAAA are requested at the same time and only A gets resolved in the first try. Pacman still waits and retries the resolve operation, this time with A and AAAA requests a little bit further apart from each other. Only after the reply with A record arrives for the second time pacman resolves the hostname and starts downloading data.

23:41:04.986312 IP 10.1.0.102.44953 > 8.8.8.8.53: 26649+ A? ftp.tu-chemnitz.de. (36)
23:41:04.986330 IP 10.1.0.102.44953 > 8.8.8.8.53: 34353+ AAAA? ftp.tu-chemnitz.de. (36)
23:41:05.034919 IP 8.8.8.8.53 > 10.1.0.102.44953: 26649 1/4/3 A 134.109.228.1 (220)
23:41:09.990943 IP 10.1.0.102.44953 > 8.8.8.8.53: 26649+ A? ftp.tu-chemnitz.de. (36)
23:41:09.991598 IP 8.8.8.8.53 > 10.1.0.102.44953: 26649 1/4/3 A 134.109.228.1 (220)
23:41:09.991642 IP 10.1.0.102.44953 > 8.8.8.8.53: 34353+ AAAA? ftp.tu-chemnitz.de. (36)
23:41:10.045897 IP 8.8.8.8.53 > 10.1.0.102.44953: 34353 0/0/0 (36)

Could anyone else with dual stack and fresh -Syu check tcpdump during i.e ping6?

Last edited by _saiko (2012-04-02 19:54:27)

fukawi2 · 2012-04-03 05:11:46

I see the same behaviour (A and AAAA simultaneously), but I get answers for both:

15:10:03.344011 IP 192.168.1.20.52659 > 192.168.1.30.53: 55516+ A? repo.fukawi2.pvt. (34)
15:10:03.344019 IP 192.168.1.20.52659 > 192.168.1.30.53: 62599+ AAAA? repo.fukawi2.pvt. (34)
15:10:03.344750 IP 192.168.1.30.53 > 192.168.1.20.52659: 55516* 3/1/1 CNAME mirror.fukawi2.pvt., CNAME seraph.fukawi2.pvt., A 192.168.1.2 (127)
15:10:03.344770 IP 192.168.1.30.53 > 192.168.1.20.52659: 62599* 3/1/1 CNAME mirror.fukawi2.pvt., CNAME seraph.fukawi2.pvt., AAAA 2001:44b8:4121:xxxx::2 (139)

_saiko · 2012-04-03 06:06:39

I see the same problem wether I resolve using my caching DNS router or using an external DNS (i.e. google).
In both cases the requests go to my router so ill have to see if some queueing rules are making it slow to react..
Yours is quite fast to react, only 0.7ms to respond whereas its 50ms in my case.

Nevertheless, its peculiar how the second retry takes care of the timings between A and AAAA requests as if the folks who coded suspected problems like these?

fukawi2 · 2012-04-03 22:59:59

_saiko wrote:

Yours is quite fast to react, only 0.7ms to respond whereas its 50ms in my case.

TBF, my query was for a RR in a master zone on my gateway, so there was no external query required; it was all done over gigabit local network.

_saiko · 2012-04-16 12:04:35

The issue is (somewhat) solved by using the option single-request in resolv.conf.
Apparently my router/firewall or perhaps even the ISP are messing up the A/AAAA replies.

The single-request option is introduced in glibc 2.10
http://udrepper.livejournal.com/20948.html

Arch Linux

#1 2012-03-25 23:27:59

DNS resolver behavior on IPv6

#2 2012-03-26 20:15:06

Re: DNS resolver behavior on IPv6

#3 2012-03-26 22:34:09

Re: DNS resolver behavior on IPv6

#4 2012-03-26 22:45:02

Re: DNS resolver behavior on IPv6

#5 2012-03-27 05:14:15

Re: DNS resolver behavior on IPv6

#6 2012-03-31 16:07:29

Re: DNS resolver behavior on IPv6

#7 2012-04-01 23:26:24

Re: DNS resolver behavior on IPv6

#8 2012-04-02 17:50:02

Re: DNS resolver behavior on IPv6

#9 2012-04-02 19:45:30

Re: DNS resolver behavior on IPv6

#10 2012-04-03 05:11:46

Re: DNS resolver behavior on IPv6

#11 2012-04-03 06:06:39

Re: DNS resolver behavior on IPv6

#12 2012-04-03 22:59:59

Re: DNS resolver behavior on IPv6

#13 2012-04-16 12:04:35

Re: DNS resolver behavior on IPv6

Board footer