DNS/DHCP redundnacy

[stan]

I'm  revamping my network infrastructure a bit to increae redundancy.

Presently DNS is served by a single FreeBSD, and I've got a dhcp server
running on an OpenBSD machine that also serves as my firewall.

Where I'm headed is to build a 2nd FreeBSD, and use it and the existing
FreebSD as redundant DNS/DHCP servers.

This leads to several questions.

1. Should both named.conf files declare themselves to be master, or should
one be slave?

I've installed the isc dhcp server from ports, and it works for simple
usage.

2. Can anyone show me an example of "failover" configuration for these?
Here is what I have come up with, but I'm not convinced it's corect:


# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#

# option definitions common to all supported networks...
option domain-name "fas.com";
option domain-name-servers 205.159.77.224;

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

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

# ad-hoc DNS update scheme - set to "none" to disable dynamic DNS updates.
ddns-update-style interim;
ignore client-updates;
option domain-name "fas.com";
ddns-domainname "fas.com";

zone fas.com. {
    primary 127.0.0.1;
}

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
# log-facility local7;

# No service will be given on this subnet, but declaring it helps the 
# DHCP server to understand the network topology.

subnet 10.152.187.0 netmask 255.255.255.0 {
}

subnet 205.159.77.0 netmask 255.255.255.0 {
	option routers 205.159.77.234;
		range 205.159.77.50 205.159.77.75;
}

failover peer "pool" {
         primary;
         address black.fas.com;
         port 519;
         peer address polar.fas.com;
         peer port 520;
         max-response-delay 60;
         max-unacked-updates 10;
         mclt 3600;
         split 128;
         load balance max seconds 3;
       }

Mostly, I'm not certain if I need to reference the pool object somewhere
else in teh config file.

Als how can I make the dhcp server update the dns records dynamicly? I've
tried to do this, but it's not working. here's the named.conf file for
reference:


// $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.5 2002/02/04 18:24:21 ume Exp $
//
// Refer to the named.conf(5) and named(8) man pages for details.  If
// you are ever going to setup a primary server, make sure you've
// understood the hairy details of how DNS is working.  Even with
// simple mistakes, you can break connectivity for affected parties,
// or cause huge amount of useless Internet traffic.

options {
	directory "/etc/namedb";

// In addition to the "forwarders" clause, you can force your name
// server to never initiate queries of its own, but always ask its
// forwarders only, by enabling the following line:
//
//      forward only;

// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below.  This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.
//	forwarders {
//		 63.246.111.11 ;
//		 63.246.111.12 ;
//		 63.246.111.22 ;
//	};
	/*
	 * If there is a firewall between you and nameservers you want
	 * to talk to, you might need to uncomment the query-source
	 * directive below.  Previous versions of BIND always asked
	 * questions using port 53, but BIND 8.1 uses an unprivileged
	 * port by default.
	 */
	 query-source address * port 53;

	/*
	 * If running in a sandbox, you may have to specify a different
	 * location for the dumpfile.
	 */
	// dump-file "s/named_dump.db";
};

// Note: the following will be supported in a future release.
/*
host { any; } {
	topology {
		127.0.0.0/8;
	};
};
*/
acl updaters {
           127.0.0.1;
   };


// Setting up secondaries is way easier and the rough picture for this
// is explained below.
//
// If you enable a local name server, don't forget to enter 127.0.0.1
// into your /etc/resolv.conf so this server will be queried first.
// Also, make sure to enable it in /etc/rc.conf.

zone "." {
	type hint;
	file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
	type master;
	file "localhost.rev";
};

zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
	type master;
	file "localhost-v6.rev";
};

// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
// Example secondary config entries.  It can be convenient to become
// a secondary at least for the zone where your own domain is in.  Ask
// your network administrator for the IP address of the responsible
// primary.
//
// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone!
// (This is the first bytes of the respective IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended.)
//
// Before starting to setup a primary zone, better make sure you fully
// understand how DNS and BIND works, however.  There are sometimes
// unobvious pitfalls.  Setting up a secondary is comparably simpler.
//
// NB: Don't blindly enable the examples below. :-)  Use actual names
// and addresses instead.
//
// NOTE!!! FreeBSD can run bind in a sandbox (see named_flags in rc.conf).
// The directory containing the secondary zones must be write accessible 
// to bind.  The following sequence is suggested:
//
//	mkdir /etc/namedb/s
//	chown bind:bind /etc/namedb/s
//	chmod 750 /etc/namedb/s

zone "fas.com" {
	type master;
	file "s/fas.com";
	allow-update { updaters; };
};

zone "77.159.205.in-addr.arpa" {
	type master;
	file "s/77.159.205.in-addr.arpa";
	allow-update { updaters; };
};

Thanks for any help on this!

-- 
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
						-- Benjamin Franklin