up vote 2 down vote favorite
share [g+] share [fb]

We have a small datacenter with about a hundred hosts pointing to 3 internal dns servers (bind 9). Our problem comes when one of the internal dns servers becomes unavailable. At that point all the clients that point to that server start performing very slowly.

The problem seems to be that the stock linux resolver doesn't really have the concept of "failing over" to a different dns server. You can adjust the timeout and number of retries it uses, (and set rotate so it will work through the list), but no matter what settings one uses our services perform much more slowly if a primary dns server becomes unavailable. At the moment this is one of the largest sources of service disruptions for us.

My ideal answer would be something like "RTFM: tweak /etc/resolv.conf like this...", but if that's an option I haven't seen it.

I was wondering how other folks handled this issue?

I can see 3 possible types of solutions:

  • Use linux-ha/Pacemaker and failover ips (so the dns IP VIPs are "always" available). Alas, we don't have a good fencing infrastructure, and without fencing pacemaker doesn't work very well (in my experience Pacemaker lowers availability without fencing).

  • Run a local dns server on each node, and have resolv.conf point to localhost. This would work, but it would give us a lot more services to monitor and manage.

  • Run a local cache on each node. Folks seem to consider nscd "broken", but dnrd seems to have the right feature set: it marks dns servers as up or down, and won't use 'down' dns servers.

Any-casting seems to work only at the ip routing level, and depends on route updates for server failure. Multi-casting seemed like it would be a perfect answer, but bind does not support broadcasting or multi-casting, and the docs I could find seem to suggest that multicast dns is more aimed at service discovery and auto-configuration rather than regular dns resolving.

Am I missing an obvious solution?

link|improve this question
1  
I suggest that in addition to finding the solution you're asking for (which I can't help you with) you should be working on the real root problem and fix the reliability issues with the DNS server. – John Gardeniers Jan 4 '11 at 21:41
feedback

3 Answers

up vote 1 down vote

Check out "man resolv.conf". You can add a timeout option to the resolv.conf. The default is 5, but adding the following to resolv.conf should bring it down to 1 second:

options timeout:1

link|improve this answer
After rereading your second paragraph, I've tried the above on a Centos and Debian VPS. After bringing down the primary dns, the resolver performed exactly as expected. Running a tcpdump, I could even see the resolver trying the first server, and then trying the next. What behaviour are you seeing? – Niall Donegan Jan 4 '11 at 21:15
There are two big use-cases for resolving: short lived processes (like command line tools) and long lived processes, and the same resolver configuration has to work for both. For short lived (single lookup) setting a short timeout will fail over quickly. But if you are looking up an external address that doesn't resolve in that time: you will get a name not found, since the resolver will abandon that query if it doesn't come back in a second. (out of room; more in the next comment) – Neil Katin Jan 4 '11 at 22:12
Long term processes will retry each lookup, timeout, and then move to the next server. But it doesn't seem to cache the "deadness" of the server. – Neil Katin Jan 4 '11 at 22:16
feedback
up vote 1 down vote

A couple of options. Both will distribute the DNS load across your DNS servers.

  • Try using options rotate in resolv.conf. This will minimize the impact of the primary server being down. If one of the other servers is down, it will slow down actions.
  • Use a different nameserver order on different clients. This will allow some clients to run normally if the primary DNS server is down. This spreads the impact of an out of service DNS server around.

These options can be combined with options timeout:1 attempts:5. Increase the attempts if you decrease timeout so you can handle slow external servers.

Depending on your router configuration you may be able to configure your DNS servers to take over the primary DNS server's IP address when it is down. This can be combined with the above techniques.

link|improve this answer
feedback
up vote 0 down vote

I know this might sound trite, but how about building a more stable, reslilient DNS infrastructure as a permanent solution to the problem.

link|improve this answer
We have a fairly resilient dns infrasture. But 2 or 3 times a year we have an outage because a dns server goes down (or is restarted, or has an OS upgrade, or whatever). – Neil Katin Jan 4 '11 at 22:17
1  
Well... restarts and upgrades should be scheduled for non-production hours. As for the rest, it seems like you're making a pretty big deal out of something that happens a few times a year. Is the additional infrastucture, time, money, and management overhead worth it for a problem that occurs so seemingly infrequently? – joeqwerty Jan 4 '11 at 23:31
2  
What happens when your production hours are 24x7? DNS should fail to the second/third/x server AND cache the failure of the other server for a period. The Default 5 second timeout is enough to bring services down depending on the load. – Ryaner Apr 29 '11 at 20:30
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.