6

I'm having issues with one of my servers taking a long time to look up host names. This is an Ubuntu 12.04 box, so I've tried following the new resolvconf directives.

In my /etc/network/interfaces file, I defined my name servers like this:

auto eth0
iface eth0 inet static
 address someaddress
 netmask 255.255.255.0
 gateway 198.58.103.1
 dns-nameservers 74.14.179.5 72.14.188.5

In my /etc/resolv.conf, I see these name servers, like this:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 74.14.179.5
nameserver 72.14.188.5

On another box, I edited the resolv.conf directly as directed by my hosts' setup help files. It looks like this: 

domain members.linode.com
search members.linode.com
nameserver 72.14.179.5
nameserver 72.14.188.5
options rotate

This second box has no issues with host name look ups and responds quite quickly.

Could not having the domain and search directives make my look ups slow? By slow, I mean it's taking anywhere from 5 to 15 seconds to find the IP address of a host.

If I do a time dig @72.14.179.5 www.google.com I get a response quickly with a "real" time of .170 seconds.

If I do a ping google.com I get a real time of 10.078 seconds, even if I quit the ping after one response. Like this:

time ping google.com
PING google.com (74.125.228.37) 56(84) bytes of data.
^C64 bytes from iad23s06-in-f5.1e100.net (74.125.228.37): icmp_req=1 ttl=54 time=34.2 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 34.291/34.291/34.291/0.000 ms

real    0m10.078s
user    0m0.001s
sys     0m0.005s
nwalke
  • 643
  • 2
  • 12
  • 32
  • Yes adding the search directive can slow things down a little, since it results in additional DNS lookups for records that are not fully qualified. Are you sure those two DNS servers are responding quickly? Are lookups slow when you query them directly using dig? – Zoredache Dec 10 '12 at 16:25
  • No. When I use dig, it's extremely fast. That mean it's definitely the search directives? – nwalke Dec 10 '12 at 16:28
  • Basically the search would only add one additional lookup. If lookup for a single record is 50ms, then with search it might be 100ms. You would expect it to dramatically increase. If `dig` is returning results quickly, then what application is having problems? Have you trying performing a `tcpdump` to see if you can find where the slowness is coming from? – Zoredache Dec 10 '12 at 16:34
  • I'm sorry, I think you misunderstood me. I edited the question to make it more clear, but the second box that HAS the search directive takes no time to perform look ups. – nwalke Dec 10 '12 at 16:37
  • Eh? I made a statement that using the search should be slower then without, what part of that has confused you? When I had asked if lookups were slow by using the dig tool, why the heck would I expect you tell me the results for the 'working' system? Please update the question with more details about exactly what is happening on the broken system. How exactly are you seeing this slowness. What exactly do you see on the **broken** system when you run something like `time dig @72.14.179.5 www.google.com`? – Zoredache Dec 10 '12 at 16:47
  • I'm sorry, I must have misunderstood what you were saying. I thought "Yes adding the search directive can slow things down a little" meant you thought the system WITH that directive was slow. I'll update with the `time dig` output. – nwalke Dec 10 '12 at 18:21

4 Answers4

2

Add the dns-search and dns-domain directives to your /etc/network/interfaces file.

TheBuzzSaw
  • 121
  • 3
  • Yeah, I think that might be causing it. I'll need to wait until tonight to restart the box. – nwalke Dec 10 '12 at 18:26
1

Have you got the ipv6 kernel module loaded?

If you have, your system will search for an AAAA record first, and if that returns a record, it'll preferentially use that over the A record, and the problem is that the service that requested the lookup will try and connect using the AAAA answer, which might not be supported for the IP stack you're using.

Disable the ipv6 kernel module, and this problem goes away.

Might not be that, though. You could always install dnsmasq locally so that your nameservers in /etc/resolv.conf is set to lookup against localhost, and dnsmasq will look up to the upstream nameservers, and cache the result, so the first one will be slow, but all subsequent ones will be lightning fast.

Tom O'Connor
  • 27,480
  • 10
  • 73
  • 148
0

I could not get the dns-domain directive to work. I also wanted to add "options rotate" at the end. I'm all for this file being generated dynamically, but there needs to be support for everything from the interfaces file. I've made resolv.conf a file again instead of a symlink.

nwalke
  • 643
  • 2
  • 12
  • 32
0

I had the same problem on 12.04 , i resolved it by doing this

Edit connections on network manager applet --> Auto Ethernet ( or wireless) --> IPV4 tab --> select method "Automatic(DHCP) Adresses only"

Enter DNS server - 8.8.8.8

Enter search domains - google-public-dns-a.google.com ( you will get this by a host look up on 8.8.8.8) and save

Thats it , no more "Resolving host"

If you do not have ipv6 maybe you can Ignore it as well in the Ipv6 tab , but i have not seen any significant change by doing that.

avinash
  • 1