howto: Dynamic DNS and DHCP dual servers with failover

Endwin · 04:51 PM

So you want to setup a few servers with redundant Dynamic DNS and dual DHCP that can handle one of them going out. Welcome to fun!

Tools of the trade...

Let's assume we want 2 servers a master and a slave. Our network will be 10.10.0.0. Master will have an IP of 10.10.0.1, and slave will have 10.10.0.2. We have bought the domain www.examplechangeme.com

Install DHCP and Bind9...

Code:

sudo aptitude -R install dhcp3-server bind9

Alright the setup...

MASTER

Master has some files we will want to mess with, first start with the main configure file. We don't need to make many changes to this one.

Code:

cd /etc/bind/
nano named.conf

At the bottom put...

Code:

controls {
	inet 127.0.0.1 allow {127.0.0.1; 10.10.0.1; 10.10.0.2; } keys { "rndc-key"; } ;
};

Wow, that is a lot of strangeness let us break it down.

Controls <= This block tells the bind server, "Hey these nice people here will be allowed to update you, please let them!"

inet 127.0.0.1 <= Who am I modifying? Myself. Here we say we are talking about the local bind server.

allow {127.0.0.1; 10.10.0.1; 10.10.0.2; } <= here I am saying who (by IP) is allowed to modify the DNS enteries. I am saying I can locally modify (hence the 127.0.0.1) also through my network connection (10.10.0.1) modifications can take place. I will also allow the slave machine (10.10.0.2) to modify the server as well. Feel free to add additional servers/remove servers as your needs permit.

keys {"rmdc-key";} ; <= This is the name of a key that is generated to authorize that the process/computer is allowed to modify the DNS. We will get more into this later. The name of the key (in " " ) is what is given by the default ubuntu install you may need to change this for other systems, or feel free to rename it as your own. Just remember to carry it on through the rest of this guide.

Ok done with named.conf save it and get ready for the next bit.

Code:

nano named.conf.local

Here comes some of the fun bits...

This usually starts off as a blank file with some comments at the top. The purpose of this file is to define all the user only zones (read domain names/networks). Again I will dump what I did and then work through it. Add the following to the end of the file (which is pretty much the begining just past the comments.

Code:

include "/etc/bind/rndc.key";

zone "examplechangeme.com" {
	type master;
	file "/etc/bind/examplechangeme.com.zone";
	allow-update { key "rndc-key"; };
	allow-transfer {10.10.0/24; };
};

zone "0.10.10.in-addr.arpa" {
	type master;
	file "/etc/bind/rev.0.10.10.in-addr.arpa";
	allow-update { key "rndc-key"; };
	allow-transfer {10.10.0/24; };
};

Well thats a mouthful...

include "/etc/bind/rndc.key"; <= This line includes the file rndc.key which was generated as a MD5 hash to be used to validate programs updating the DNS. Sort of like an include statement in programing. It dumps the contents of the file in the spot where the include is put.

zone "examplechangeme.com" { <= Here we are defining a new zone whose name is examplechangeme.com. It can be anything you want to make a domain or sub domain for. It could be home.lan or linux orhome.linux.lan.moo.cow.milk you get the idea. =)

type master; <= Since this is the master (Read main) DNS server we have to say so here. On the slave this will be diffrent. See if you can guess what it will be. HINT it starts with an s.

file "/etc/bind/examplechangeme.com"; <= Here we say where the address resolution database will be located. This is the file that holds the NAME => IP information along with some information. We will talk about the contents of this file later.

allow-update { key "rndc-key"; }; <= Here we are saying who/what can update this zone. Here we say anyone who comes to us with the rndc-key will be allowed to update the DNS.

allow-transfer {10.10.0/24; }; <= Here we are saying who can have a copy of our zone. (In this case I am saying anyone on the 10.10.0.0-10.10.0.255 network. This can be changed to just a set of IPs or left as is. For example you could have allow-transfer {10.10.0.2; 10.10.0.200;};

zone "0.10.10.in-addr.arpa" { <= Odd looking zone... This is a reverse lookup database one of these typically accompany a named zone. This file allows for reverse lookups. Say you typed in 10.10.0.5 and want to know what the name associated with that was. Everything else in the definition is the same as above.

On to creating the actual database files we made reference to in the two file directives above. From my research there are a few ways to make one of these files, the simplest method for me was to make a copy of one of the stock db files and modify it to my needs. So let's do that.

Code:

cp db.empty examplechangeme.com.zone
cp db.empty rev.0.10.10.in-addr.arpa

Let us edit....

Code:

nano examplechangeme.com.zone

Ok here I will display an example and explain as much of it as I know.

Code:

$TTL 86400
examplechangeme.com.       IN      SOA     master.examplechangeme.com. root.localhost. ( 
                              1       	; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL

examplechangeme.com.	IN	NS	master.examplechangeme.com.
examplechangeme.com.	IN	NS 	slave.examplechangeme.com.

master			IN	A	10.10.0.1
slave			IN	A	10.10.0.2

From the top!

$TTL 86400 <= Not exactly sure but from context I think it is the time to live (in secconds) of the names on the server.

examplechangeme.com. IN SOA master.examplechangeme.com. root.localhost. ( <- sets the domain. The master.examplechangeme.com. bit needs to be there so we know this is the main server the one following looks like some sort of place holder I decided to let it be as it is.

The long bit with serial, refresh etc sets the times for the name leases. Serial according to some sites is important to increment every time the file is modified. However in my testing I never changed it and it apeared to work fine.

Code:

examplechangeme.com.	IN	NS	master.examplechangeme.com.
examplechangeme.com.	IN	NS 	slave.examplechangeme.com.

Here we set what the name servers are (hence the NS) make sure to resolve the names bellow.

Code:

master			IN	A	10.10.0.1
slave			IN	A	10.10.0.2

Here we set some static names (good for servers) here I define master, and slave. You can put other things (and probably should) here like www, @, mail etc. One thing of note mail servers are dified diffrently the two ways I have seen this is...

Code:

examplechangeme.com.      IN      MX     10       mta.examplechangeme.com.

and

Code:

@       IN      MX      1       mail.examplechangme.com.

Make sure to define mail, mta, and @ bellow in the static sections if you add in mail servers.

Onto the reverse lookup database!

Code:

$TTL 86400
@       			IN      SOA     master.examplechangeme.com. root.localhost. ( 
                              1       	; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL

					IN	NS	master.examplechangeme.com.	
					IN	NS 	slave.examplechangeme.com.

1					IN	PTR	master.examplechangeme.com
2					IN	PTR	slave.examplechangeme.com

A lot like above with a few differences.

@ IN SOA master.examplechangeme.com. root.localhost. ( <= Note here we replaced examplechangeme.com. with @

Bellow that at the name servers we dropped the proceeding examplechangeme.com.

In our static resolution section we replaced the names with the last numerical address, and instead of A we put PTR. Since we are doing a reverse lookup we put the name in for the reverse lookup.

Save your changes and we will go to the next bit. In the folder we are in which should be /etc/bind/ we should make sure the files we will be modifying are owned by bind. Do a simple

Code:

chgrp bind *

and that should help resolve reading/writing issues later on.

Let's take a look at that key file. We are not going to edit it I am just putting an example so you understand its format.

Code:

more rndc.key

key "rndc-key" {
        algorithm hmac-md5;
        secret "fjs8FjKDo320jpWdmvcdwf==";
};

NOTE: This is not my key I just made it up. However this is the file that we included in our named.conf.local and note the name of the key is rndc-key this is an arbitrary name. IE it can be whatever you want. I just left the default, but if you want to you can change it.

Now we need to copy our key so that the dhcp server can use it.

Code:

cp /etc/bind/rndc.key /etc/dhcp3/.

Head on over to the dhcp directory.

Code:

cd /etc/dhcp3

Make sure dhcp can read our key...

Code:

chown root:dhcpd rndc.key

And now we edit the files...

Code:

nano dhcpd.conf

This file comes with a lot of commented out examples we will ignore them and just modify the top, and add our own information. At the top you will see

Code:

ddns-update-type none;

change it to

Code:

ddns-update-style interim;

next in

Code:

# options definitions common to all supported networks...
option domain-name "example.com";
option domain-name-servers ns1.example.con, ns2.example.com;

change it to

Code:

option domain-name "examplechangeme.com";
option domain-name-servers 10.10.0.1, 10.10.0.2;

leave the default lease time, and max lease time alone, unless you want to change them.

after the lease times put:

Code:

one-lease-per-client on;

Bellow that is:

Code:

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
# authoritative;

Uncoment authoritative so it looks like...

Code:

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

The log bit I left alone, however bellow it I put in our failover for dhcp directive.

Code:

failover peer "dhcp" {
		primary;
		address 10.10.0.1;
		port 519;
		peer address 10.10.0.2;
		peer port	520;
		max-response-delay 60;
		max-unacked-updates 10;
		mclt 600;
		split 128;
		load balance max seconds 3;
}

Ok the above works like this, failover peer "dhcp" { <- here we are declaring a failover peer and for the sake of simplicity we are naming it dhcp I could name it moo-cow or cookie-milk it is something so we can reference this failover peer. You can define multiple ones for different networks I think and as such have multiple decelerations of the above.

I set this server as the primary with an address, a port, and then I declare the peer (my failover/backup dhcp server) with an address and a port. Note the ports have to be different. From the few examples I was able to find 519 and 520 are the ones most used for this.

Max response delay, unacked, mclt, split, and load balance I am not sure on their exact purpose I think the max resonse is how long it will wait for the other server to respond before it takes over. Anyway the default settings here should work for most people.

Bellow our failover we should include our key, and the zones that we will be updating.

Code:

include "/etc/dhcp3/rndc.key";

zone examplechangeme.com. {
	primary 10.10.0.1;
	key rndc-key;
}

zone 0.10.10.in-addr.arpa. {
	primary 10.10.0.1;
	key rndc-key;
}

What this does is define the zones the DHCP is to update whenever a lease is given. Say bob.examplechangeme.com logs in gets an IP the DHCP server notifies the DNS server of the lease and modifies it so that whenever someone types in bob.examplechangeme.com they always get bob's machine no matter what address bob may have. Primary sets the server we will update and the key is to let the server know we are legitimate.
Now to make our subnet. bellow the zone section put.

Code:

subnet 10.10.0.0 netmask 255.255.255.0 {
	pool {
			failover peer "dhcp";
			range	10.10.0.50 10.10.0.254;
			deny dynamic bootp clients;
			allow unknown-clients;
		}
	option routers		10.10.0.1;
	option broadcast-address 10.10.0.255;
	option subnet-mask	255.255.255.0;
}

subnet 10.10.0.0 netmask 255.255.255.0 { <- here we define our network I am using subnet 10.10.0.0 with a mask (what bits of the Ips are mine) of 255.255.255.0 which means I have 253 Ips to play with.

Code:

	pool { 		
			failover peer "dhcp";
			range	10.10.0.50 10.10.0.254;
			deny dynamic bootp clients;
			allow unknown-clients;
		}

This section is specific to failover DHCP if you just want normal DHCP drop it all and just keep the range part. We set the failover peer definition (defined above) then the range of Ips it is allowd to toss out. The deny dynamic bootp clients; line is in reguards to a protocol for thin clients. If you have thin clients failover, from what I can tell, is not supported in the current dhcp server. The final line allow unknown-clients; lets you get an IP from the server. For some reason without it I was unable to grab an IP. You don't need it in a non failover setup.

Code:

	option routers		10.10.0.1;
	option broadcast-address 10.10.0.255;
	option subnet-mask	255.255.255.0;

This is info that you pass to the clients that connect. Your router may be a different IP and setting up a router is beyond this long howto.

We are done editing the master server! Our final finishing thing is to get a copy of the rndc.key file to the slave computer. You can do this via sftp, or copy/paste the contents of the file over. However you want to do it.

SLAVE MACHINE

Make sure you copied the key from master over to the slave. Put a copy in both /etc/bind/ and /etc/dhcp3 in bind make sure the group is bind and for dhcp make sure the group is dhcpd.

in /etc/bind

Code:

chgrp bind rndc.key

in /etc/dhcp3

Code:

chgrp dhcpd

We will start with the DNS server first, and edit named.conf.

Code:

cd /etc/bind
nano named.conf

Like on master we will do the same here at the end of the file put.

Code:

controls {
	inet 127.0.0.1 allow {localhost; 10.10.0.1; 10.10.0.2;} keys { "rndc-key"; };
};

Save exit and then to named.conf.local

Code:

nano named.conf.local

Again we have an empty file, things will be a little different. At the end of our comment file put:

Code:

zone "examplechangeme.com" {
	type slave;
	file "/etc/bind/examplechangeme.com.zone";
	masters {10.10.0.1; };
};

zone "0.10.10.in-addr.arpa" {
	type slave;
	file "/etc/bind/rev.0.10.10.in-addr.arpa";
	masters {10.10.0.1;} ;
};

A lot like before, the type of server is a slave (answer to pop quiz way at the beginning). File says where we are saving the files, and masters lets the slave know where to get the DNS information from.

Save and close.

We don't have to make our own databases for the slave since it will grab that information from the master. So that saves a lot of effort. Off to DHCP land, and dhcpd.conf!

Code:

cd /etc/dhcpd

nano dhcpd.conf

A lot of this will be the same as in master with a few differences. Since we will assume that if master is down we cannot modify the DNS on master I told it to modify the DNS on the slave. So whenever master is down slave's DHCP server takes over gives out IPs and modifies slave's DNS.

Code:

ddns-update-type interim; 


option domain-name "examplechangeme.com";
option domain-name-servers 10.10.0.1, 10.10.0.2;

default-lease-time 600;
max-lease-time 7200;

one-lease-per-client on;

authoritative;

failover peer "dhcp" {
	secondary;
	address 10.10.0.2;
	port 520;
	peer address 10.10.0.1;
	peer port 519;
	max-response-delay 60;
	max-unacked-updates 10;
}

Here we just change a few things around. We are the secondary server and we set things that were the peer on the master. Make sure to keep the ports and IPs straight.

Code:

include "/etc/dhcp3/rndc.key";

zone examplechangeme.com. {
	primary 10.10.0.2;
	key rndc-key;
}

zone 0.10.10.in-addr.arpa {
	primary 10.10.0.2;
	key rndc-key;
}

Note the change in the IP for the zone definitions. This is so the slave updates the DNS for itself whenever the master is down.

Code:

subnet 10.10.0.0 netmask 255.255.255.0 {
	pool {
			failover peer "dhcp";
			range 10.10.0.50 10.10.0.200;
			deny dynamic bootp clients;
			allow unknown-clients;
		}
		option routers 10.10.0.1;
		option subnet-mask 255.255.255.0;
		option broadcast-address 10.10.0.255;
}

Save and exit.

Wow I think we are done. On both servers issue the following commands to restart the dhcp and bind servers.

Code:

/etc/init.d/bind9 restart;
/etc/init.d/dhcp3-server restart;

In theory things should be working. Here are some troubleshooting/testing tips. This assumes your client machine is also a linux box.

NOTE: For the dynamic name update for DHCP to DNS you may need to edit /etc/dhclient.conf uncomment send host-name " STUFF HERE "; and replace STUFF HERE with the name of the machine, like bob, or joe, or mail etc.

Also make sure both master and slave's clocks are in sync DHCP and DNS failover/updating is VERY dependent on time. Set a cron job to update time.

dig

example

Code:

dig examplechangeme.com

You should get back something like this.

Code:

; <<>> DiG 9.3.2 <<>> examplechangeme.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51050
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www.examplechangeme.com.              IN      A

;; ANSWER SECTION:
www.examplechangeme.com.       120     IN      CNAME   examplechangeme.com.
examplechangeme.com.           120     IN      A       10.10.0.1

;; AUTHORITY SECTION:
examplechangeme.com.           120     IN      NS      master.examplechangeme.com.
examplechangeme.com.           120     IN      NS      slave.examplechangeme.com.

;; Query time: 187 msec
;; SERVER: 10.10.0.1#53(10.10.0.1)
;; WHEN: Fri Sep 29 11:15:05 2006
;; MSG SIZE  rcvd: 108

You are looking for the answer section to see if your IP was set. What this program does is check to see what the DNS has for whatever you sends its way.

dhclient is useful to see if the dhcp server is tossing out IPs like it should. The most useful flags were -r which releases the lease dhclient has.

example

Code:

dhclient -r
dhclient
dhclient eth0

If you have multiple cards using dhcp include the ethX in there so that you don't reset all of them.

Check /var/log/daemon.log and /var/log/syslog on the master and slave. I found this very helpful in tracking down problems.

You will want to edit /etc/dhcp3/dhclient.conf uncomment supersede domain-name and
prepend domain-name-servers. replace the domain name with your domain name and add to the domain-name-servers the IPs of your domain names. By doing so resolv.conf will always keep that infotmation if you are on a dynamic IP connection.

I hope this helps some people when I went on-line and looked for how to do dynamic dns, failover dns, dhcp failover, and the like I found poor/little documentation. If you have questions I will do what I can to help!

hellmet

wow that is a whole lotta
..
was thinking of doing this..
you've made it possible.
will possibly set it up tomorrow..

hellmet

uh... dude.. is it possible for you to cut short some of it..
and pm me ..? coz I have just one system, and one ISP
connection.. so I just need to setup Dynamic DNS server
on it..

Endwin

It is actually quite easy to set it up for just one server (I did it at home) All you need to do is follow the master part and just remove the stuff refering to the other server (Remove the failover sectoon of DHCP) and drop the pool section to just range 10.10.0.50 10.10.0.254

btdown

Thank you for this...I'll have to try it out.

BT

simidau

While it looks like it's working - have not checked that removing the master will allow everything to continue.

I looked in syslog and and found the following lines on startup of dhcpd and another unsure line every time a client gets an address.

Master server is normal

Startup message
--------------------------------------------------------------
Nov 29 14:37:47 server2 dhcpd: Internet Systems Consortium DHCP Server V3.0.4
Nov 29 14:37:47 server2 dhcpd: Copyright 2004-2006 Internet Systems Consortium.
Nov 29 14:37:47 server2 dhcpd: All rights reserved.
Nov 29 14:37:47 server2 dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
Nov 29 14:37:47 server2 dhcpd: Wrote 0 leases to leases file.
Nov 29 14:37:48 server2 dhcpd: failover peer dhcp: I move from recover to startup
Nov 29 14:38:02 server2 dhcpd: failover peer dhcp: I move from startup to recover
---------------------------------------------------------------

The last two lines ebing the ones I am unsure of?

Then when a client gets an address I get the following.
---------------------------------------------------------------
Nov 29 14:40:47 server2 dhcpd: failover peer dhcp: unexpected error
---------------------------------------------------------------

There is another error popping up
---------------------------------------------------------------
Nov 29 14:39:17 server2 dhcpd: failover peer dhcp: address not available

---------------------------------------------------------------

Any ideas?

Endwin

I would say it looks like something is misconfigured or needs to be tweaked. The lines

Quote:

Nov 29 14:37:48 server2 dhcpd: failover peer dhcp: I move from recover to startup
Nov 29 14:38:02 server2 dhcpd: failover peer dhcp: I move from startup to recover

indicates the mode the DHCP server is in. As for

Quote:

Nov 29 14:40:47 server2 dhcpd: failover peer dhcp: unexpected error

and

Quote:

Nov 29 14:39:17 server2 dhcpd: failover peer dhcp: address not available

I would need to see the setup for the files. Also check in /var/log/daemon.log. That sometimes gives a more detailed description of what is wrong then syslog.

zigford

Wish I had seen this earlier. I had tried to configure this in the past, but failed.

Now seeing you point to /var/log/daemon

I had no idea thats where bind info goes and I was able to fix my setup in seconds. Amen!

makadam

Hi.

Thanks for this wonderful tutorial.

Best regards

Makadam

Abhi Kalyan

That is a very detailed work that you have crafted, Thank you a Tonne.
Hope the following request does not annoy you.
"When you mean "master" is it the hostname of the primary DNS server or is it a code that points the services to accept this system as master?"
Like the Primary DNS server is "master.examplechangeme.com"
Hostname: master
Hostname -f: examplechangeme.com
Sorry if this is really a very small doubt.
hope you could throw some light on this subject.
I tried the WHole Manual asubstituteing things and am still not able to get it right.
Thank you

September 29th, 2006	#1
Endwin A Carafe of Ubuntu Join Date: Nov 2005 Beans: 119 Ubuntu 8.10 Intrepid Ibex	howto: Dynamic DNS and DHCP dual servers with failover So you want to setup a few servers with redundant Dynamic DNS and dual DHCP that can handle one of them going out. Welcome to fun! Tools of the trade... Let's assume we want 2 servers a master and a slave. Our network will be 10.10.0.0. Master will have an IP of 10.10.0.1, and slave will have 10.10.0.2. We have bought the domain www.examplechangeme.com Install DHCP and Bind9... Code: sudo aptitude -R install dhcp3-server bind9 Alright the setup... MASTER Master has some files we will want to mess with, first start with the main configure file. We don't need to make many changes to this one. Code: cd /etc/bind/ nano named.conf At the bottom put... Code: controls { inet 127.0.0.1 allow {127.0.0.1; 10.10.0.1; 10.10.0.2; } keys { "rndc-key"; } ; }; Wow, that is a lot of strangeness let us break it down. Controls <= This block tells the bind server, "Hey these nice people here will be allowed to update you, please let them!" inet 127.0.0.1 <= Who am I modifying? Myself. Here we say we are talking about the local bind server. allow {127.0.0.1; 10.10.0.1; 10.10.0.2; } <= here I am saying who (by IP) is allowed to modify the DNS enteries. I am saying I can locally modify (hence the 127.0.0.1) also through my network connection (10.10.0.1) modifications can take place. I will also allow the slave machine (10.10.0.2) to modify the server as well. Feel free to add additional servers/remove servers as your needs permit. keys {"rmdc-key";} ; <= This is the name of a key that is generated to authorize that the process/computer is allowed to modify the DNS. We will get more into this later. The name of the key (in " " ) is what is given by the default ubuntu install you may need to change this for other systems, or feel free to rename it as your own. Just remember to carry it on through the rest of this guide. Ok done with named.conf save it and get ready for the next bit. Code: nano named.conf.local Here comes some of the fun bits... This usually starts off as a blank file with some comments at the top. The purpose of this file is to define all the user only zones (read domain names/networks). Again I will dump what I did and then work through it. Add the following to the end of the file (which is pretty much the begining just past the comments. Code: include "/etc/bind/rndc.key"; zone "examplechangeme.com" { type master; file "/etc/bind/examplechangeme.com.zone"; allow-update { key "rndc-key"; }; allow-transfer {10.10.0/24; }; }; zone "0.10.10.in-addr.arpa" { type master; file "/etc/bind/rev.0.10.10.in-addr.arpa"; allow-update { key "rndc-key"; }; allow-transfer {10.10.0/24; }; }; Well thats a mouthful... include "/etc/bind/rndc.key"; <= This line includes the file rndc.key which was generated as a MD5 hash to be used to validate programs updating the DNS. Sort of like an include statement in programing. It dumps the contents of the file in the spot where the include is put. zone "examplechangeme.com" { <= Here we are defining a new zone whose name is examplechangeme.com. It can be anything you want to make a domain or sub domain for. It could be home.lan or linux orhome.linux.lan.moo.cow.milk you get the idea. =) type master; <= Since this is the master (Read main) DNS server we have to say so here. On the slave this will be diffrent. See if you can guess what it will be. HINT it starts with an s. file "/etc/bind/examplechangeme.com"; <= Here we say where the address resolution database will be located. This is the file that holds the NAME => IP information along with some information. We will talk about the contents of this file later. allow-update { key "rndc-key"; }; <= Here we are saying who/what can update this zone. Here we say anyone who comes to us with the rndc-key will be allowed to update the DNS. allow-transfer {10.10.0/24; }; <= Here we are saying who can have a copy of our zone. (In this case I am saying anyone on the 10.10.0.0-10.10.0.255 network. This can be changed to just a set of IPs or left as is. For example you could have allow-transfer {10.10.0.2; 10.10.0.200;}; zone "0.10.10.in-addr.arpa" { <= Odd looking zone... This is a reverse lookup database one of these typically accompany a named zone. This file allows for reverse lookups. Say you typed in 10.10.0.5 and want to know what the name associated with that was. Everything else in the definition is the same as above. On to creating the actual database files we made reference to in the two file directives above. From my research there are a few ways to make one of these files, the simplest method for me was to make a copy of one of the stock db files and modify it to my needs. So let's do that. Code: cp db.empty examplechangeme.com.zone cp db.empty rev.0.10.10.in-addr.arpa Let us edit.... Code: nano examplechangeme.com.zone Ok here I will display an example and explain as much of it as I know. Code: $TTL 86400 examplechangeme.com. IN SOA master.examplechangeme.com. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache TTL examplechangeme.com. IN NS master.examplechangeme.com. examplechangeme.com. IN NS slave.examplechangeme.com. master IN A 10.10.0.1 slave IN A 10.10.0.2 From the top! $TTL 86400 <= Not exactly sure but from context I think it is the time to live (in secconds) of the names on the server. examplechangeme.com. IN SOA master.examplechangeme.com. root.localhost. ( <- sets the domain. The master.examplechangeme.com. bit needs to be there so we know this is the main server the one following looks like some sort of place holder I decided to let it be as it is. The long bit with serial, refresh etc sets the times for the name leases. Serial according to some sites is important to increment every time the file is modified. However in my testing I never changed it and it apeared to work fine. Code: examplechangeme.com. IN NS master.examplechangeme.com. examplechangeme.com. IN NS slave.examplechangeme.com. Here we set what the name servers are (hence the NS) make sure to resolve the names bellow. Code: master IN A 10.10.0.1 slave IN A 10.10.0.2 Here we set some static names (good for servers) here I define master, and slave. You can put other things (and probably should) here like www, @, mail etc. One thing of note mail servers are dified diffrently the two ways I have seen this is... Code: examplechangeme.com. IN MX 10 mta.examplechangeme.com. and Code: @ IN MX 1 mail.examplechangme.com. Make sure to define mail, mta, and @ bellow in the static sections if you add in mail servers. Onto the reverse lookup database! Code: $TTL 86400 @ IN SOA master.examplechangeme.com. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache TTL IN NS master.examplechangeme.com. IN NS slave.examplechangeme.com. 1 IN PTR master.examplechangeme.com 2 IN PTR slave.examplechangeme.com A lot like above with a few differences. @ IN SOA master.examplechangeme.com. root.localhost. ( <= Note here we replaced examplechangeme.com. with @ Bellow that at the name servers we dropped the proceeding examplechangeme.com. In our static resolution section we replaced the names with the last numerical address, and instead of A we put PTR. Since we are doing a reverse lookup we put the name in for the reverse lookup. Save your changes and we will go to the next bit. In the folder we are in which should be /etc/bind/ we should make sure the files we will be modifying are owned by bind. Do a simple Code: chgrp bind * and that should help resolve reading/writing issues later on. Let's take a look at that key file. We are not going to edit it I am just putting an example so you understand its format. Code: more rndc.key key "rndc-key" { algorithm hmac-md5; secret "fjs8FjKDo320jpWdmvcdwf=="; }; NOTE: This is not my key I just made it up. However this is the file that we included in our named.conf.local and note the name of the key is rndc-key this is an arbitrary name. IE it can be whatever you want. I just left the default, but if you want to you can change it. Now we need to copy our key so that the dhcp server can use it. Code: cp /etc/bind/rndc.key /etc/dhcp3/. Head on over to the dhcp directory. Code: cd /etc/dhcp3 Make sure dhcp can read our key... Code: chown root:dhcpd rndc.key And now we edit the files... Code: nano dhcpd.conf This file comes with a lot of commented out examples we will ignore them and just modify the top, and add our own information. At the top you will see Code: ddns-update-type none; change it to Code: ddns-update-style interim; next in Code: # options definitions common to all supported networks... option domain-name "example.com"; option domain-name-servers ns1.example.con, ns2.example.com; change it to Code: option domain-name "examplechangeme.com"; option domain-name-servers 10.10.0.1, 10.10.0.2; leave the default lease time, and max lease time alone, unless you want to change them. after the lease times put: Code: one-lease-per-client on; Bellow that is: Code: # If this DHCP server is the official DHCP server for the local # network, the authoritative directive should be uncommented. # authoritative; Uncoment authoritative so it looks like... Code: # If this DHCP server is the official DHCP server for the local # network, the authoritative directive should be uncommented. authoritative; The log bit I left alone, however bellow it I put in our failover for dhcp directive. Code: failover peer "dhcp" { primary; address 10.10.0.1; port 519; peer address 10.10.0.2; peer port 520; max-response-delay 60; max-unacked-updates 10; mclt 600; split 128; load balance max seconds 3; } Ok the above works like this, failover peer "dhcp" { <- here we are declaring a failover peer and for the sake of simplicity we are naming it dhcp I could name it moo-cow or cookie-milk it is something so we can reference this failover peer. You can define multiple ones for different networks I think and as such have multiple decelerations of the above. I set this server as the primary with an address, a port, and then I declare the peer (my failover/backup dhcp server) with an address and a port. Note the ports have to be different. From the few examples I was able to find 519 and 520 are the ones most used for this. Max response delay, unacked, mclt, split, and load balance I am not sure on their exact purpose I think the max resonse is how long it will wait for the other server to respond before it takes over. Anyway the default settings here should work for most people. Bellow our failover we should include our key, and the zones that we will be updating. Code: include "/etc/dhcp3/rndc.key"; zone examplechangeme.com. { primary 10.10.0.1; key rndc-key; } zone 0.10.10.in-addr.arpa. { primary 10.10.0.1; key rndc-key; } What this does is define the zones the DHCP is to update whenever a lease is given. Say bob.examplechangeme.com logs in gets an IP the DHCP server notifies the DNS server of the lease and modifies it so that whenever someone types in bob.examplechangeme.com they always get bob's machine no matter what address bob may have. Primary sets the server we will update and the key is to let the server know we are legitimate. Now to make our subnet. bellow the zone section put. Code: subnet 10.10.0.0 netmask 255.255.255.0 { pool { failover peer "dhcp"; range 10.10.0.50 10.10.0.254; deny dynamic bootp clients; allow unknown-clients; } option routers 10.10.0.1; option broadcast-address 10.10.0.255; option subnet-mask 255.255.255.0; } subnet 10.10.0.0 netmask 255.255.255.0 { <- here we define our network I am using subnet 10.10.0.0 with a mask (what bits of the Ips are mine) of 255.255.255.0 which means I have 253 Ips to play with. Code: pool { failover peer "dhcp"; range 10.10.0.50 10.10.0.254; deny dynamic bootp clients; allow unknown-clients; } This section is specific to failover DHCP if you just want normal DHCP drop it all and just keep the range part. We set the failover peer definition (defined above) then the range of Ips it is allowd to toss out. The deny dynamic bootp clients; line is in reguards to a protocol for thin clients. If you have thin clients failover, from what I can tell, is not supported in the current dhcp server. The final line allow unknown-clients; lets you get an IP from the server. For some reason without it I was unable to grab an IP. You don't need it in a non failover setup. Code: option routers 10.10.0.1; option broadcast-address 10.10.0.255; option subnet-mask 255.255.255.0; This is info that you pass to the clients that connect. Your router may be a different IP and setting up a router is beyond this long howto. We are done editing the master server! Our final finishing thing is to get a copy of the rndc.key file to the slave computer. You can do this via sftp, or copy/paste the contents of the file over. However you want to do it. SLAVE MACHINE Make sure you copied the key from master over to the slave. Put a copy in both /etc/bind/ and /etc/dhcp3 in bind make sure the group is bind and for dhcp make sure the group is dhcpd. in /etc/bind Code: chgrp bind rndc.key in /etc/dhcp3 Code: chgrp dhcpd We will start with the DNS server first, and edit named.conf. Code: cd /etc/bind nano named.conf Like on master we will do the same here at the end of the file put. Code: controls { inet 127.0.0.1 allow {localhost; 10.10.0.1; 10.10.0.2;} keys { "rndc-key"; }; }; Save exit and then to named.conf.local Code: nano named.conf.local Again we have an empty file, things will be a little different. At the end of our comment file put: Code: zone "examplechangeme.com" { type slave; file "/etc/bind/examplechangeme.com.zone"; masters {10.10.0.1; }; }; zone "0.10.10.in-addr.arpa" { type slave; file "/etc/bind/rev.0.10.10.in-addr.arpa"; masters {10.10.0.1;} ; }; A lot like before, the type of server is a slave (answer to pop quiz way at the beginning). File says where we are saving the files, and masters lets the slave know where to get the DNS information from. Save and close. We don't have to make our own databases for the slave since it will grab that information from the master. So that saves a lot of effort. Off to DHCP land, and dhcpd.conf! Code: cd /etc/dhcpd nano dhcpd.conf A lot of this will be the same as in master with a few differences. Since we will assume that if master is down we cannot modify the DNS on master I told it to modify the DNS on the slave. So whenever master is down slave's DHCP server takes over gives out IPs and modifies slave's DNS. Code: ddns-update-type interim; option domain-name "examplechangeme.com"; option domain-name-servers 10.10.0.1, 10.10.0.2; default-lease-time 600; max-lease-time 7200; one-lease-per-client on; authoritative; failover peer "dhcp" { secondary; address 10.10.0.2; port 520; peer address 10.10.0.1; peer port 519; max-response-delay 60; max-unacked-updates 10; } Here we just change a few things around. We are the secondary server and we set things that were the peer on the master. Make sure to keep the ports and IPs straight. Code: include "/etc/dhcp3/rndc.key"; zone examplechangeme.com. { primary 10.10.0.2; key rndc-key; } zone 0.10.10.in-addr.arpa { primary 10.10.0.2; key rndc-key; } Note the change in the IP for the zone definitions. This is so the slave updates the DNS for itself whenever the master is down. Code: subnet 10.10.0.0 netmask 255.255.255.0 { pool { failover peer "dhcp"; range 10.10.0.50 10.10.0.200; deny dynamic bootp clients; allow unknown-clients; } option routers 10.10.0.1; option subnet-mask 255.255.255.0; option broadcast-address 10.10.0.255; } Save and exit. Wow I think we are done. On both servers issue the following commands to restart the dhcp and bind servers. Code: /etc/init.d/bind9 restart; /etc/init.d/dhcp3-server restart; In theory things should be working. Here are some troubleshooting/testing tips. This assumes your client machine is also a linux box. NOTE: For the dynamic name update for DHCP to DNS you may need to edit /etc/dhclient.conf uncomment send host-name " STUFF HERE "; and replace STUFF HERE with the name of the machine, like bob, or joe, or mail etc. Also make sure both master and slave's clocks are in sync DHCP and DNS failover/updating is VERY dependent on time. Set a cron job to update time. dig example Code: dig examplechangeme.com You should get back something like this. Code: ; <<>> DiG 9.3.2 <<>> examplechangeme.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51050 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.examplechangeme.com. IN A ;; ANSWER SECTION: www.examplechangeme.com. 120 IN CNAME examplechangeme.com. examplechangeme.com. 120 IN A 10.10.0.1 ;; AUTHORITY SECTION: examplechangeme.com. 120 IN NS master.examplechangeme.com. examplechangeme.com. 120 IN NS slave.examplechangeme.com. ;; Query time: 187 msec ;; SERVER: 10.10.0.1#53(10.10.0.1) ;; WHEN: Fri Sep 29 11:15:05 2006 ;; MSG SIZE rcvd: 108 You are looking for the answer section to see if your IP was set. What this program does is check to see what the DNS has for whatever you sends its way. dhclient is useful to see if the dhcp server is tossing out IPs like it should. The most useful flags were -r which releases the lease dhclient has. example Code: dhclient -r dhclient dhclient eth0 If you have multiple cards using dhcp include the ethX in there so that you don't reset all of them. Check /var/log/daemon.log and /var/log/syslog on the master and slave. I found this very helpful in tracking down problems. You will want to edit /etc/dhcp3/dhclient.conf uncomment supersede domain-name and prepend domain-name-servers. replace the domain name with your domain name and add to the domain-name-servers the IPs of your domain names. By doing so resolv.conf will always keep that infotmation if you are on a dynamic IP connection. I hope this helps some people when I went on-line and looked for how to do dynamic dns, failover dns, dhcp failover, and the like I found poor/little documentation. If you have questions I will do what I can to help! Last edited by Endwin; October 21st, 2006 at 04:51 PM..

October 13th, 2006	#2
hellmet Dipped in Ubuntu Join Date: Apr 2006 Location: Hyderabad ,India Beans: 575 Ubuntu 9.10 Karmic Koala	Re: howto: Dynamic DNS and DHCP dual servers with failover wow that is a whole lotta .. was thinking of doing this.. you've made it possible. will possibly set it up tomorrow.. __________________ India is a pluralist society that creates magic with democracy, rule of law and individual freedom, community relations and diversity. I wouldn't mind being born ten times to rediscover India. - Robert Blackwill, U.S Ambassador until 2003.

October 14th, 2006	#3
hellmet Dipped in Ubuntu Join Date: Apr 2006 Location: Hyderabad ,India Beans: 575 Ubuntu 9.10 Karmic Koala	Re: howto: Dynamic DNS and DHCP dual servers with failover uh... dude.. is it possible for you to cut short some of it.. and pm me ..? coz I have just one system, and one ISP connection.. so I just need to setup Dynamic DNS server on it.. __________________ India is a pluralist society that creates magic with democracy, rule of law and individual freedom, community relations and diversity. I wouldn't mind being born ten times to rediscover India. - Robert Blackwill, U.S Ambassador until 2003.

October 16th, 2006	#4
Endwin A Carafe of Ubuntu Join Date: Nov 2005 Beans: 119 Ubuntu 8.10 Intrepid Ibex	Re: howto: Dynamic DNS and DHCP dual servers with failover It is actually quite easy to set it up for just one server (I did it at home) All you need to do is follow the master part and just remove the stuff refering to the other server (Remove the failover sectoon of DHCP) and drop the pool section to just range 10.10.0.50 10.10.0.254

October 16th, 2006	#5
btdown Gee! These Aren't Roasted! Join Date: Apr 2005 Location: Orlando, FL Beans: 214 Ubuntu Karmic Koala (testing)	Re: howto: Dynamic DNS and DHCP dual servers with failover Thank you for this...I'll have to try it out. BT

November 29th, 2006	#6
simidau First Cup of Ubuntu Join Date: Nov 2006 Beans: 5	Re: howto: Dynamic DNS and DHCP dual servers with failover While it looks like it's working - have not checked that removing the master will allow everything to continue. I looked in syslog and and found the following lines on startup of dhcpd and another unsure line every time a client gets an address. Master server is normal Startup message -------------------------------------------------------------- Nov 29 14:37:47 server2 dhcpd: Internet Systems Consortium DHCP Server V3.0.4 Nov 29 14:37:47 server2 dhcpd: Copyright 2004-2006 Internet Systems Consortium. Nov 29 14:37:47 server2 dhcpd: All rights reserved. Nov 29 14:37:47 server2 dhcpd: For info, please visit http://www.isc.org/sw/dhcp/ Nov 29 14:37:47 server2 dhcpd: Wrote 0 leases to leases file. Nov 29 14:37:48 server2 dhcpd: failover peer dhcp: I move from recover to startup Nov 29 14:38:02 server2 dhcpd: failover peer dhcp: I move from startup to recover --------------------------------------------------------------- The last two lines ebing the ones I am unsure of? Then when a client gets an address I get the following. --------------------------------------------------------------- Nov 29 14:40:47 server2 dhcpd: failover peer dhcp: unexpected error --------------------------------------------------------------- There is another error popping up --------------------------------------------------------------- Nov 29 14:39:17 server2 dhcpd: failover peer dhcp: address not available --------------------------------------------------------------- Any ideas?

December 2nd, 2006	#8
zigford 5 Cups of Ubuntu Join Date: Jul 2005 Location: Sunny Coast Australia Beans: 30 Hardy Heron (Ubuntu Development)	Re: howto: Dynamic DNS and DHCP dual servers with failover Wish I had seen this earlier. I had tried to configure this in the past, but failed. Now seeing you point to /var/log/daemon I had no idea thats where bind info goes and I was able to fix my setup in seconds. Amen!

January 8th, 2007	#9
makadam 5 Cups of Ubuntu Join Date: Jul 2006 Location: Luxembourg Beans: 15 Ubuntu 6.06	Re: howto: Dynamic DNS and DHCP dual servers with failover Hi. Thanks for this wonderful tutorial. Best regards Makadam

March 15th, 2007	#10
Abhi Kalyan Way Too Much Ubuntu Join Date: Oct 2006 Location: India, Chennai, Mylapore Beans: 265 Ubuntu 8.04 Hardy Heron	Re: howto: Dynamic DNS and DHCP dual servers with failover That is a very detailed work that you have crafted, Thank you a Tonne. Hope the following request does not annoy you. "When you mean "master" is it the hostname of the primary DNS server or is it a code that points the services to accept this system as master?" Like the Primary DNS server is "master.examplechangeme.com" Hostname: master Hostname -f: examplechangeme.com Sorry if this is really a very small doubt. hope you could throw some light on this subject. I tried the WHole Manual asubstituteing things and am still not able to get it right. Thank you __________________ Love Abhinya (\_./) (O.-) (> <)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode