This is a Canonical Question about whether to outsource DNS resolution for ones own domains
I currently have my ISP providing DNS for my domain, but they impose limitations on adding records. Therefore, I am thinking about running my own DNS.
Do you prefer to host your own DNS, or is it better to have your ISP do this?
Are there alternatives which I can look into?
I wouldn't run my own DNS server - in my case, the hosting company that hosts my website provides free DNS service. There are also alternatives, companies that do nothing but DNS hosting (DNS Made Easy comes to mind, but there are many others) which are the kind of thing you should probably look into.
The reason I wouldn't do it myself is that DNS is supposed to be fairly reliable, and unless you have a geographically distributed network of servers of your own, you'd be putting all your eggs in one basket, so to speak. Also, there are plenty of dedicated DNS servers out there, enough that you wouldn't need to start up a new one.
We always host our own DNS (preferrable reverse DNS also). This allows us to make emergency changes without relying on a third party. If you have more than one location, it is easy to setup an accetpable level of redundacy for your DNS servers.
If you don't have multiple sites, then I would consider someone that specifically does DNS hosting (NOT your ISP) with a web interface for changes. Also look for 24x7 support and decent SLAs.
For a good, reliable DNS setup for your domain(s), you should have ...
Since it is unlikely you have access to the above network infrastructure, you're better off choosing a reputable DNS hosting provider (as others have recommended) which has the above network infrastructure.
For many years I ran my own DNS servers using BIND (versions 8 & 9) without any major hassle. I stored my configurations within version control with post-commit checks which would validate the zone files and then had my DNS servers checkout the zone files at regular intervals. The problem was always ensuring the SOA serial number was updated with each commit that got pushed out otherwise caching servers would not update.
Years later I worked with djbdns as the format was ideal for having automated scripts to manage the zones and did not suffer from the same SOA serial number issue I had to deal with using BIND. It did however have it's own issues with having to format certain resource record sets to get them to be accepted.
As I found much of my traffic was DNS and having to maintain both a primary and secondary DNS server to please the registrars I have since moved to using EasyDNS for my DNS needs. Their web interface is easy to manage and gives me the flexibility I need to manage my RR sets. I also found it to be easy to work with than those provided by some hosting providers like 1 & 1 that limit the available RR sets you can enter, or even domain registrars like Network Solutions which only works if you use Windows to manage your DNS.
For my personal domains (and some friends' domains I help out with) we host our own DNS and my registrar (Gandi) provides secondary DNS. Or a friend on another network provides secondary. Gandi doesn't update zones immediately, they seem to check about once every 24 hours or so, but changes are very infrequent; works well enough for us, and their server is probably much more reliable than ours.
At my job, we do our own DNS and our upstream network provider provides secondary DNS. However, we're a university and 99% of our users are on-site; if the local network is down it doesn't matter if DNS is down. Also, we have full a class-B (/16) with roughly 25k DNS records (plus 25k reverse DNS records, of course), which seems a bit awkward to manage through a web interface. Our local DNS servers are highly available and plenty fast.
I've done both. There can be benefits with hosting your own: you definitely learn a lot about how DNS works when your boss is asking you why its taking so long. Also, you are that much more in control of your zones. This isn't always as powerful as it ought to be, in large part due to the hierarchical distributed nature of DNS - but every now and again it does come in handy. Doubly so if you can get your provider to allocate you as the SOA for the reverse DNS of your IP block, assuming you have one.
However, all comments above about how you really ought to have a lot of failure resistance built in above are bang on. Servers in different data centers in different geographical areas is important. Having managed through the massive power outage in the Northeast in 2003 - we all learned that having a box in two different data centers in the same city, or even province or state - is not necessarily protection enough. The elation that kicks in when you realize your batteries and then diesel generators saved your butt is quickly replaced with the dread caused by the realization that you are now driving on your spare tire.
I do always run our internal DNS server for the LAN, however. It can come in very handy to have complete control over the DNS that your network uses internally - and if the power goes out in your office, your internal DNS server by virtue of being in the server rack is probably on battery or battery and diesel, while your PC's will not - so your clients will be offline long before the server is.
I'm reading all these solutions with some amusement because we managed to accidentally fit into all these "requirements" by hosting our primary DNS off a static DSL line, and having the registrar (which was on another continent) provide a secondary DNS on a much more serious and reliable connection. In this way, we get all the flexibility of using bind and setting all the records in the while being reasonable assured that the secondary gets updated to mirror these changes and will be available in the event of a manhole catching fire, to cite one occurrence.
This effectively fulfills:
"A minimum of two authoritative DNS servers for your domain;"
"The DNS servers should be connected to different physical networks and power supplies;"
"The DNS servers should be in different geographical areas."
It depends.
I've run my own DNS for my various jobs since the late 80s (BSD 4.3c). For work, I've always hosted my own DNS, but I've always had multiple datacenter locations, or was able to exchange secondary DNS with a partner. For example, at my last job we did secondary DNS for a different .EDU (they were in MN, we are in CA), and they did the same for us. Geographical and network diversity.
Or, at my present job we have our own east and west coast (US) datacenters. Hosting our own DNS lets us put in whatever unusual DNS records we might need (SVR, TXT, etc.) that might not be supported by some of GUI DNS services. And, we can change TTLs whenever we like; we have pretty much ultimate flexibility, at the cost of doing it ourselves.
For home stuff, I've done it both ways. For some domains where I'm doing unusual stuff, or need lots of flexibility, I still run my own "hidden" master DNS servers and exchange public DNS services with others who are doing the same. I use RCS to version control zone files for configuration management, so I can see the whole history of zone changes back to the beginning of time. For simple things like a domain with a single blog or generic web servers (one A record, or one CNAME), it's just easier to use a domain registrars DNS service where available and now worry about CM.
It's a tradeoff. Ultimate control and flexibility comes at the cost of handling diversity on your own, running multiple servers, dealing with hardware/software failures, etc. If you don't need the flexibility or total control, then any of the top-tier DNS providers will solve your problem, probably at a lower total cost.
As already mentioned in this thread, there several special cases with DNS, the most significant difference is between authoritative and caching name server deployments.
If you need a DNS server just to resolve Internet resources, some free cashing DNS resolver is a wise choice. I personally use PowerDNS recursor (pdns-recursor) on Linux.
For servicing your external infrastructure, like web-sites or MX's I wouldn't use internal NSes (if we are talking about SOHO here). Use some good, reliable, bullet-proof service like DNSmadeasy. I use their business package, and it rocks while being very affordable.
Should we host our own nameservers?
Yes, and you should also use one ore more of the big 3rd party DNS providers. A hybrid solution is likely the safest long term approach for multiple reasons, especially if you are a business that has any manor of SLA or contractual requirements to your customers. Even more so if you are b2b.
If your master DNS servers (hidden or public) are your source of truth, then you protect yourself operationally from getting locked into vendor specific capabilities. Once you start using their nifty features that go beyond basic DNS, you may find that switching to another provider or hosting your own DNS is problematic, as you now have to replicate those capabilities. Examples would be the site health checks and DNS failover that Dyn and UltraDNS provide. Those features are great, but should be considered one-off's and not a dependancy. These features also do not replicate well from provider to provider.
If you have only 3rd party vendors, then your uptime may be impacted when they are under a targetted DDoS attack. If you have only your own DNS servers, then your uptime may be impacted when you are the target of a DDoS attack.
If you have one or more DNS providers and your own distributed DNS servers that slave to hidden master DNS servers you control, then you will ensure that you are not locked into a particular vendor and that you maintain control of your zones at all times and that attacks must take down both your servers and the one or more major providers that slave to your servers. Anything short of that will be a degradation of service vs. a critical outage.
Another advantage of having your own master (ideally hidden, unpublished) servers is that you can build your own API and update them in whatever manor suits your business needs. With 3rd party DNS providers, you will need to adapt to their API. Each vendor has their own; or in some cases, just has a web UI.
Futhermore, if your master is under your control and a vendor is having a problem, then any of your slave servers that can still reach your master will get the updates. This is something you will wish you had after you realized that having a 3rd party as your master was a mistake during a large DDoS incident and you are unable to change any of the servers on providers that are not under attack.
From a legal perspective, preventing vendor lock-in may also be important for your business. For example, Dyn is potentially being purchased by Oracle. This puts them in a unique position to gather DNS stats on all of Dyn's customers. There are competitive aspects of this that may introduce legal risk. That said, I am not a lawyer, so you should consult your legal and PR teams on that matter.
There are many other aspects to this topic if we wanted to dig into the weeds.
[Edit] If this is just for a small personal / hobby domain, then 2 VM's that are not in the same datacenter as each other, running a small DNS daemon is more than enough. I do that for my own personal domains. It was not clear to me if your domain meant a business or just for hobby. Whatever the smallest VM's you can get is more than enough. I use rbldnsd for my domains; using a very high TTL on my records, as it takes up 900 KB of ram and can handle any abuse people throw at it.
I've used Zonedit or years. Its cheap (or free) and I've added lots of CNAME, A, MX, TXT, SRV, and other records.
We recently brought our public DNS in house when we brought all our services in house. This allows us to update everything as quickly as we need to. Having geographically distributed DNS isn't a requirement for us at the moment as the web servers are all in the same site.
I have the best of both worlds.
I host my public DNS for my websites and my MX records "somewhere else". It's reliable, it's safe, it works, I can modify it at will. I pay for the service and I am happy with the value.
But at home, I run my own caching DNS server rather than rely on my ISP. My ISP has a habit of losing DNS, having slow DNS, invalid DNS, and sometimes they want to pervert DNS so that failures go to places they think I might be interested in. I am not interested in using my ISP's DNS. So I have my own caching DNS servers and do it myself. It was a little bit of effort to set up in the beginning (maybe 2 hours), but it's clean and I have reliable DNS. Once a month, a cron job interrogates the root servers and refreshes the hints table. Maybe once a year I have to fiddle with it, like sending doubleclick.com to 127.0.0.1 or similar. Other than that, it requires no intervention and it works great.
If you decide to host your own DNS for the love of god have TWO dns servers per site. One for your external DNS, direct attached to your firewall for the world to find you. And a seperate one inside your network for your inhouse dns.
I can't comment yet, but I'm doing the same as freiheit. We run our primary DNS here in our DMZ, and our ISP has several slave DNS servers throughout the country wich updates immediatly after we make a change at the primary DNS.
It gives the best of both worlds; immediate control plus redunancy.
There are pros and cons to each approach, but I definitely favour hosting your internal DNS internally. The list of things you're reliant on for basic network services if you host it externally is mind boggling. The CEO might think it's clever to save money on DNS servers by hosting externally, but what will he think when he can't get his email if the internet link goes down?
From experience, if you want to attract a denial of service attack, host your own DNS. And your own website.
I am a believer in there are some things you should not do yourself. DNS hosting is one of them. Like many people have said, you would need redundant servers, connections and physical locations and you still would not approach the resiliency of even the smaller hosting companies.
The biggest benefit to hosting your own DNS is that changes can be made right away. Need to shorten your TTL's for an upcoming migration? You could probably write a script that does that on your own servers; for hosted DNS you may need to log in and manually change the records, or even worse, call the provider, go through 3 levels of support until you finally reach some one that can spell DNS, just to have them tell you they will submit the changes in 2-3 days.
I run my own DNS using BIND on Linux servers. I currently have four located in London UK, Miami FL, San Jose CA and Singapore. Works great and I have complete control. Stability of the data centre is very important, hence I have selected good DC's to run the servers (not reliant on the ISP or some other 'unknown' infrastructure). I'm able to set up DNS servers and other services anywhere in the world using the world class DC's that I select based on strict criteria. Rock solid DNS is essential for the email and web services that I run.
Think of DNS hosting as the basis for your public services. In my case email is critical to our business. If you host your DNS internally and your internet connection falters your DNS records can become stale, forcing your domain to be unavailable.
So in my case, if an MX record cannot be found for our domain, email is rejected right away.
So, I have our DNS hosted externally.
If the MX record is available, but our internet connection is down, mail will continue to queue on servers trying to send email to our domain.
I've been running my own servers and managing domains since at least 2002.
I've often used the DNS server of my provider.
The number of times that my server at my IP was available, but my DNS wasn't, were a few too many.
Here are my war stories:
One yuge provider in Moscow (one-of-the-first VZ-based ones) had my VPS in a cheap "value" DC, but their DNS were in a premium state-of-the-art DC with expensive traffic, in two different /24 subnets, as was required by some TLDs at the time. At one point, a disaster hit (possibly the power outage of 2005?), and their expensive DC went offline, and my site (still in Moscow, but in a "value" DC) could only be accessed by its IP address.
Interestingly, even before any incidents, I clearly recall doing traceroute, and, noticing the same DC for both ns1 and ns2 of my ISP, asking them to move one to "my" DC, too, for geo-redundancy; they dismissed the idea of the geo-redundancy, because the servers were already in the most premium DC possible.
I've had another provider (one-of-the-first ISPsystem-based ones), where they had one ns on-site, and another one abroad. Long story short, the whole setup was ridiculously buggy, and the "abroad" server often failed to maintain its zones, so, my domain effectively had an extra point of failure and wouldn't be accessible even if my whole server still ran smoothly.
I've had a registrar that ran its own network. It went down every now and again, even though my off-site servers were up. My DNS was down.
I've recently used multiple big cloud providers for secondary, where I'd myself run a hidden master. Both providers changed their setup at least once; never with any public announcements; some of my domains stopped resolving. Happened to a friend of mine, too, with one of same providers. This happens more often with third-party services than people care to admit in public.
In short, http://cr.yp.to/djbdns/third-party.html is absolutely correct on the topic.
The costs of having to bother with third-party DNS are often not worth the benefits.
The negatives of having a third-party DNS are often unfairly overlooked.
I would say that unless your domain already uses third-party services (e.g., for web, mail, voice or text), then adding a third-party DNS would almost always be counterproductive, and is by no means the best practice in every circumstance.
