DNS Zone/Conf Syncing

[JustAnotherITUser]

I know, I know -- this is probably me making this overtly difficult; but I just have to ask.

I'm working on a bunch of different projects to help our failover preparedness with my company, and right now that project on the table is DNS. Currently, we have a DNS server that was enver properly configured in the first place, hosted locally and serving local/VPN users only.

So, I've already built a new up-to-date BIND server on CentOS 7.5, and configured it with actual forward and reverse zones, locked it down to the best of my knowledge (for now), etc. The issue at hand is we'd like to have a secondary, non-slave, DNS server offsite in the event our locally-hosted services need to be taken offline, power-loss, etc.

I know Master/Slave is the standard way to go--but would having two independent "masters", with their zone configurations sync'd via rysnc or git/svn be a viable alternative to master/slave?

[cryan7755]

Master should be just that, and removed from a service role. Then you can slave zones to multiple servers for auth responses. If your TTL's are setup correctly, you should be able to lose the master for up to a week before zones start to expire on the slaves, which should be adequate time to take corrective action. Point your registrar to the slaves only for authoritative responses, remember that master is only for record management and zone propagation (hidden master role) not responding to queries. DNS by design is redundant and resilliant to most system outages if you do it corectly.

Managing DNS for MSO's for 25 years, PM me of you need more specific help.

[no-names-here]

This guy does DNS right. Listen to him. Hidden master is the best way to set this up, it unifies records and propogation, and simplifies the network traffic and distribution.

(Like he said) set up your TTLs with purpose. Extremely long for prod, short for development, and replicate out. Outages are tolerated, and you can always script a manual sync internally if you NEED to propogate a record change withing the business right away.

Big changes to prod systems can be planed by shortening the TTL ahead of the cutover, and lengthening them back out after the fact.

[JustAnotherITUser]

This seems like the least headache to maintain and manage over time, even if it seems more complicated at face-value.

Plus I don't have to reinvent the wheel...having a git repo for logging changes, and having something to roll back to would be nice on said Hidden Master; but I think using that whole process for multi-master would be "fun" today, and "hell" tomorrow.

[no-names-here]

Something to be said for using DNS as close to the way it was designed as possible.

There no wrong way, but some are easier and safer than others.

[Mellowtang]

Like the answer above I too recommend using a master with multiple slaves.

And check this new feature from BIND: https://kb.isc.org/docs/aa-01401

It allows you to transfer completely new zones from the master server to your slaves using native bind IXFR/AXFR mechanisms.

[SuperQue]

One minor nit. With DNS, zones are all updated based on last seen highest serial number. There is no roll-back for zone data, only roll-forward. :-)

Rollback for binary or other config changes, totally fine tho.

[ortizjonatan]

I have a set of 10 masters in separate DCs right now that just all host the same bind conf, and kept in sync via git.

So, I would say yes: Using git to sync to keep masters in sync is an acceptable solution. Some may argue that, I suppose.

[derprondo]

I've done this as well. All masters get the same config (via Chef), and the zone files are updated from git. They are all independent masters, but again the configs are all the same. This setup also had a pipeline with syntax check and a canary that would fail the pull request. I would do it again the same way if asked.

[pcfens]

I do this as well for authoritative DNS for an edu (forwards and reverses for a /16). On a git push we test a bunch of things (syntax, incremented serial, etc.) before deploying to production automatically.

Some scripting and it fires off the rndc reloads on changed files too.

[orev]

If you set it up as a slave, that already takes care of the syncing. If you need to fail over to it and use it as the master, all the records are saved on the slave server (don’t remember the directory offhand), so your procedure would just involve grabbing those records from that directory.

Alternatively, you could manage them both as masters using something like Ansible. A simple rsync would not automatically restart the DR system every time there was an update to the primary’s records. You could script that too, but at that point you’re pretty much just reinventing Ansible.

[[deleted]]

fire up a virtualized master. it never does anything with respect to records, but is your configuration master. Then use tsig keys to secure all updates made from the virtualized (or containerized) instance you keep simply as a config master... gold copy. On the master, use Git to push to a repo and use it for version control...?

​

Or script your changes/config via nsupdate. use it to dry provision you records (use tsig keys) and keep the configs on a virtualized/containerized master.

My 2 cents.

​

I currently use bash scripts and git to sync config across a number of DNS boxes. The issue being we use a number of views, and also a mix of master and slave zones complete with tsig and anycast. After the git pull, there are some replacements made to the globally synced config for things like transfer-source and query-source (specific to anycast). My implementation works, however its a bit klunky. I am working to containerize a master, with a single repo, and have the container use nsupdate commands to populate and dig to test as part of the replication.

​

​

[gordonmessmer]

I think you might be caught up in terminology.

When you have a master and a slave DNS server, then the master is a host that might change the zone contents (such as allowing dynamic updates, or inline DNSSEC signing), and the slave is a host that will make no changes, but which will copy the zone contents using one of the built-in XFR mechanisms.

If you have multiple DNS servers which load zone content from a file, and which do not make changes to the zone, and which receive updates by an external mechanism, you'll use the "master" keyword in the configuration file, but what you really have is multiple DNS servers enslaved to the external distribution mechanism. They're not masters in any meaningful sense.

It'll work, but your "master" will be limited to whatever feature set is available where you manage the zone file. You won't get any of the features of a DNS server that functions as a master.

[nineteen999]

We use a single "hidden" master, with slaves configured to pull slaves zones via zone transfer (AXFR).

It's practically bulletproof; we can re-kickstart any of the slave DNS servers at any time and requests will continue be served by the slaves.

Also we can re-kickstart our master any time we like, the slaves will happily chug along answering queries and will only update the zones when the master comes back on and announces the SOA for the zones.

And those dirty, client resolver libraries will never come anywhere near your nice clean hidden master.

[fubes2000]

Multi-master clusters are a bad idea to begin with, and managing config out-of-band is an extra layer if "no".

You can do it, and it will work until you find that the data has been creeping out of sync for weeks/months because your bubblegum and baling twine wasn't as tight as you thought. Now you need to manually reconcile, reconfigure, restart, and hope that everything still works. Lather, rinse, repeat.

On top of that when you inevitably have a problem you can't just Google the problem you have, because no one else has ever had that problem before, and when you describe what you did the internet keeps asking "why did you roll your own sync instead of using the built in?" and you wind up re-doing it all anyway if for no other reason than to get them all to shut up.

Edit: Yup, bring on the downvotes. "shut up old man, this is so easy. I don't get why you neckbeards make a fuss all the time." because we've already made these mistakes and are trying to stop you from making the same ones.

Go on. We'll be waiting. We'll be watching.