Painless DDNS part 2 - the server

Author : Jeff Garzik - September 3rd, 2004 - link to original article

Introduced in BIND version 8 and refined in BIND version 9, the nsupdate utility provides the system administrator or casual user with a quick and painless method of updating a DNS zone, adding or deleting any type of DNS record the name server supports.

Looking again at dynamic DNS (DDNS), we now turn to setting up dynamic DNS on your BIND named name server, discussing some of the available security policies, and providing some examples of use. For directions on actually performing dynamic DNS updates from a remote client, read the companion article on nsupdate.

Configuring dynamic DNS on your name server is fairly straightforward. You build a collection of keys, and then associate each key with one or more DNS zone, thereby establishing your site security policy.

Configuration file: keys.conf

It is a good idea to separate the DDNS security keys from the other portions of /etc/named.conf. This potentially allows for tighter permissions on the key file, or allowing different groups of administrators read/update access to named.conf or the key file.

Therefore, we create a new file /var/named/keys.conf, and include it from /etc/named.conf:

include "keys.conf";

The contents of /var/named/keys.conf includes one key record for each user or host that will have DDNS update access. Each key record contains a name, algorithm type, and key. Using the username (foo@bar44.com), algorithm (HMAC-MD5, as shown in the key) and the key from the nsupdate example, the key record will look like

key foo22.bar44.com. {
  algorithm HMAC-MD5;
  secret "YrVW9yP6gNMA7VbcU/r2mSIwYnFj/XkCDd6QuqOHE26/ipnrPy+eXrKr UyaFhB2XWNdVLUX7QCUkfhg4zN5YiA==";
};

(NOTE: "secret" line must appear as a single line in the configuration file, with the two halves separated by a single space character)

Security policy: full access to zone

Once keys are added to the keys.conf file, you may begin associating keys with DNS zones and DNS records, giving the owners of the keys permission to add/update/delete DNS records.

The most simple form of access control grants a key permission to add, updated, or delete any DNS record in a specified DNS zone. This is the allow-update security policy, and is configured with a allow-update statement inside a zone statement, in /etc/named.conf:

zone  "bar44.com" {
  type master;
  file  "bar44.com.zone";
  allow-update {
    key foo22.bar44.com.;
  };
};

The key listed in the allow-update statement must exactly match one key in keys.conf.

Security policy: partial access to zone

A second security policy allows the administrator to grant fine-grained dynamic DNS update access to specific hosts or specific users, the update-policy security policy, which is configured with an update-policy statement inside a zone statement, in /etc/named.conf:

...
update-policy {
  grant <key> <type> <zone> <record-types>;
};
...

key is a key from keys.conf. type is the breadth of grant, such as name or subdomain. zone is the name or subdomain this key is allowed to update, and record-types is a list of DNS record types this key is allowed to update.

Sticking with our previous examples, the following /etc/named.conf example allows laptop.bar44.com (presumably a host key) to update its own DNS record, but no other record. And foo22@bar44.com (a user key) can update any record in the zone.

zone  "bar44.com" {
  type master;
  file  "bar44.com.zone";
  update-policy {
    grant laptop.bar44.com. name laptop.bar44.com. A TXT;
    grant foo22.bar44.com. subdomain bar44.com. ANY;
  };
};

Permissions in /var/named

It is important to ensure that named has permission to

• update zone files when receiving remote dynamic updates
• create new files in /var/named

While doing testing related to the examples in this document, I noticed in syslog (/var/log/messages or /var/log/daemon usually) that I was receiving some strange and unhelpful errors such as open failed: no more and open failed: unexpected error.

After fiddling for a while, I found out that named was trying to create the file /var/named/bar44.com.zone.jnl, but the default Fedora Core 2 permissions did not allow this. After chowning /var/named to user 'named', the updates proceeded without further difficulties.

Note that dynamic updates will stay in /var/named/bar44.com.zone.jnl (or whatever your DNS zone is) for quite some time. Only on server shutdown, or after a length of time has passed, will the text file /var/named/bar44.com.zone actually get updated with the contents of the most recent DDNS updates. Similar to a journalling filesystem, the $zone.jnl file saves updates to prevent data loss in the event of a crash.

Check your work

A simple and easy way to help eliminate config file typos are the programs named-checkconf and its sister program for zonefiles, named-checkzone. You should use these programs to verify that your config file and zone file changes will properly parse and load, before running rndc reconfig or rndc reload.

Don't touch that file!

After receiving updates to a DNS zone, the named server will update /var/named/bar44.com.zone. Since the server is automatically updating this file, it is important to remember to not hand-edit this file, because your changes will be overwritten by the next dynamic update.

If you insist upon hand-editing the file, make sure to first suspend updates to the zone with rndc freeze $ZONE. After editing is finished, you have verified your edits with named-checkzone, and you have incremented the SOA serial number, resume dynamic updates by running rndc thaw $ZONE.