Master/Slave DNS setup vs. rsync'ed DNS servers

Question

We currently have primary and secondary DNS servers on our corporate network. They are setup in a master/slave type setup, where the slave gets its DNS information from the master.

I'm trying to figure out what the real advantage is for the master/slave setup instead of just setting up an automated rsync between the two to keep the DNS settings matched.

Can anyone shed some light on this? Or is it just a preferential thing? If that is the case, it seems like the rsync setup would be much easier to setup, maintain and understand.

Answer 1

The master/slave configuration (also known as “zone transfers,” AXFR or IXFR) is the standard configuration used by most DNS servers. For that reason alone, it’s what I’d recommend, even though it’s complicated.

Although I recommend it for interoperability, and because it’s easy for other admins to understand, that doesn’t mean it’s technically the best way to do it.

Daniel Bernstein (of djbdns/tinydns) strongly prefers rsync and has this table comparing rsync vs. zone transfers. rsync works great with tinydns but I’ve never tried it with bind.

If you try it, keep in mind that you’ll probably be writing a script that gets run by cron. Another admin who looks at your DNS configuration won’t necessarily know this, or know where to find the sync script. By contrast, the regular zone transfer config is right there in your zone files, making it explicit. Whether this matters depends on how many other admins you deal with and how informed you expect them to be about your DNS configuration.

Answer 2

There's actually a lot going on here, but much of it may be irrelevant to your situation.

First, using DNS master/slave relationships allows easy replication across heterogeneous server types. I know I've synced a primary OS X Server (BIND?) server with Windows DNS.

This also allows you to specify that a secondary DNS system may retrieve from different primary servers for different zones (and vice versa). A practical example: We used to run our own DNS system, and outsourced additional secondary DNS for reliability.

Expanding DNS servers is also easy this way. You simply add the new slave to the list, instead of adding the additional name server, setting up additional replication, etc. This keeps the process relatively self-contained.

Answer 3

There are a few reasons to use AXFR / IXFR rather than rsync:

1. It's standard, and works across all conformant implementations. This allows you to mix servers - perhaps if you want resilience in case of a security issue with one of your vendors

2. It's fast - changes on the master can be replicated to the secondaries within seconds if you use the NOTIFY mechanism. (the master tells the secondaries that the zone changed, and then the secondaries can grab the changes with IXFR).

3. It's reliable - there's zero chance of your server somehow getting a half-copied file and thinking that's the whole file.

FWIW, we use IXFR here on a very big zone. It "just works".

Answer 4

Assuming BIND here.

• If you update your zone records, on a reload the master will normally notify the slave(s) of a change. The slave will then fetch the updates.
• Using rsync the updates will only propagate when rsync is run. Plus the then need to tell the slave to reload the changes.

It seems to me that using rsync is not only more trouble, it just creates more things to go wrong, possibly leaving the master and slave out of step.

Answer 5

It seems like an rsync and an IXFR would end up doing just about the same thing. You'd be fine rsyncing from bind9->bind9 for example but if you needed to go from bind8->bind9 or bind->Microsoft a zone transfer should still work despite the differences in backend. The plus to going rsync-only as I see it is that you could disable zone transfers entirely, which is nice from a security standpoint.

Answer 6

We've run bind with rsync since 1995 - Works fine - There's plenty of reasons to go tinydns and/or zone transfers today but the logic back then, and why we've stuck with it today, is if one server got hacked somehow there is no true "primary" to then replicate the problem to the others.

That said having the primary internal to your LAN and slaves reachable on the Internet also solves the problem.

We push out the rsync and reload via scripts, along with some sanity checks - If you go that route consider adding all these pieces incase something goes wrong - You REALLY don't want your DNS servers down or even missing zones.

Answer 7

I typically do what is natural for the given situation.

When using bind, depending on the situation, I will typically run 2 masters and several slaves.

Changes are made one master; those changes are validated then rsynced to another master. That master uses zoen transfers to send the zones to the DNS servers clients see. The other two aren't advertised. (the first master isn't strictly necessary, but it is nice to have a scratch monkey) I also like having 2 copies of the server configs and 2 copies of the zone files in a proper format (instead of the copy you get on a slave server). Care must be taken in making sure the server reloads the zones only after the rsync finishes.

When you're using AD for DNS, you don't need to worry about exchanging zones between servers -- the AD protocols magically take care of synchronizing everything.

PowerDNS expects that you will use zone transfers or you use some database replication mechanism to keep things in sync.

TinyDNS can use zone transfers but if you're transferring files within the same organization it makes sense to use something like rsync because the tinydns server makes reloading zones safe and easy.

Lastly, and most importantly -- use zone transfers if you're exchanging DNS zones with organizations outside of your direct control. For instance, it is common place to have your ISP host an authoritative server for customers. That server will be a slave server and get the zones via zone transfers, regardless of what type of DNS server the customer is running. Similarly, if I outsource my DNS to a provider like UltraDNS, I'll insist on being able to do zone transfers of my zones from their servers, so I can leave them at any time by updating the registrars to use my servers instead of theirs as the authoritative servers for my domains.