Find the answer to your Linux question:
Results 1 to 6 of 6
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 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jul 2008
    Posts
    3

    Slow DNS Lookup (and no IPv6-issue???)


    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

  2. #2
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    do the following replacing <host> with something to lookup and post the output.

    Code:
    dig +trace <host>

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  3. #3
    Just Joined!
    Join Date
    Jul 2008
    Posts
    3
    Hi,

    thanks for your answer! At first the desired output of "dig +trace google.com"
    Code:
    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!

  4. #4
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    Quote Originally Posted by Mastov View Post
    Hi,

    thanks for your answer! At first the desired output of "dig +trace google.com"
    Code:
    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.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  5. #5
    Just Joined!
    Join Date
    Jul 2008
    Posts
    3
    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!

  6. #6
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    Quote Originally Posted by Mastov View Post
    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.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •