11

I keep getting an error message whenever doing anything that requires a DNS lookup on my CentOS server. E.g.:

[root@15557 etc]#  wget http://www.whitehouse.gov/sites/default/files/rss_viewer/birth-certificate-long-form.pdf
--2011-05-03 20:55:35--  http://www.whitehouse.gov/sites/default/files/rss_viewer/birth-certificate-long-form.pdf
Resolving www.whitehouse.gov... failed: Temporary failure in name resolution.
wget: unable to resolve host address `www.whitehouse.gov'

If I restart the server then this problem goes away for a short time, but it always comes back after an hour or so. If I change the nameserver IPs listed in resolv.conf, the problem is not fixed, even if I substitute them with common nameserver like Google's 8.8.8.8. If I flush the hosts cache after changing resolve.conf, it does not fix the problem either. After restart of the server, the resolv.conf is changed back to it's default values (I guess by some DHCP).

whitelines222
  • 111
  • 1
  • 1
  • 3
  • 1
    Any outbound packet loss on your server? I'd fire up a packet sniffer and see what the DNS traffic looks like when this happens. – EEAA May 04 '11 at 04:09
  • Can you recommend a packet sniffer? I haven't installed such a software before. Thanks. – whitelines222 May 04 '11 at 04:10
  • `tcpdump` is readily availalble in most distros via their package repository. I'd recommend googling around for a tcpdump tutorial before getting started, though. Also, you can use tcpdump to capture the packets and write them to a log file, then you can open up that log file in a GUI tool called Wireshark, which is a bit more user-friendly than using the CLI. – EEAA May 04 '11 at 04:13
  • tcpdump -Ani -s0 port domain (-w my.log &) – 3molo May 04 '11 at 07:45

2 Answers2

10

This might be a problem caused by DHCP server -actually, by a rogue or another misconfigured DHCP server on your network.

Probably, this is what happens: when your server boots, it manages to get the accurate parameters (IP address, gateway, DNS servers, etc) from the legit DHCP server and as a result, you won't experience any problems until the lease renewal. After a relatively short period of time (it depends on dhcp client and server configuration), the DHCP client will attempt to renew the lease, by contacting the legit DHCP server (via unicast transmission). If this for some reason fails or your dhcp client for some reason doesn't get a response from the legit DHCP server, it will get into rebinding state and will broadcast a request to extend the lease time. If the rogue/another misconfigured DHCP server manages to respond first, it might send to your DHCP client inacurate parameters -for example a "wrong" DNS server address, and as a result you won't be able to resolve hostnames.

If my speculation is right, rebooting your server does not always solve the problem, since there might be times when the rogue DHCP server responds first, and as a result you experience the problem you mentioned.

In any case, try configuring static IP addresses, disabling DHCP and setting manually DNS servers. Also you should probably check if any other DHCP servers are running on your network, besides the one you're using.

dkaragasidis
  • 745
  • 4
  • 11
  • How do I find if there is a rogue DHCP server on my Network? http://serverfault.com/questions/8526/how-do-i-find-if-there-is-a-rogue-dhcp-server-on-my-network – Elijah Lynn Mar 07 '17 at 22:48
2

In my case, I'd set the fw rules up for the wrong interface. So port 53 wasn't open, and the server couldn't make a dns req

grahamrhay
  • 131
  • 3
  • I found this to be a problem with my firewall. After reading this I checked and my firewall listed a blocked action. I temporarily disabled the firewall and it started to work. But it wasn't port 53 for me -- although my failure was over a Jenkins SSH connection so that could explain the different port number. – John Rocha Dec 30 '21 at 18:53