New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Correct way to setup DNS and maybe VPS redundancy
trycatchthis
Member
in Tutorials
Usually when I setup a VPS I use Bind to handle the DNS.
I believe this could cause email to not be delivered if the VPS goes down for any amount of time.
Should I then be using the DNS at the domain registrar and only point the A record to the VPS?
Also with webpage load speed being a thing will the DNS on a typical VPS be any better than that on another service?
What is the best practice?
Comments
You need two DNS servers minimum. Period. If you are using the same IP twice, that is not best practice. The two DNS servers should be on a different network so that if one goes down the other remains accessible - DNS has inbuilt redundancy through the multiple nameservers.
Whether to use the registrar's nameservers, your own, or another service (HE.net, Cloudflare, etc.) depends partly upon your own ability to maintain, how your traffic is distributed, etc. If you are running a simple (static) DNS and only have one VPS, then honestly you should use someone's service.
Hosting the DNS yourself may slow down the lookups, because most services that are worth considering use anycast with nameservers distributed across the globe; at least there is unlikely to be a speed advantage in operating the DNS yourself. Your VPS will tend to give quick answers to those close by, but slower answers for those further away (which may or may not be important depending on how your traffic is distributed).
So lets say for instance you have a VPS with one IP address. How would you implement redundancy in that case? Thanks for the reply.
You'd get a second VPS.
You can't. If this is the case, you are below the minimum requirements and should use a DNS service or get a second VPS, as pointed out above.
Would the purpose of the second VPS be to have a redundant nameserver service running?
If so are you supposed to duplicate the nameserver service from the primary to the backup?
That said why would you want the hassle of hosting your own DNS when you can get free DNS service from providers like Dynu?
You just need two dns servers delivering consistent answers when queried for your domain. The servers don't even have to use the same dns software (one can run Bind on Debian, the other NSD on Ubuntu). The DNS zone they use to answer requests for your domain just has to be kept in sync between servers, no matter how: rsync, copy-paste, axfr...
(purists will hate me but that's the general idea).
Small twist: If you on the one hand want to run a DNS server yourself, maybe for gaining experience, but on the other hand to not run 2 (or more) DNS servers yourself you can look out for a service willing to only run the secondary (or in DNS parlance, a slave) for the master you run yourself.
A word of warning though: Virtually all of those (few I guess) providers will expect your master to be fully and properly configured, in particular wrt record updates/transfers.
Generally speaking. Who on earth would want to copy and paste DNS records?
What is the generally accepted way / best practice for updating the secondary DNS?
I have almost always used systems with some kind of web panel CPanel, DirectAdmin and others which I cant remember. I never thought about it much because everything usually just works. On CPanel bind runs as a service along with everything else so is it better to separate it from the main web server?
Many ways but mainly AXFR.
Properly configured master nameserver takes care of this. There is "notify" and "also-notify" directive in bind configuration...
Sorry, I can't help at all wrt panels.
Yeah, sure, Notify/AXFR/IXFR is usually the way to go. I was just making a more general point about how, for most use cases, all the dns servers must be kept roughly in sync, and equally available (i.e. no such thing as a "main" and "backup", the terms "master" and "slave" being just a matter of one-way syncing)
PowerDNS is another good way to implement it, you just need to setup mysql slaves and all your records will be synched across all your DNS Servers, you can setup as many as you want
Even if you are using cPanel or any other panel (if it uses PowerDNS) just find out the DB/table for PowerDNS enable replication for that particular table and setup mysql slaves
Yes, and: I didn't relate or object to your post.
Not really. There is a master and there are slaves, by definition. that all must be available is one point, but how to keep their content in sync is another one.
If you're using PowerDNS with MySQL replication, you can use multi-master replication where multiple nodes are masters, and the replication happens two ways. This is useful for when one master goes down (you can keep performing writes to a different master), however the consistency guarantees aren't as strong as with a single master and you're more likely to hit potential conflicts (eg if you update the same row in different ways on two masters and there's a delay in the syncing)
Adding a SQL DB (and in particular MySQL) to a DNS server adds complexity that is absolutely not needed in > 99% of DNS servers and should be avoided unless absolutely necessary.
Also, if really needed "out of band" replication can also be done by other and more reliable means.
I do not think well of going towards ease-of-management (in particular in relation with panels) on the minimalism and professionalism vs ease-of-management axis.
Also I of course strongly dislike "out of band" solutions with critical infrastructure. DNS does offer a built in and (well, largely) standardized solution and I fail to see how it would be advantageous to rather rely on considerably more complex mechanisms (like MySQL replication).
In my experience, MySQL replication was far easier to configure and monitor and less complex than anything with DNS AXFR, plus I was already using MySQL for other purposes so I already had the replication configured. Maybe I'll have another go at a non-MySQL PowerDNS configuration at some point.
In other words you are close to ease-of-management on the axis I mentioned above (as not healthy). I do understand that desire/approach but quite a few years in IT Sec tell a clear message: keep it simple, avoid complexity where possible, and do not add layers unless absolutely needed, in particular complex layers (like SQL).
So I commend your being willing to look at a solution without MySQL or, being at it, without any SQL DB incl. Sqlite, and btw the rather simple and clear cut structure of DNS data all but begs for a simple non SQL database (if any database at all) which also is faster than a SQL DB and which usually can be transferred or synchronized just as well and simple.
As a final recommendation I'd suggest you take a good extensive look at NSD.
What advantages does NSD have over PowerDNS?
Just from the top of my head: the organisation behind it is from a professional background, decades old and respected also in academia, a non-profit organization (unlike PDNS), does not want to sell anything and does not think in terms of markets (unlike PDNS/OX), close to diverse relevant standard bodies, the code is written in C (which is way better verifiable than C++, let alone Rust) (unlike PDNS), has a good track record, just works properly (unlike e.g. Knot or bind), is available in pretty much any and all relevant OS and distros, can grok bind zone configs (the "standard"), runs some root nodes, never even had the idea to add additional unneeded sh_t layers, and is smaller (the code base too).
But forgive me, I'm no salesman, I merely offer advice. If you are interested just have a look, if not then not; after all it's your zones and system(s).
This is accurate but remember DNS caches. The first lookup maybe be slow, after that you'll be talking to your ISP until TTL expires (and your browser caches as well).
I agree, if only because it's way simpler to manage than BIND. If all you need is an authoritative server (as opposed to a full caching server), NSD works very well.
https://lowendbox.com/blog/setup-a-dns-nameserver-using-nsd/
They'll talk to each other. Or you can do as I do - rsync periodically when things change. That's not as professional-grade but then I'm not managing very many domains and they rarely change.
They are also the people behind 'unbound', a server that has gained quite some (very good) reputation.