4

For some reason, two of my machines have started suffering from extremely slow DNS lookups.

Sample timed output of 'host' command:

[root@ns507403 ~]# time host www.google.com
www.google.com has address 172.217.5.4
www.google.com has IPv6 address 2607:f8b0:4006:80d::2004

real    0m3.050s
user    0m0.000s
sys     0m0.004s

Lookups seem to take at least 3 seconds no matter which address is used or how many times the lookup is done. The highest I have seen was 9 seconds to lookup www.paypal.com

I have ruled out the possibility of a slow DNS server because I'm using the same DNS resolver on 4 other servers all located in the same data center, all of which work fine. (< 1ms lookups)

Things I have tried already without success:

  • Adding options single-request to /etc/resolv.conf
  • Adding options single-request-reopen to /etc/resolv.conf
  • Disabling IPv6 using sysctl -w net.ipv6.conf.all.disable_ipv6=1
  • Disabling NetworkManager (It is not installed on my server)

This is my current /etc/resolv.conf file:

nameserver 127.0.0.1
nameserver 213.186.33.99
search ovh.net

The dig command seems to work just fine, showing query time 0ms.

Any ideas what could be causing this? I'm using CentOS 6 on both machines.

Improve this question
3
  • 2
    What do you see with dig @127.0.0.1 www.google.com
    – Aaron
    Commented Jul 26, 2016 at 0:26
  • It shows that it timed out
    – Elite_Dragon1337
    Commented Jul 26, 2016 at 0:28
  • 2
    That means your local recursive dns daemon is misconfigured or not running. For now, I would comment out the nameserver 127.0.0.1 line until that dig command above works. I would check chkconfig --list | grep "3:on" and see which DNS daemon is supposed to be running and fix that before you uncomment the 127.0.0.1 entry.
    – Aaron
    Commented Jul 26, 2016 at 0:30

7 Answers 7

Reset to default
3

127.0.0.1 is your localhost loopback interface, meaning you're reaching your own server. For various reasons, your server is using that first to lookup DNS and since your server doesn't know how to answer a DNS query, you have to wait until the query times out and moves on to the 2nd nameserver.

Just use the real DNS nameserver as the only entry:

nameserver 213.186.33.99

Why do you even have 127.0.0.1 as a nameserver?

Improve this answer
4
  • I'm using the default settings that were set up by my host OVH. These settings are working perfectly fine on other servers that I have at OVH, and they were working fine on this server before. Something broke it, I think it might be caused by me running yum update a week ago? Any idea?
    – Elite_Dragon1337
    Commented Jul 26, 2016 at 0:25
  • Are the other servers using the same nameservers in the same exact order? If so then there are other network settings that are affecting the order of selection (of which there are many, search for "linux nameserver order"). The best fix is to just remove the known bad setting.
    – Mani Gandham
    Commented Jul 26, 2016 at 0:57
  • @Elite_Dragon1337 I have some experience with OVH's default installations...frankly they're utter crap. I ignore them and do the OS installation myself via the IPMI console.
    – Michael Hampton
    Commented Jul 26, 2016 at 1:00
  • This server has been running for 3 years already, the DNS only stopped working very recently. I'm guessing when I did yum update -y about a week ago. Is there any reason why this would break the DNS server on 127.0.0.1? I'm guessing it has something to do with "BIND"?
    – Elite_Dragon1337
    Commented Jul 26, 2016 at 1:07
1

Reverse the name server order and it will speed up.

nameserver 213.186.33.99
nameserver 127.0.0.1
Improve this answer
4
  • That seemed to have fixed the issue. Could you explain why this is the case, and why it was not an issue on the other servers I have at the same data center?
    – Elite_Dragon1337
    Commented Jul 26, 2016 at 0:05
  • 1
    127.0.0.1 implies that you have a name server running on the local box, not running remotely. If you don't have a name server on the local box you should leave out 127.0.0.1 entirely.
    – chicks
    Commented Jul 26, 2016 at 0:21
  • I'm using the default settings that were set up by my host OVH. These settings are working perfectly fine on other servers that I have at OVH, and they were working fine on this server before. Something broke it, I think it might be caused by me running yum update a week ago? Any idea?
    – Elite_Dragon1337
    Commented Jul 26, 2016 at 0:25
  • voting back up - as OP said it "fixed the issue" - I had same problem and first nameserver was slow/not responding (confirmed via dig that resolution came from last nameserver ) - so re-ordering meant resolution was much quicker.
    – Dazed
    Commented Dec 3, 2019 at 15:39
1

More than likely you're pointed to 127.0.0.1 (localhost) because your distro uses a caching name service daemon. Think of it like a caching DNS server that runs on your own computer. The use of such a daemon is of debatable effectiveness.

It does have some benefits in speeding up some types of Internet usage by cutting down on the number of DNS requests that go out to the Internet. However, I have seen them crash and burn on their own, resulting in "the network is slow" errors that so many of us just love.

If I remember correctly CentOS uses the nscd (name services caching daemon) to perform this function. A quick sudo service nscd restart should fix it.

Or, you can do what you've done and cut out the middle-man so-to-speak. If that's the case and you don't want to run the caching daemon you should disable it with:

sudo service nscd stop
sudo chkconfig nscd off
Improve this answer
1
  • 1
    nscd is not a DNS resolver and not reachable over IP. It's a caching demon for NSS map lookups (passwd, group, hosts, etc.). Some Linux distros are using dnsmasq as local caching DNS resolver.
    – Michael Ströder
    Commented Apr 16, 2019 at 20:19
0

Turns out it was a firewall issue after all.. OVH has a really buggy web-based firewall which was causing the problems. The staff at OVH told me that my firewall was set up 100% fine, because otherwise it would not be possible to resolve using 213.186.33.99. This was incorrect, the firewall is bypassed for this specific IP because it is apparently hosted inside the OVH network.

Improve this answer
2
  • What exactly was the firewall preventing? You said the DNS lookup was slow, not stopped altogether...
    – Mani Gandham
    Commented Jul 27, 2016 at 6:40
  • It would first try to lookup using 127.0.0.1 which would time out after a couple of seconds because of the firewall, and then it would look it up using the second DNS server 213.186.33.99.
    – Elite_Dragon1337
    Commented Jul 27, 2016 at 14:14
0

In my case I used google's DNS instead of my routers (Gateway)

I replaced 192.168.1.1 and added:

nameserver 8.8.8.8
nameserver 8.8.4.4
Improve this answer
0

Our entire office recently experienced symptoms exactly like the OP described, indicating it was a problem with the router appliance (Fortigate).

The problem turned out to be the choice of nameservers in the router config. Our old settings were pointing to stalwart Level3 servers at 4.2.2.1 and 4.2.2.2. For reasons unknown, these servers were performing very badly.

We switched to 1.1.1.1 (CloudFlare) and 8.8.8.8 (Google) and problem instantly fixed, plus overall browsing speed dramatically increased.

Improve this answer
-1

This config work for me:

nameserver 213.186.33.99
nameserver 127.0.0.1
nameserver 208.67.222.222
search ovh.net
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .