Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
add comment

7 Answers

up vote 7 down vote accepted

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.

share|improve this answer
    
That rsync vs. zone transfer comparison doesn't really feel very up-to-date, in regards to the status of notify, tsig, etc. –  andol Apr 9 '10 at 13:58
2  
would have upvoted but can't take you seriously whilst quoting old DJB stuff... ;-) –  Alnitak Apr 23 '10 at 13:12
    
+1 for future admins... don't reinvent the wheel. Zone transfers work and are standard. –  James Apr 23 '10 at 13:47
add comment

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.

share|improve this answer
add comment

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".

share|improve this answer
add comment

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.

share|improve this answer
    
Agreed -- rsync + Bind = catastrophe. The djbdns model has a server that doesn't stop serving requests when it is rereading the database and the database itself is updated atomically. With bind, if it rereads the "database (zone files) while the rsync is in progress, boom! –  chris Apr 8 '10 at 22:27
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
How is rsync any better to a transfer if the primary/master machine is compromised? Either way the zone file can be tampered with, which then gets transferred to the slave/secondary. –  John Gardeniers Apr 9 '10 at 3:50
    
Sorry, I should have clarified that - ALL public facing name servers are mirroring from an internal rsync server - The name servers have read only rsync access from a private IP rsync server. –  Steve Radich-BitShop.com Apr 9 '10 at 4:04
    
In regards to compromise, I still don't see how the benifit of your solution is about rsync vs. zone transfers. Wouldn't pretty much the same result come from having a hiden internal master, zone transfering to a bunch of public slave servers? –  andol Apr 9 '10 at 13:59
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.