10.3 DNS Dynamic Update

BIND 8 also supports the dynamic update facility described in RFC 2136. This permits authorized updaters to add and delete resource records from a zone for which the server is authoritative. An updater can find the authoritative name servers for a zone by retrieving the zone's NS records. If the server receiving an authorized update message is not the primary master for the zone, it will forward the update "upstream" to its master server(s). If they, in turn, are slaves for the zone, they will also forward the update upstream.

Dynamic update permits more than the simple addition and deletion of records. Updaters can add or delete individual resource records, delete RR sets (a set of resource records with the same domain name, class and type, such as all Internet addresses for www.acmebw.com ), or even delete all records associated with a given name. An update can also stipulate that certain prerequisite records exist or not exist in the zone before the update takes effect. For example, an update can add the address record:

dakota.west.acmebw.com.          in      a       192.168.1.4

only if the name dakota.west.acmebw.com isn't currently being used, or only if dakota.west.acmebw.com currently has no address records.

For the most part, dynamic update functionality is used by programs like DHCP servers that assign IP addresses automatically to computers, and then need to register the resulting name-to-address and address-to-name mappings. These programs use the ns_update() routine to create update messages and send them to an authoritative server for the zone that contains the domain name.

However, it is possible to create updates manually with the command-line program nsupdate , which is part of the standard BIND distribution. nsupdate reads one-line commands that it then translates into an update message. Commands can be specified on standard input (the default) or in a file, whose name must be given as an argument to nsupdate . Commands not separated by a blank line are incorporated into the same update message.

The commands nsupdate understands are:

prereq yxrrset domain name type [ rdata ]

Makes the existence of an RR set of type type owned by domain name a prerequisite to performing the update

prereq nxrrset

Makes the non-existence of an RR set of type type owned by domain name a prerequisite to performing the update specified in successive update commands

prereq yxdomain domain name

Makes the existence of the domain name specified a prerequisite to performing the update

prereq nxdomain

Makes the non-existence of the domain name specified a prerequisite to performing the update

update delete domain name [ type ] [ rdata ]

Deletes the domain name specified or, if type is also specified, deletes the RR set specified or, if rdata is also specified, deletes the record matching domain name , type , and rdata

update add domain name ttl [ class ] type rdata

Adds the record specified to the zone. Note that the TTL , in addition to the type and resource-record-specific data, must be included, but the class is optional, and defaults to IN

So, for example, the command:

% 

nsupdate

 > 

prereq nxdomain dakota.west.acmebw.com.

 > 

update add dakota.west.acmebw.com. 333 in a 192.168.0.4

 >

tells the server to add an address for dakota.west.acmebw.com only if the domain name does not already exist. Note that the last blank line is nsupdate 's cue to send the update.

The command:

% 

nsupdate

 > 

prereq yxrrset dakota.west.acmebw.com. in mx

 > 

update delete dakota.west.acmebw.com. in mx

 > 

update add dakota.west.acmebw.com. in mx 10 dakota.west.acmebw.com.

 > 

update add dakota.west.acmebw.com. in mx 50 store-forward.mindspring.com.

 >

checks to see whether dakota.west.acmebw.com already has MX records, and if it does, deletes them and adds two in their place.

Given the fearsome control that dynamic updates obviously give an updater over a zone, you clearly need to restrict them, if you use them at all. By default, BIND 8 servers don't allow dynamic updates to authoritative zones. In order to use them, you add an allow-update substatement to the zone statement for the zone that you'd like to allow updates to.

allow-update takes an address match list as an argument. The address or addresses matched by the list are the only addresses that are allowed to send your server updates to that zone. It's prudent to make this access list as restrictive as possible:

zone "acmebw.com" {                 type master;                 file "db.acmebw";                 allow-update { 192.168.0.1; }; };