Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I think maybe I'm missing something here, perhaps someone can enlighten me.

I keep reading that hosting your own DNS is bad news, you should go with a reliable provider with geographic redundancy, multiple ISP connections, blah blah blah. We host our own DNS right now and are in the process of upgrading everything, so if there is a compelling reason, we might switch out to hosted DNS (i.e. DynDNS).

I'm slightly confused as to why it matters though. If my example.com connection goes down / loses power / etc and there is no redundancy there, what does it matter if my DNS resolution for example.com is still working?

If I do have redundant connections, battery backup power and generators for the example.com web app, then I can put the DNS on the same redundant infrastructure and it is just as reliable as the example.com app.

Is there any reason to have DNS that is more reliable than the applications on the domains it is serving?

share|improve this question

5 Answers 5

One reason your DNS should be reliable is email. Assuming you're also hosting your own email server consider what happens when your system goes off-line for any reason.

Self hosted: Any system trying to deliver a message sees there is no DNS for your domain and in most cases (dependent somewhat on how each system is configured) will give up as a permanent error.

Hosted externally on more reliable systems: The sender will detect your system is down, treat it as a temporary failure and will go through the normal retry routine.

share|improve this answer

It depends on the error you want to send, and how people will interpret that error:

A mailserver that gets 'No such machine' because your DNS is down might not bother retrying the delivery later, while if it was able to resolve it to an IP that was thenunreachable it might queue it for later retries. Also, ideally you have an offsite backup MX that will queue all mail for you so your main mailserver will get it once you get back on the net.

On the web, it might not matter unless/until you use some kind of Content Distribution Network that is doing reverse proxying of content from your site - in that case even if your site was down, some content would be cached and so okay to show, but iwithout DNS to point at the CDN, it won't be reachable.

share|improve this answer

DNS reliability is a must. There's nothing wrong in having self hosted DNS, but you should always mirror it with some big provider(s). I use XName.org, Afraid.org and puck.nether.net as slaves of my domains. And I've donated some bucks to Xname so that I can use branded names like ns2.mydomain.com, etc.

Also the zone expiry time should be big enough (mine is one week and that's the max as per RFC, I believe) so that in case your server goes down miserably or your ISP has some big trouble which will take more time, then DNS still exists.

It is always better to have mail server independent of your infrastructure because it is critical unless you are 95%+ sure that there will be no downtime. Most mail servers try for 2 days on failures with valid DNS.

For the same reason I use Google Apps :)

share|improve this answer
1  
On the flipside, if you want to change the IP your hosts are pointed to, you are going to have a heck of a time getting that to propagate in an emergency. Setting to max TTL seems too risky to me. –  Warner Aug 7 '10 at 17:14
    
TTL and expiry are two different things. Expiry is the maximum time when the slaves will keep data of the zone if the master goes down. On the other side, TTL is the maximum time when the resolved data in the resolver cache expires. You can have a low TTL with a high expiry time. And about penetration of updates to slaves, it is controlled by the refresh setting. –  nileshgr Aug 7 '10 at 18:25

"Is there any reason to have DNS that is more reliable than the applications on the domains it is serving?"

As mentioned by Nilesh, domain setups that use a combination of services such as Google Apps for Domain for email, plus self-managed services, is a very good reason to use a 3rd party DNS provider.

I have been using DNS Made Easy for more than a year to manage domains precisely for such a setup, and given that DNS Made Easy boasts a 100% uptime record over the last 8 years, with solutions starting at less than US$3/month, it provides great value for money, and certainly more reliable even than the web infrastructure of Amazon, Google and Rackspace!

Since you are now preparing for the next stage of your infrastructure setup, consider that services such as DNS Made Easy and DynDNS support Dynamic DNS records that can be updated via scripts. So for example, you might have a backup web & database setup on a cloud service. Should you need to re-direct traffic from your normal server infrastructure to an alternative site, for example because of an outage or a DDoS, an external monitor system could run a script and automatically adjust the DNS A-Record to reflect the changes in IP addresses.

You'll find a useful article on this type of setup in the August 2010 issue of Linux Magazine (UK) that I think is called Linux Pro Magazine in the US.

You'll also find some ideas at this Amazon Web Services forum discussion: http://developer.amazonwebservices.com/connect/message.jspa?messageID=72903

share|improve this answer

DNS is also a common service to target with a Denial of Service attack, which other providers can sometimes be better equipped to deal with.

I prefer to run my DNS in most cases, however there can be advantages to using external DNS providers in addition to your DNS if not just for redundancy.

You can gain the advantage of maintaining your own zones directly yet not having the footprint on the Internet by running a stealth DNS. Your external providers would slave off the DNS you run but only they would be able to access your DNS via the firewall, which is a configuration I often use.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.