5.26 Running Multiple Primary Master Name Servers for the Same Zone

5.26.1 Problem

You want to run more than one primary master name server for the same zone.

5.26.2 Solution

Configure multiple name servers with zone statements of type master for the zone, then use a program such as scp , rdist , or rsync to keep the zone data files synchronized.

5.26.3 Discussion

An rdist distfile to synchronize zone data files between two name servers might look like this:

DUPS = ( ns2.foo.example ns3.foo.example )

FILES = ( /var/named/db.foo.example )

${FILES} -> ${DUPS}

    install;
    special "rndc reload foo.example";

A scheme like this won't work with a dynamically updated zone, because the zone data file won't usually be rewritten right away after the name server receives an update. Moreover, if more than one primary master actually accepts dynamic updates, rsync -style synchronization might corrupt the zone data file.

5.26.4 See Also

rdist(1) and scp(1) .

5.27 Creating a Zone Programmatically

5.27.1 Problem

You want to create a new zone on a name server programmatically.

5.27.2 Solution

Create a minimal zone data file that uses only relative domain names in the owner field of the records. For example:

$TTL 86400
@    IN    SOA    ns1.foo.example.    hostmaster.foo.example.    (
     2002051200
     3600
     900
     604800
     3600 )

    IN    NS    ns1.foo.example.
    IN    NS    ns2.foo.example.

    IN    A     10.0.0.1

    IN    MX    10 mail.foo.example.

www IN    CNAME    @

Then write a script to add a new zone statement to the name server's named.conf file, referring to the zone data file. Finally, use rndc reconfig or ndc reconfig , as appropriate, to tell the name server to reread named.conf .

An example script, addzone.pl , is included in the tar file that accompanies this book (see the Preface for details). To run addzone.pl , specify the domain name of the zone and the name of the minimal zone data file as arguments:

# addzone.pl baz.example db.template

5.27.3 Discussion

addzone.pl is fairly simple-minded: it assumes its working directory is the name server's working directory. And I'm sure some Perl hacker could replace it with a single-line script.

5.27.4 See Also

Section 1.16 for configuring a name server as the primary master for a zone, and Section 5.7 for adding a zone without restarting the name server.

5.28 Migrating from One Domain Name to Another

5.28.1 Problem

You need to migrate from one domain name to another because you're changing the name of your zone.

5.28.2 Solution

Once you've established the new zone, create aliases pointing from each domain name in the old zone to the corresponding domain name in the new zone. For example:

a.foo.example.    IN    CNAME    a.bar.example.
b.foo.example.    IN    CNAME    b.bar.example.
c.d.foo.example.  IN    CNAME    c.d.bar.example.

Change the NS and MX records in the old zone, as necessary, so they don't point to aliases:

foo.example.    IN    NS    ns1.bar.example.
                IN    NS    ns2.bar.example.
                IN    MX    10 mail.bar.example.

Change the PTR records for these hosts to reverse-map to their new domain names , too:

20.0.168.192.in-addr.arpa.    IN    PTR    a.bar.example.
21.0.168.192.in-addr.arpa.    IN    PTR    b.bar.example.
22.0.168.192.in-addr.arpa.    IN    PTR    c.d.bar.example.

Next, configure any resolvers that use the old domain name as their local domain name to use the new one; for example:

domain bar.example

This may require additional changes to the configuration of the host. If the host runs a mailer or a web server, check the server's configuration files. You may need to change the domain name the mailer uses in return addresses or the domain name it sees as local. You may need to reconfigure the web server with its new domain name or install a new SSL server certificate. Also, check that any authorization files refer to the new domain names, since IP addresses will now reverse-map to them.

Wait for some grace period, and then remove the aliases and the old zone. If you're not sure how long to keep the old zone around, you can use the zone statistics described in Recipe Section 5.15 to determine whether the aliases are still being used.

5.28.3 Discussion

If you run BIND 9 name servers for the zone, you may be able to use the new DNAME record to simplify the setup of the old zone. DNAME records work like substitution rules in sed or Perl. For example, this DNAME record will "synthesize" CNAME records aliasing each domain name in foo.example to the corresponding domain name in bar.example :

foo.example.    IN    DNAME    bar.example.

A querier looking up a.foo.example will find this CNAME record, created on the fly from the DNAME record:

a.foo.example.    IN    CNAME    a.bar.example.

While a querier looking up c.d.foo.example will have this CNAME record returned:

c.d.foo.example.    IN    CNAME    c.d.bar.example.

5.28.4 See Also

Section 2.4 for creating individual aliases using CNAME records, Section 5.15 for measuring zone statistics, and Section 9.3 and Section 9.4 for configuration of a resolver's local domain name.