In order to provide reliable DNS service, it is standard practice to operate two DNS servers. This allows you to take one DNS server down for repairs while the other server remains operational and continues to serve DNS data.

Never have two DNS servers using DLZ both communicating directly with the same database server. This will cause both DNS servers to be useless if your database server goes down.

When not using DLZ, usually one DNS server is setup as a "master" and all other DNS servers are setup to be "slaves". All DNS updates are done on the master DNS server and propogated to the slave DNS servers via "zone transfers". While this method of data replication is necessary when not using DLZ, and is in fact the "standard" way (according to the RFC's) of propogating data, it is not how data replication should be handled with DLZ.

One of the main goals of DLZ is immediate DNS updates. By using zone transfers, the data on your slave DNS servers will not be updated until the zone "expires" and the slave performs a zone transfer. If you have a long zone expiration time, your slave DNS server may be out of sync with your master for a long period of time. If your zone expiration is short, you may be copying a great deal of data from the master server to the slaves unnecessarily. Often only one, or at most a few, records have changed in a zone, but zone tranfers with DLZ require a full zone transfer - resulting in a lot of wasted data being sent across the wire.

DLZ does, however, support zone transfers if you insist on handling DNS data replication in this manner. Be forewarned that using zone transfer with DLZ will negate many of the benefits of using DLZ for your slave DNS servers.

The best practices section discusses using database replication as a means to provide reliable redundant DNS service. The replication schemes below represent some ways you should NOT implement database replication.

Most modern databases support triggers. Using triggers you could update all the databases on the DNS servers automatically when the data is changed in your master database. While this option sounds good initially, it has some serious drawbacks.

A simple implementation would attempt to immediately update all the other databases on the DNS servers. If even one of those other databases were unreachable, your trigger would fail, causing the transaction to fail on your master database. This causes your database system to be very fragile because if even one database server is down, you are prevented from making changes to your database.

Even worse is the possiblity of corruption. It is quite possible that your trigger may need to update two or more of the other databases. If the first one or two updates to the other databases was successful and the last one failed, you have a serious problem. Since the master database trigger failed, the entire transaction failed, and the person attempting to make the change thinks it didn't happen. They expect the DNS data to be in the databases unmodified.

Manual replication involves polling your master database to determine if any data has changed since the last time you communicated with it. Polling produces an unneccessary load on the master database server and wastes bandwidth, too.

If you poll the master database server often, you are wasting a great deal of resources on the master database. If you don't poll often enough, your slave database servers may be out of sync until the next poll, and thus your DNS server is also out of sync. As you add more DNS servers, the situation becomes worse because there is even more polling activity on the master database. I highly recommend avoiding this option.