97

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?

Saif Khan
  • 1,935
  • 2
  • 20
  • 25
  • Adding to the answers below, experience is also important. There are numerous mistakes that you *will* make as a fledgling DNS admin barring good mentorship or an eagle eye for documentation. (books and RFCs, *not* HOWTOs) Mistakes made at the authoritative DNS layer cause outages *even when the rest of your network is fine*. – Andrew B Sep 30 '14 at 04:37
  • Also read the related Q&A [Why is geo redundant DNS necessary even for small sites?](http://serverfault.com/questions/710108/why-is-geo-redundant-dns-necessary-for-small-sites) – HBruijn Oct 30 '15 at 07:07

21 Answers21

64

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.

David Z
  • 5,376
  • 2
  • 24
  • 22
  • 7
    +1 to DNS Made Easy. They have an audited, 100.0% update record over the last 7+ years. – Portman Jun 10 '09 at 23:29
  • Just thought I'd drop a note. Just today we finally got fed up with crappy DNS from our current provider, switched to DNS Made Easy based on the recommendation here, and it's fan-bloody-tastic. Love it. Wish I had done it years ago. – Mark Henderson Aug 18 '09 at 04:32
  • 1
    Isn't this why there's a primary and secondary server for every entry? I've never had a glitch being the primary, and having the secondary be my registrar; I mean I have had a glitch on primary, but nobody noticed because there was a reliable secondary. – dlamblin Sep 14 '09 at 07:47
  • Sure, nothing wrong with that if you really want to run your own DNS server for some reason. But otherwise, as long as you're going to be paying a third party for DNS hosting anyway (to be the secondary), you might as well let them handle it all. I think for most people, running a DNS server is more trouble than it's worth. – David Z Sep 16 '09 at 02:16
  • DNS Made Easy actually has a network of servers spanning several continents. And they use anycast routing. So their redundancy is ridiculous, well beyond the conventional two-server (primary and secondary) setup. But in theory that also means that computers all across the globe will get fast DNS resolution. – Steve Wortham Jan 23 '10 at 00:07
  • If your website is your business you shouldn't compromise on DNS. I would never setup DNS for a single domain (or even few dozens), unless part of the core business is providing subdomains. – eitanpo Dec 05 '12 at 11:30
  • If you also host your own servers (mail, web, etc), not sure why you need your DNS to be super awesome and redundant/etc. Most cases your servers will be hit multiple times for every DNS request, so hosting everything *but* the DNS is going to cut your traffic by less than half (less than 5 to 10% in a lot of cases). – eselk Aug 08 '13 at 18:14
  • @MarkHenderson, your comment about switching from one third-party provider to another one pretty much underlines the issue with third-party DNS in general -- sure, if things work, they work; but if things do happen to break, it's totally out of your control, and you have to use an IP-address to ssh into your own systems. Third-party DNS service is almost always misused; most sites would be much better off with their own DNS. – cnst Jan 06 '17 at 19:59
27

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.

Doug Luxem
  • 9,592
  • 7
  • 49
  • 80
  • 4
    When considering outsourcing, also ask what kind of DDoS protection or mitigation they have in place. DNS providers get attacked all the time and some are able to keep running without breaking a sweat and others will crumble into a pile of crumbs at the slightest spike in traffic, so be weary of outsourcing unless it's a reputable provider that has many servers deployed with anycast routing enabled. – Justin Scott Dec 01 '11 at 09:01
  • I was about to upvote (with much enthusiasm!) based on your personal experience in the first sentence, but then you suggest to use a third-party service in the second one, which basically means that an extra unnecessary point of failure is added for little to no benefit. :/ Sad. – cnst Jan 06 '17 at 20:24
19

For a good, reliable DNS setup for your domain(s), you should have ...

  • A minimum of two authorative 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.

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.

Convict
  • 1,593
  • 9
  • 8
  • Hard not to get convinced when you put it that way. – Filip Dupanović Apr 22 '11 at 08:21
  • This is a great summary of the industry consensus, bar none. (You know, the industry that makes its money from expensive overengineered solutions that may not even perform to actual true spec.) – cnst Jan 06 '17 at 20:57
  • What good is having highly redundant DNS servers if your hosting is still non-redundant? – Chris Smith Oct 04 '19 at 20:52
14

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.

Jeremy Bouse
  • 11,241
  • 2
  • 27
  • 40
  • This is a good honest answer, but it sounds like you may be deceiving yourself in the soundness of your solution -- by using EasyDNS, you're making it your single point of failure; your site could be all up and running, yet your names may not be resolving should your third-party provider suffer an outage or a DDoS directed at one of their customers. – cnst Jan 06 '17 at 20:52
8

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.

freiheit
  • 14,334
  • 1
  • 46
  • 69
  • 3
    We do the same thing here. We have two Linux boxes running BIND (one pri the other sec), and our 'ISP' is also running secondary DNS. – l0c0b0x Jun 10 '09 at 23:28
  • 1
    Ditto. Also with a class-B, also running our own BIND DNS servers. And when we have DNS problems, it's usually with our off-site ;) – sysadmin1138 Jun 11 '09 at 01:51
  • Great answer; this is my favourite answer for this question so far, because it's actually based on both sound engineering practices and realistic estimation of available redundancy and availability, as well as personal experience; whereas so many other answers simply list their favourite third-party DNS provider, or blindly copy the briefs written by people with a clear conflict of interest of making extra money from the overengineered solutions they propose. – cnst Jan 06 '17 at 20:31
5

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.

Kyle
  • 1,849
  • 2
  • 17
  • 23
4

Take a look at Dyn.com; they have all sorts of DNS related services such as DNS hosting, dynamic DNS, MailHop, etc, etc. I've found them reliable and been using them for probably 5 years.

Knox
  • 2,453
  • 2
  • 26
  • 33
4

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."

dlamblin
  • 929
  • 2
  • 10
  • 20
  • This is certainly a feel-good approach; but if a manhole catches fire, and your whole infrastructure goes down, sans DNS, what's the point of the DNS still being available, when none of the servers could be contacted? :-) I think going into the trouble of third-party secondary DNS only makes sense if you yourself outsource some other services to other third-parties as well. – cnst Jan 06 '17 at 21:41
  • @cmst The point is, when dns is down, anyone who emails you, they see an immediate problem (customers? partners? very bad publicity). If the dns works and mail server is down for some hours, they mostly don't notice a thing. – kubanczyk Jan 06 '17 at 22:13
  • @cmst DNS isn't limited to pointing to servers on my personal network. I can name IPs anywhere. Like, maybe I have a name for each of my employees/friends home network NAT boxes. Or I could use other record types and publicly identify/verify something. – dlamblin Jan 07 '17 at 06:47
3

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.

tep
  • 304
  • 1
  • 5
  • Whilst it's true that it's easier to simply use the DNS of the registrar, it's not all that uncommon for a registrar's DNS to be down, all the while both the domain registry and your own host are up, yet your site ain't available, because you've added an extra point-of-failure to your setup for the sake of ease. It's really not that difficult to run your own DNS; especially nowadays with the plethora of lightweight and easy-to-use servers. – cnst Jan 06 '17 at 21:32
3

As already mentioned in this thread, there several special cases with DNS, the most significant difference is between authoritative and caching name server deployments.

  1. 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.

  2. 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.

Taras Chuhay
  • 645
  • 3
  • 9
  • Many people also endorse a DJB's view of *never* running a DNS cache (the recursive resolver) on the same system as a serving DNS (the zone file storage). This is for security reasons, so the holes in one don't impact the other and vice versa. – kubanczyk Jan 06 '17 at 22:59
3

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.

Aaron
  • 2,809
  • 2
  • 11
  • 29
  • Whilst overly enterprise-centric, this is a reasonable good answer, could whoever gave the -1 please explain themselves? – cnst Jan 06 '17 at 22:20
  • 1
    Two good fresh points about the API and the vendor mergers. Two DCs are OK, but also note to have separate ISP for each, not the same ISP. – kubanczyk Jan 06 '17 at 23:22
  • Good point @kubanczyk muiltiple ingres links for sure and automated failover and health checks on them. – Aaron Jan 06 '17 at 23:51
2

I've used Zonedit or years. Its cheap (or free) and I've added lots of CNAME, A, MX, TXT, SRV, and other records.

Steve Jones
  • 795
  • 5
  • 8
2

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.

mrdenny
  • 27,074
  • 4
  • 40
  • 68
  • 2
    Is your e-mail hosted at that site as well? Keep in mind that if you lose connectivity there, and e-mail is outside that network, that your MX records will disappear and e-mail will stop working even if it's housed elsewhere. If it's at the same site as well, not a big deal, but I've seen this argument fall apart for this reason several times in the past. – Justin Scott Dec 01 '11 at 09:04
  • 1
    Yes, those guys are hosing their email at the same site (I'm not at that company any more). – mrdenny Dec 01 '11 at 21:25
2

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.

codebunny
  • 211
  • 1
  • 5
  • The problem with third-party DNS is that if it's down, even if your site is up, people can't access your domain. (So much for redundancy!) – cnst Jan 06 '17 at 21:00
2

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.

XTZ
  • 183
  • 1
  • 1
  • 10
  • This practice is called split-horizon. It's probably not applicable to most setups, frankly, and has been rather outdated, outside of the big enterprise, for quite a while now. – cnst Jan 06 '17 at 21:03
  • @cnst Split-horizon (or split-view) is serving **different** **zone** under the **same** domain name, and XTZ didn't say he recommends it. An internal server usually serves a different domain name (maybe subdomain). – kubanczyk Jan 06 '17 at 22:51
2

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.

pauska
  • 19,532
  • 4
  • 55
  • 75
2

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?

Maximus Minimus
  • 8,937
  • 1
  • 22
  • 36
2

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.

2

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.

  • LOL, great ad-piece, can I get the number of your marketing department and their copyeditor? I'm marking as an obvious spam candidate, but at the same time I won't at all be surprised if this flag, too, is declined! – cnst Jan 06 '17 at 21:45
1

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.

dmourati
  • 24,720
  • 2
  • 40
  • 69
Brian
  • 59
  • 1
  • 1
  • 3
  • I don't think this is true in regards to `MX` records; in fact, it's one of the misconceptions documented at http://cr.yp.to/djbdns/third-party.html. – cnst Jan 06 '17 at 21:38
0

It depends.™

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.

cnst
  • 12,948
  • 7
  • 51
  • 75