Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm setting up a failover system for DHCP and DDNS. The software being used are ISC BIND and ISC DHCP, running on Ubuntu 10.04 LTS.

serverA runs DNS01 and DHCP01, serverB runs DNS02 and DHCP02. DHCP failover is set to a 128-bit split (half the zone on each server), wich is working correctly.

serverA is set as the master DNS, serverB is secondary (slave).

Where should DHCP02 point its dynamic updates? Can a slave zone be updated with DDNS entries and then be AXFR'ed back to the master, or do I need to point all DDNS updates to DNS01, both on DHCP01 and DHCP02?

share|improve this question
For those of you who want to suggest Windows DHCP+DNS: Microsoft requires CAL for each client, wich is out of the question. – pauska Feb 16 '11 at 9:10

4 Answers 4

up vote 2 down vote accepted

Looks like this is not doable. I tried to lab it, and the secondary DHCP fails with errors in the syslog about not being allowed to update the zone.

share|improve this answer

Works for me for years. Both servers in a failover set are updating the master (why anyone of them should even try to update the slave ?). Master is replicating to the slave.

share|improve this answer

I have the following in /etc/dhcp/dhcpd.conf, on both servers:

ddns-update-style interim;

include "/etc/bind/rndc.key";
zone myzone.lan. {
    key rndc-key;
zone {
    key rndc-key;

And I copied the primary's /etc/bind/rndc.key file to the secondary DNS/DHCP server. This way, the dhcpd.conf file section above is exactly the same on both dhcp servers.

Alternatively, I could have copied the primary's DNS key to a different file, and specified that file in the dhcpd.conf file of the failover.

It seems to work, so maybe pauska's answer saying it's not doable is obsolete. I have this running on Debian Squeeze with isc-dhcp-server version 4.1.1-P1-15+squeeze2.

share|improve this answer
-1 Completely not what the Question is asking... – Chris S Mar 2 '12 at 19:05
@Chris: ???. The OP wants both his DHCP servers to update his primary DNS zone. Using the primary DNS key on both DHCP servers, and configuring them both to send updates to the primary DNS allows that. Seems to me that was exactly the original question. "Where should DHCP02 point its dynamic updates" : to DNS01. – mivk Mar 2 '12 at 19:33
You're getting caught up in that one little sentence. He's really asking if multiple BIND servers can accept updates for a dynamic zone. The answer is no, which is what was already answered. The author was well aware of how to configure two servers to send updates. The Question is concerning failover ability within BIND for dynamically updated zones; which there is none. – Chris S Mar 2 '12 at 19:41
Well, I still disagree. The last part of the question summarizes it: "or do I need to point all DDNS updates to DNS01, both on DHCP01 and DHCP02?" (the answer is yes). – mivk Mar 2 '12 at 19:46

It should be sort of doable, but needs the master DNS to come back up eventually.

Firstly, you need to use the "allow-update-forwarding" parameter in the slave DNS zone. Use the same key as you use the "allow-update" in the master DNS zone.

Secondly, you need to tell the DHCP servers to contact the secondary DNS servers if they fail to contact the primary. To do that, list the secondary DNS servers in the DHCP zone, e.g.:

zone myzone.lan. { primary; secondary; key rndc-key; }

Now if the master DNS goes offline, DHCP servers can send dynamic updates to the slave DNS server and it will queue them up to be sent to the master when it comes back online. Unfortunately, DNS clients won't see the dynamic updates until the master comes back online, receives and processes the pending dynamic updates from the slave, and redistributes the updates back to the slaves.

share|improve this answer

Your Answer


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.