[Mastov]

Hi,

my dns lookups take several (~ 6-10) seconds every time. I tried a lot
of things, but now I ran out of ideas. What I tried up to now is:

1. Deactivate IPv6: The most common advice about slow dns lookups
   didn't work in my case. IPv6 is already successfully deactivated (at
   least "lsmod | grep ipv6" claims that), but the problem continues.
   Also deactivation IPv6-lookups for certain programs (like firefox or
   ssh) doesn't help.
2. Use other nameservers: Changing the nameserver in /etc/resolv.conf
   to other ones didn't change anything as well. Besides, the original
   nameservers are working well on other systems!
3. Adding "option timeout:1" to or removing "domain ..." or
   "search ..." lines from the /etc/resolv.conf file: Also didn't help...

Any further ideas?

Thanks!
Chris

PS: Distro "Debian Lenny Amd64" out of the box, only ndiswrapper
installed and WLAN configured

[Lazydog]

do the following replacing <host> with something to lookup and post the output.

dig +trace <host>

[Mastov]

Hi,

thanks for your answer! At first the desired output of "dig +trace google.com"

mast@basil:~$ dig +trace google.com

; <<>> DiG 9.4.2 <<>> +trace google.com
;; global options:  printcmd
.			354324	IN	NS	F.ROOT-SERVERS.NET.
.			354324	IN	NS	G.ROOT-SERVERS.NET.
.			354324	IN	NS	H.ROOT-SERVERS.NET.
.			354324	IN	NS	I.ROOT-SERVERS.NET.
.			354324	IN	NS	J.ROOT-SERVERS.NET.
.			354324	IN	NS	K.ROOT-SERVERS.NET.
.			354324	IN	NS	L.ROOT-SERVERS.NET.
.			354324	IN	NS	M.ROOT-SERVERS.NET.
.			354324	IN	NS	A.ROOT-SERVERS.NET.
.			354324	IN	NS	B.ROOT-SERVERS.NET.
.			354324	IN	NS	C.ROOT-SERVERS.NET.
.			354324	IN	NS	D.ROOT-SERVERS.NET.
.			354324	IN	NS	E.ROOT-SERVERS.NET.
;; Received 512 bytes from 80.58.61.254#53(80.58.61.254) in 45 ms

dig: couldn't get address for 'C.ROOT-SERVERS.NET': not found

And then I installed wireshark and did some analysis, what was going on, when I tried to connect to some server, for example google.com:80. It looked always like this:

0s : Query AAAA google.com
2s : Query AAAA google.com
4s : Query AAAA google.com
4.01s : Response AAAA google.com
4.02s : Query AAAA google.com.local.lan
6s : Query AAAA google.com.local.lan
8s : Query AAAA google.com.local.lan
8.01s : Response AAAA google.com.local.lan : No such name
8.02s : Query A google.com
10s : Query A google.com
12s : Query A google.com
12.01s : Response AAAA google.com : 72.14.207.99
12.02s : TCP Init connection with 72.14.207.99
...

2 interisting questions about that:

1. Why does every query have to be done 3 times until a response is received???
2. Why are there still AAAA-queries, if the ipv6-kernel-module is not loaded ("lsmod | grep ipv6" gives empty output!)?

Anyone any idea? Thanks!

[Lazydog]

Originally Posted by Mastov

Hi,

thanks for your answer! At first the desired output of "dig +trace google.com"

mast@basil:~$ dig +trace google.com

; <<>> DiG 9.4.2 <<>> +trace google.com
;; global options:  printcmd
.            354324    IN    NS    F.ROOT-SERVERS.NET.
.            354324    IN    NS    G.ROOT-SERVERS.NET.
.            354324    IN    NS    H.ROOT-SERVERS.NET.
.            354324    IN    NS    I.ROOT-SERVERS.NET.
.            354324    IN    NS    J.ROOT-SERVERS.NET.
.            354324    IN    NS    K.ROOT-SERVERS.NET.
.            354324    IN    NS    L.ROOT-SERVERS.NET.
.            354324    IN    NS    M.ROOT-SERVERS.NET.
.            354324    IN    NS    A.ROOT-SERVERS.NET.
.            354324    IN    NS    B.ROOT-SERVERS.NET.
.            354324    IN    NS    C.ROOT-SERVERS.NET.
.            354324    IN    NS    D.ROOT-SERVERS.NET.
.            354324    IN    NS    E.ROOT-SERVERS.NET.
;; Received 512 bytes from 80.58.61.254#53(80.58.61.254) in 45 ms

dig: couldn't get address for 'C.ROOT-SERVERS.NET': not found

Not sure why this didn't work, what server were you using?

2 interisting questions about that:

1. Why does every query have to be done 3 times until a response is received???

Look at your resolve file. You normally have 3 DNS Server listed.
If the first one doesn't answer then DNS fails over to the second.
If the second fails it fails over to the third.

2. Why are there still AAAA-queries, if the ipv6-kernel-module is not loaded ("lsmod | grep ipv6" gives empty output!)?
Anyone any idea? Thanks!

I don't know enough about ipv6. Look at your eth config files to ensure it's not configured.

[Mastov]

I think I resolved the issue:

I analyzed the DNS queries of windows (working without problems on the same machine) and found out that the same effect is happening there as well: 3 query packets have to be sent until a response is received. The difference: Windows sends the queries with a much higher frequency and therefore the whole progress doesn't take as much time and the user doesn't recognize any delay.

So the problem seemed to be rather the router than the client system. Maybe the router recognizes an UDP "connection" only after at least 3 packets have been sent from the same port to the same port (as using UDP the router has no TCP flags signalling new connections). I don't know, something like this...

Workaround (since I haven't got access to reconfigure the router): Define the router IP itself as nameserver instead of the nameservers that it suggests via DHCP. So the UDP packets have to travel only within the LAN and the problem is avoided. The router is then able to act as a "DNS-forwarder", asks the nameservers of the ISP for the result and returns the result to the client.

Anyway: Hard to imagine that this effect doesn't happen all over the linux world?! What is different in other people's linux systems? Do they usually have shorter timeouts? Is the configuration of my router really THAT strange and normally routers forward the DNS packets properly? Do they ignore the DHCP-given nameservers and use the gateway-IP as default nameserver??? I didn't reconfigure anything strangely, the system is an almost-out-of-the-box debian!

Thanks for your help!

[Lazydog]

Originally Posted by Mastov

I think I resolved the issue:

I would not call this resolved but a work around.

I analyzed the DNS queries of windows (working without problems on the same machine) and found out that the same effect is happening there as well: 3 query packets have to be sent until a response is received. The difference: Windows sends the queries with a much higher frequency and therefore the whole progress doesn't take as much time and the user doesn't recognize any delay.

So the problem seemed to be rather the router than the client system. Maybe the router recognizes an UDP "connection" only after at least 3 packets have been sent from the same port to the same port (as using UDP the router has no TCP flags signalling new connections). I don't know, something like this...

Or just how the router is configured. It shouldn't take 3 packets to recognize a connection. If it is then you do not have the router configured correctly.

Workaround (since I haven't got access to reconfigure the router): Define the router IP itself as nameserver instead of the nameservers that it suggests via DHCP. So the UDP packets have to travel only within the LAN and the problem is avoided. The router is then able to act as a "DNS-forwarder", asks the nameservers of the ISP for the result and returns the result to the client.

Sounds like the router was misconfigured.

Anyway: Hard to imagine that this effect doesn't happen all over the linux world?! What is different in other people's linux systems? Do they usually have shorter timeouts? Is the configuration of my router really THAT strange and normally routers forward the DNS packets properly? Do they ignore the DHCP-given nameservers and use the gateway-IP as default nameserver??? I didn't reconfigure anything strangely, the system is an almost-out-of-the-box debian!

Thanks for your help!

Never had any issues using my ISP's DNS server before configuring my own.