Do you guys perfer to host your own DNS or have your isp do this? I have my ISP doing this but there are limitations on adding records and I am thinking to running my own DNS. Are ther alternatives which I can look into?
|
8
|
|||
|
|
|
|
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 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. |
||||||
|
|
|
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. |
||
|
|
|
|
I've used Zonedit or years. Its cheap (or free) and I've added lots of CNAME, A, MX, TXT, SRV, and other records. |
||
|
|
|
|
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. |
||
|
|
|
|
Take a look at DynDNS.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. |
||||
|
|
|
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. |
||
|
|
|
|
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. |
||
|
|
|
|
As already mentioned in this thread, there several special cases with DNS, the most significant difference is between authoritative and caching name server deployments.
|
|||
|
|
|
|
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: |
||
|
|
|
|
I'd recommend OpenDNS Some routers can be configured to point DNS requests to OpenDNS. |
||
|
|
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. |
||
|
|
|
|
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. |
||
|
|
|
|
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? |
||
|
|
|
|
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 que on servers trying to send email to our domain. |
||
|
|