- Dynamic DNS
- Of Masters and Slaves
- Accepting and Doing Updates
- TSIG
- The Dynamic Zone
- The Client
- Update Prerequisites
- Update Actions
- Using nsupdate
- Slave Server Issues
- Reverse Zones
- A One Host Zone
- DHCP
- Mixing DNS and DHCP Implementations
- DHCP and Static DNS Entries
- DHCP and Dynamic DNS Entries
- Dynamic Updates by the Client
The Dynamic Zone
An important thing to note is that a zone maintained dynamically cannot be maintained any other way. The primary master will maintain the zonefile automatically and BIND expects to be the sole updater of the file. Any effort to edit it manually will result in mayhem and confusion. Although, this does not stop you from maintaining the zone wholly with the dynamic DNS tools, and indeed you can do that.
But, due to this restriction and because they want to keep using the tools they know to maintain their normal zones, many sites set up separate zones for dynamic DNS.
The Penguin company has hired 16 new employees and wants to maintain their workstations in a dynamic zone. The company adds dyn.penguin.bv. This must be a separate zone, delegated in the normal way with NS records in the parent zone. In the penguin.bv zone, this is added to delegate the zone to the named servers:
dyn NS ns dyn NS ns.herring.bv.
In named.conf dyn.penguin.bv is added in the normal way, less one detail—the allow-update ACL:
zone "dyn.penguin.bv" {
type master;
file "pz/dyn.penguin.bv";
allow-update {
192.168.55.2;
};
};
This zone specifies which hosts are allowed to update the zone. In this case it is the nameserver's own IP address. It will also act as a DHCP server so all updates will come from itself. To use TSIG authentication of updates, a key pair must first be generated:
# dnskeygen -H 512 -h -n ns.penguin.bv. Generating 512 bit HMAC-MD5 Key for ns.penguin.bv. Generated 512 bit Key for ns.penguin.bv. id=0 alg=157 flags=513
Two files were created: Kns.penguin.bv.+157+00000.key and Kns.penguin.bv.+157+00000.private. They both contain the same secret key, but in different formats. The .key file is in DNS zone file format. The key must be stolen for the thief to be able to sign as you would and thus be indistinguishable from you for the DNS server. Keep your key on a secure machine, and as with sensitive passwords, change it now and then—especially when key staff leaves you or whenever you have security incidents. Keeping your keys secure is not a matter to be taken lightly.
The public key must be entered in the named.conf file, or in a file it includes, and the file containing it must of course be read restricted. The audience able to read it should be miniscule.
key ns.penguin.bv. {
algorithm hmac-md5;
secret "XBzxlscP7rw3vfqF/yONoGNDQKMKgAcndBhKednuwlgqMc2rTVO
jdGv4VqGyhj5uqW/uJlciyn/M045VFonxtQ==";
}The key has been broken to fit in the book. In the file there should be no line break. The zone must be configured to allow for the holder of the key to change it:
zone "dyn.penguin.bv" {
type master;
file "pz/dyn.penguin.bv";
allow-update {
key ns.penguin.bv.;
};
};You can, of course, list several authorized keys and IP-numbers. I will get back to how the client uses the key in a second.
The next task is to seed the dynamic zone—to provide an initial zone file. It should include all the usual records for a zone, perhaps excepting any actual host records. You can add those later. Here then, is a seed file:
$TTL 1m
;
@ 1m SOA ns.penguin.bv. hostmaster.penguin.bv. (
1 ; serial
5m ; refresh
2m ; retry
6h ; expire
1m ; minimum
)
1m NS ns.penguin.bv.
1m NS ns.herring.bv.Which values to use in the SOA record is an interesting question. The answer depends on how often your zone will actually change and how important it is for the change to be known immediately. In some settings the zone might be managed as a dynamic zone, but, in fact, the contents will be highly static. Hosts will keep their IP addresses for a long time, and if it does change it is no catastrophe if the change is not known at once. This is true for many office settings. In other settings hosts will change IP numbers fairly often, perhaps disappear, and when they reappear the new IP number should be known ASAP. This could be the case for a dial-up setting. Of course, whether a host changes an IP number often in a dial-up setting might be an administrative decision as well, and it might prove better not to change IP numbers often.
The SOA shown previously is suited for a highly dynamic zone, where hosts change IP numbers often—potentially several times a day. In the opposite case, the SOA values used for the main penguin zone in Chapter 2 are more appropriate. The thinking behind these values is that the serial number will be automatically maintained by the nameserver. It does not keep it in the yyyymmddnn format and giving the impression that it does by seeding the zone with a serial number in that format is liable to cause confusion.
The refresh interval is short. Normally the NOTIFY protocol discussed in Chapter 2 ensures that the update propagates promptly to all slave servers, but the UDP packed bearing the NOTIFY can get lost occasionally. In that case a five-minute refresh interval might not be too onerous to wait out. If the refresh fails, the transfer will be repeated every retry interval—every 2 minutes here. A shorter interval might be used if failures need to be corrected more quickly. This depends on your environment and requirements.
An interesting problem arises if the zone transfer fails repeatedly. How long is it before the zone expires? In a highly dynamic zone, the data will quickly become stale. Having the slave servers fail rather than serve stale data might be preferable, and possibly set off more alarms as well, which could help the situation to be resolved more quickly. Do not keep a zone immediately under a TLD on such a short leash. The TLD administrators can suspend your domain if it tends to be unavailable. For a highly dynamic zone, six hours might be too much.
The one minute TTL was chosen because that way caches will expire the cached data quickly and rerequest the data, which might have changed, often. This helps ensure that new data becomes known quickly. It is important that the minimum TTL be one minute as well because it controls negative caching of the zone. Very few zones will be this dynamic. For most of them much higher intervals are appropriate.
There is also a scaling problem here. BIND will only do whole zone transfers. If your zone is big and changes often, the load on the DNS hosts and the network can grow into a nuisance or even become intolerable. Incremental zone transfers will fix this, but this is not yet available as of June 2000. The problem will be aggravated by having many slaves for the zone. But I do mean big—say, in the order of several thousand hosts.
Note that BIND does some sanity checks on the SOA values: It wants the refresh interval to be at least two times longer than the retry interval, and the expire interval to be at least one week. If these checks are violated, warning messages will be printed in the logs. The messages can be irritating, but if you choose to set the values contrary to the sanity checks it's okay, because you know what you're doing, right? The expire value shown earlier provokes this warning:
pz/dyn.penguin.bv: WARNING SOA expire value is less than 7 days (21600)
Having edited named.conf and seeded the zone, the nameserver can be "ndc restart"ed, and the zone populated with data. Remember to look in the logs for error and warning messages.