Dynamic zones on the DNS name server
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.