Do I need a DNS server on my Linode?
Whilst I understand what a DNS server does etc. I don't fully understand why I would want one on my own server.
My ISP provides me with a DNS that I access when I'm browsing the web from my workstation. I assume that all the visitors to my site would have the same arrangemet.
What benefits do I gain by hosting a DNS server?
Cheers,
Nap
7 Replies
There is no particular benefit to running a DNS server on your Linode, unless you manage a lot of domains and/or want to do something not supported by the other options.
If everything is working and you're happy with it, stick with what you've got. If not, I suggest you use Linode's DNS servers.
If you do want to run a DNS server on your Linode, I suggest you do what I do – slave Linode's DNS servers of your master server. Properly configured, this approach reduces the security risks and keeps your server load to a minimum.
I am already using Linode's DNS servers for 2 .com domains I own, even though I'm still setting up my linode. And a 3rd domain, my main one, is being hosted temporarily by a web hosting company until I complete my setup, so I'm using thier name server in the mean time. I'm not planning on hosting any more domains at the moment, but that might change in the future.
Things seem to be working ok for me, hence my question.
I guess, if I were hosting sites for multiple clients, a DNS server with my domain name would make my 'image' more professional.
By using Linode's servers, considering my VPS is part of their cloud, I see no real 'loss of control' or additional risk.
Also, as I have a single Linode 512, the master/slave setup you have, wouldn't really be needed here.
I'm also making the assumption that it is possible to setup a DNS server later on when I feel I would need it.
Am I understanding things correctly?
Cheers,
Nap
Cloudflare
@yaz:
(…) I could instantly rollback my domain to my old server which was still online and then switch it back to Linode when it was up again.
Of course this is subject to the TTL on your records, and any clients whose cache was ignoring the TTL, plus nowadays any browsers with internal application caches. In practical terms (for clients) I think best case is much slower than instantly, though something on the order of 60s for a large percentage of clients should be doable. That is, propagation time for the DNS servers is usually a small part of the latency involved in switching addresses, compared to getting all the clients to obey the new value. Of course, this doesn't make using a third party a bad idea, only that they can't magically address client side issues any more than you can yourself.
In terms of this thread, while no, there's no "need" to run your own DNS server, if update latency is an important factor for you, running your own server (and slaving Linode's servers for redundancy) does have an advantage of allowing you to minimize update latency while remaining "in-house". Managing domains through the manager needs to wait for the 15-minute refresh cycle, using a local name server with notifies will refresh the zones in Linode's servers immediately.
So as long as you decrease your TTL before making changes, and of course, wait at least your prior TTL before starting, you can make quick switches without a third party. I'd probably stay above a 30-60s TTL to avoid risking some cache deciding to ignore you. If it's a web service, things like the default Firefox browser cache expiration of 60s puts a floor on changes anyway, so lower TTLs are of limited use.
Even then (whether in-house or third-party) there may be a small percentage of customers who take much longer to adjust, so depending on the importance of the server, when possible it's best to maintain an overlap in both addresses until you actually see no requests hitting the old address.
– David
@Napoleon:
Also, as I have a single Linode 512, the master/slave setup you have, wouldn't really be needed here.
One of my Linodes is the master, Linode's DNS servers are the slaves – this works with just one Linode -- you lock down the DNS server on your Linode so it only talks to the slaves, minimising the number of possible attack vectors (and leaving the Linode team to worry about most of the security issues).
@Napoleon:
I'm also making the assumption that it is possible to setup a DNS server later on when I feel I would need it.
Absolutely.
Over the 6 years that I've had a presence on the web, I've been with the same hosting company. They were also my domain registrar.
I finally decided to move away from them. Their prices weren't reflecting market trends, and I considered it rather rude of them to be offering better packages (though still pricy) to new customers that I, as a loyal customer, wasn't elligible to take up.
On top of this, the quality of their service was in decline.
When making the move, I, being in Australia, had to keep my .net.au domain registered with an Australian registrar, but my site could be hosted anywhere. The company I've registered with also provides a hosting service, but whilst cheap, didn't provide some key features I required. So for the first time, the site and domain registra are seperate.
When I updated the name servers to reflect the changes, I was rather amazed at how quickly they had taken affect, a matter of seconds it seemed. My previous experience had been in the order of a few hours.
So, here I am at Linode, through a recomendation by a knowledgable friend. My live site is still hosted elsewhere, until I finish setting up my server here.
@yaz:
Something to also consider is that managing your DNS through certain third-parties such as
allows you to have instant DNS "propagation" across the Internet with server/IP changes, in addition to the general benefits of Cloudflare. This instant switching was invaluable for keeping things online last month when I switched over from another webhost, but Linode was having stability issues. I could instantly rollback my domain to my old server which was still online and then switch it back to Linode when it was up again. Cloudflare
Great point. With CF all VPS IP's are behind Cloudflare's proxy so propagation is not an issue and is done within seconds internally at CF edges.
There is one pitfall though - you would have to make IP changes timely. By default if you set up two IP's for lets say example.com CF will alternate between the two automatically (a round robin load balance). The only issue is if one of the IPs is down, CF isn't smart enough to stop using it.
Without CF most modern browsers (lets say chrome) would automatically try the second IP, if the first was down, but with CF the only IP's returned to users is CF's anycast IPs not your VPS'.