Dynamic zones on the DNS name server

Edit online

The named command allows for dynamic updates. The named database and configuration files need to be configured to allow for client machines to issue updates. A zone can be set to dynamic or static. The default zone is static.

To make a zone dynamic, you must add the keyword allow-update to that zone's stanza in the /etc/named.conf file. The allow-update keyword specifies an Internet address match list that defines hosts allowed to submit updates. See the named.conf File Format for TCP/IP in the Files Reference for more information and a detailed example of a conf file. In the following example, all hosts are allowed to update the dynamic zone:

zone "abc.aus.century.com" IN {
    type master;
    file "named.abc.data";
    allow-update { any; };
};

After a zone is marked dynamic, three modes of security can be initiated:

Item	Description
Unsecured	Allows anyone at anytime to update any information in the zone. Attention: Use of this mode is not recommended. It can lead to data loss, data interception, and user frustration. At the least, an unsecured zone should be limited to updates only from specific Internet addresses.
Controlled	Allows for the creation of new information and the replacement of existing information. This is probably the easiest mode to use for a secure transition environment. This mode also requires that all incoming updates be timestamped and have keyed signatures.
Presecured	Requires all updates to existing information be replaced with similar information. Does not allow for the creation of new information. This mode also requires that all incoming updates be timestamped and have keyed signatures.

A dynamic zone defaults to unsecured mode. To use one of the other modes, type controlled or presecured after the keyword update-security in the zone stanza of the /etc/named.conf file. This tells the named server the level of security to use with that zone. For example:

zone "abc.aus.century.com" IN {
    type master;
    file "named.abc.data";
    allow-update { any; };
    update-security controlled;
};

After a mode is selected, the actual data files must be modified for your level of security. In unsecured mode, the data files are used "as is." For controlled or presecured mode, you must generate a set of master server/host name key pairs for each name in the zone. This is done with the nsupdate command using the -g option. This command generates the key pair (a private and a public key). These keys are needed to authentically sign for updates. After generating all the keys for your list of zone names, you need to add them to the data file. The KEY format is as follows:

Index    ttl    Class     Type     KeyFlags     Protocol     Algorithm     KeyData

where:

Item	Description
Index	Specifies the name used to reference the data in the zone.
ttl	Specifies the time-to-live (TTL) for this data. This is an optional field.
Class	Specifies the class of the data. This is dependent on the zone, but usually it is IN.
Type	Indicates the type of the record. In this case, it is KEY.
KeyFlags	Gives named information about the key. 0x0000 defines the typical key record used for a host. 0x0100 defines the key record associated with the zone name.
Protocol	Specifies the protocol to use. Currently, there is only one, `0`.
Algorithm	Specifies the algorithm of the key. Currently, there is only one, `1`. This is the MD5 Private/Public authentication method.
KeyData	Indicates the key in base64 representation. The nsupdate command generates both the public and private keys in base64 representation. The public key is listed last in the output file.

For example, to ensure security over a host name in a dynamic zone, a line similar to the following needs to be added to the zone file for the zone containing the host name.

bears    4660    IN    KEY    0x0000    0    1    AQOtg......

The preceding example indicates that bears has a KEY record defined. Someone wanting to update bears would have to sign his update with the private key matching the public key in the database. For the nsupdate command to succeed, the private key needs to be placed on the client in a keyfile (defaults to /etc/keyfile). It should follow the format:

 hostname          mastername           base64          key

A similar KEY entry is required in the zone definition section. A zone key is required for both presecured and controlled modes or the mode is considered to be unsecured. This can be done as shown in the previous bears example, but the private key is left for the administrator to use with the nsupdate command's administrative mode.

To generate a key pair using the nsupdate command, type the following:
```
nsupdate -g -h ZoneName -p ServerName -k AdminKeyFile
```
This generates a key for the zone. In this example, nsupdate is linked to nsupdate4, which can be done by typing the following:
```
ln -fs /usr/sbin/nsupdate4 /usr/sbin/nsupdate
```

Place the last key of the pair in the beginning section for the zone as follows:

IN     KEY     0x0100  0  1  Key

The entry for the named.abc.data file is as follows:

$TTL 3h    ;3 hour

@ IN    SOA     venus.abc.aus.century.com. gail.zeus.abc.aus.century.com. (
                1       ;serial
                3600    ;refresh
                600     ;retry
                3600000 ;expire
                86400   ;negative caching TTL
)
        IN      NS      venus.abc.aus.century.com.
        IN      KEY     0x0100  0 1 AQPlwHmIQeZzRk6Q/nQYhs3xwnhfTgF/
                        8YlBVzKSoKxVKPNLINnYW0mB7attTcfhHaZZcZr4u/
                        vDNikKnhnZwgn/
venus   IN      A       192.9.201.1
earth   IN      A       192.9.201.5
mars    IN      A       192.9.201.3

The zone is now ready to be loaded by refreshing the name server. Place the AdminKeyFile on the client or DHCP server that is updating the zone. The zone key contained in the AdminKeyFile can be used to apply updates and maintenance operations to the name server.