Mirroring DNS masters
Dan Brown
I was just wondering if anyone mirrors their master domain name servers
as either an exact mirror or a copied mirror for redundancy or load
balancing.
We have a couple of Cobalt RaQs which themselves are not hard to setup but
rather than setting up master and slave nameservers, we would like to setup
two master servers. 99% of DNS updates would occur on the one server and
for the most part updating the zone files on the other server is going to
be handled through a cron job and some scripting using SSH.
By doing this we hope to acheive the complete redundancy of another master
server (which would be listed as our secondary, but serves as a mirror on
another network) rather than a secondary server whose records start to
expire after 12 hours.
I've done some searching on both the bind archives as well as Google but
have only so far been getting hits referencing LDAP. If anyone could point
me towards some documentation on either how to do configure mirrored DNS
masters or what difficulties there are in attempting such a configuration, I
greatly appreciate it.
Dan Brown
d...@amanah.com
Barry Margolin
>By doing this we hope to acheive the complete redundancy of another master
>server (which would be listed as our secondary, but serves as a mirror on
>another network) rather than a secondary server whose records start to
>expire after 12 hours.
Why would their records expire after 12 hours? You should set the SOA
Expire time to something like 7 or 10 days.
--
Barry Margolin, barry.m...@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Steven Job
Dan,
You can always rsynch the the /var/named directory from one machine to the slave machine. Set it up as a cronjob and you are all set.
But setting it up as a true secondary would probably be the most efficient and you wouldn't have to wait for the cronjob to run. You can increate the expire time of the secondarys so they do not expire in 12 hours. You can have it keep giving queries over a year if you want.
$ORIGIN .
$TTL 86400 ; 1 day
yourdomain.com IN SOA ns1.yourdomain.com. dns.yourdomain.com. (
2002100206 ; serial
43200 ; refresh (12 hours)
3600 ; retry (1 hour)
1209600 ; expire (2 weeks) YOU CAN SET THIS TO A YEAR IF YOU WANT
180 ; minimum (3 minutes)
Don't look at some of my other values. I don't think they are recommended values by any means, I just wanted to show you where you can look.
But whatever you feel most comfortable with is all that matters.
-Steve
On Tue, 26 Aug 2003, Dan Brown wrote:
> Hi,
>
> I was just wondering if anyone mirrors their master domain name servers
> as either an exact mirror or a copied mirror for redundancy or load
> balancing.
> We have a couple of Cobalt RaQs which themselves are not hard to setup but
> rather than setting up master and slave nameservers, we would like to setup
> two master servers. 99% of DNS updates would occur on the one server and
> for the most part updating the zone files on the other server is going to
> be handled through a cron job and some scripting using SSH.
>
> By doing this we hope to acheive the complete redundancy of another master
> server (which would be listed as our secondary, but serves as a mirror on
> another network) rather than a secondary server whose records start to
> expire after 12 hours.
>
p...@icke-reklam.ipsec.nu
> Dan Brown
> d...@amanah.com
If you study the pronciples of dns & bind you will see that it is
redundant technology.
All that is needed is that whenever a master breaks down you can replace it
within the lifetime of data ( which sets a limit to how short "expire" should be )
What you suggest is not needed and not wanted.
--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
Simon Waters
Hash: SHA1
p...@icke-reklam.ipsec.nu wrote:
>
> What you suggest is not needed and not wanted.
It avoids the need for two different configurations.
Configuration A the master, configuration B the slave, doubles your work
load.
Where as you write a few scripts to ensure the master is updated
correctly, and then rsync it, you can readily ensure the same tested
configuration is deployed to multiple servers.
However I'm worried anyone would ask how to do it.
You either know how to set up a master server or you don't, if you know
how to do it, doing it N times is hardly challenging. May be the OP
never used rsync before.
I'm worried about the 99% of updates would occur on the one server. I
figure this means 1% of updates will probably get lost, since you really
don't want to get into multimaster replication, even at the zone file
level. I'd do 100% of updates on a test server, and deploy when it all
works.
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/S/LtGFXfHI9FVgYRAju3AJ4kgXI/I1FsNL4QgyIRfO4KGaLZJgCfSngZ
P+hDEwzBwjO+lukayzpZfVk=
=jp8i
-----END PGP SIGNATURE-----
Barry Finkel
>If you study the pronciples of dns & bind you will see that it is
> redundant technology.
>
>All that is needed is that whenever a master breaks down you can replace it
>within the lifetime of data ( which sets a limit to how short "expire" should be )
>
>What you suggest is not needed and not wanted.
Unless the master has DDNS zones, in which case the sysadmin would need
to get the master up and running in a shorter period of time.
----------------------------------------------------------------------
Barry S. Finkel
Computing and Instrumentation Solutions Division
Argonne National Laboratory Phone: +1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 222, Room D209 Internet: BSFi...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
Dan Brown
> correctly, and then rsync it, you can readily ensure the same tested
> configuration is deployed to multiple servers.
Essentially the script keeps track of the last time a file was updated. Any
modification times newer than this will be synchronized on the remote
server.
> However I'm worried anyone would ask how to do it.
>
> You either know how to set up a master server or you don't, if you know
> how to do it, doing it N times is hardly challenging. May be the OP
> never used rsync before.
I know how to setup the master server without any problems. The
synchronization of data between two masters serving the same data is where I
am wondering if there will be any problem. Will bind ever have to be
restarted as a result of changing zone files? In the files themselves they
say:
; Do Not edit BIND db files directly.
I have a suspicion this may only refer to our Cobalt UI having problems with
files being updated while actually being edited in the UI as well. I've yet
to work with bind on a server other than the RaQ appliances.
The updates will occur at most once every five minutes (though probably more
like once a minute, or once every two, I haven't decided yet), and for the
moment will only occur from our primary master server which we currently do
DNS updates with all the time to our current secondary.
> I'm worried about the 99% of updates would occur on the one server. I
> figure this means 1% of updates will probably get lost, since you really
> don't want to get into multimaster replication, even at the zone file
> level. I'd do 100% of updates on a test server, and deploy when it all
> works.
The 99% to 1% ratio I referred to is due to the fact that it doesn't matter
how many times you tell people to use a certain procedure or server, someone
will always not follow your rules.
AK
> Peter H=E5kanson replied to a post:
>=20
>=20
>>If you study the pronciples of dns & bind you will see that it is=20
>>redundant technology.
>>
>>All that is needed is that whenever a master breaks down you can replac=
e it
>>within the lifetime of data ( which sets a limit to how short "expire" =
should be )
>>
>>What you suggest is not needed and not wanted.=20
>=20
>=20
> Unless the master has DDNS zones, in which case the sysadmin would need=
> to get the master up and running in a shorter period of time.
> ----------------------------------------------------------------------
> Barry S. Finkel
> Computing and Instrumentation Solutions Division
> Argonne National Laboratory Phone: +1 (630) 252-7277
> 9700 South Cass Avenue Facsimile:+1 (630) 252-4601
> Building 222, Room D209 Internet: BSFi...@anl.gov
> Argonne, IL 60439-4828 IBMMAIL: I1004994
>=20
>=20
As long as the party has the master's named.conf file, one would have to =
promote a slave server to be the new master. The ease or difficulties=20
of this transition will depend on the mechanisms employed when the=20
master was operational.
As to the DDNS zones, the soa record needs to reflect the new master and =
all is good. The time available for the transition is still controlled=20
by the expire clause of the SOA record.
AK