Secure dynamic DNS howto
Table of contents
Background
This text was produced at the DNSSEC/DYNUPD workshop hosted by the RIPE NCC. The workshop took place at the Grand Hotel Krasnapolsky in Amsterdam, the Netherlands, between January 21-24, 2002.
Participants and authors:
Brian Wellington, Daniel Massey, David Blacka, Ed Lewis, Jaap Akkerhuis, Jakob Schlyter, Johan Ihrén, Lars-Johan Liman, Mark Kosters, Olaf Kolkman, Randy Bush, Roy Arends, Scott Rose, Ted Lemon, Ted Lindgreen and Wesley Griffin.
This document only covers use with ISC's BIND 9 and DHCP software. If anyone can help with examples using other products that use the same standards, we would be delighted to include them. Send text .
Why Dynamic Update?
Dynamic update proposes to provide a workable solution to the seemingly trivial operation of exchanging data between two computers with known names both visiting a foreign network where we don't know, care or trust the underlying address. This feature has long been available for specific platforms, but a general OS-agnostic method has been lacking.
We now have a more or less ubiquitous availability of DHCP, increasing use of TSIG in the DNS infrastructure and a renewed interest in getting DNSSEC deployed. Therefore it seems possible to to, in a secure fashion, both publish and consume locally available information via appropriate application protocols (ftp, http, whatever).
To put it simply, it is now possible to point your neighbour at the IETF conference to a web page on your laptop by pointing at the URL on your business card.
Why Secure Dynamic Update?
Secure dynamic update in this context covers the entire chain from the client initiated update (protected by a TSIG or SIG(0) signature) via the automatic resigning of the updated records (via online DNSSEC keys) in the zone to the final server synchronization via update of the serial number and slave notification and subsequent IXFRs.
Dynamic update of a zone and DNSSEC signing of a zone are orthogonal concepts. However, since both require modern software and both require key management the additional cost of full DNSSEC for such a zone becomes marginal and is therefore a good idea.
Comments
Please send comments on this document to dnsop@cafax.se.
Introduction
There are three steps to configure dynamic updating of the forward zone, which are divided into the three following sections:
- Decide on which keying method you will use
- Configure the server
- Configure the client
Once these three steps have been completed, the next section discusses how to test the dynamic update setup.
Software Requirements
- BIND 9.2.0 or newer
BIND 9.3.0s20020122 (9.3.0 snapshot) or newer required for SIG(0)
Note: BIND has to be compiled with OpenSSL (built using the '--with-openssl' configure option) if you want to use DNSSEC features such as SIG(0) or a signed zone. - ISC DHCP 3.0.1rc7 or newer
Keys
You have to choose one of two different key types to use to secure the dynamic update: TSIG keys and SIG(0) keys.
TSIG Keys
TSIG keys are symmetric HMAC-MD5 keys.
Pros
- The configuration is slightly more simple on both the server and client side.
- Both the built-in dhclient updater and dhclient-exit-hooks script can be used to perform the dynamic update (See Section 4. Configuring the Client).
- Supported in the release version of BIND 9.2.
Cons
- The key is a symmetric key, with both the server and client having full knowledge of the key. This may be a consideration if, as a client, you do not actually own the forward zone name server and do not want to share a symmetric key with the zone operator.
- If you run your name server on a shared/multi-user host, then there is the chance you can accidentally divulge the TSIG key to the other users, which, being a symmetric key, could allow them access to your zone.
- The client can not use dynamic update to update the key, because the symmetric key should never be published in the zone.
Generating TSIG Keys
TSIG keys are generated with the following command:
$ dnssec-keygen -a HMAC-MD5 -b 512 -n HOST
The key will be stored in the file K+157+.private
This file will not be used directly by anything, and the key is the string after the Key: line in the file (See the next step, Configuring the DNS Server).
One possible problem that can be encountered with dnssec-keygen is that it might use up all the entropy in /dev/random before it is done generating the key. This will make dnssec-keygen appear to hang, when in fact it is simply waiting for more entropy.
One solution to feed more entropy to the system is to generate it by creating system activity. In another window you can compile a kernel, visit websites, etc. What precisely you should do depends on the operating system and how it was compiled, but generally anything involving keyboard I/O will work.
A less secure, and not recommended, solution to this is to use the -r parameter that allows you to specify another random device, such as /dev/urandom. This is not recommended, because the /dev/urandom device does not guarantee the data to be strong and will continue to output data even when the entropy has been exhausted.
SIG(0) Keys
SIG(0) keys are asymmetric key-pairs. There is a public key and a private key forming a SIG(0) key-pair. They can be of any of the asymmetric key algorithms (RSAMD5, RSASHA1, DSA).
Pros
- The client can use dynamic update to update the key, because the public key must be published in the zone.
- The key is an asymmetric key-pair, with only the client having knowledge of the private key. This may be a consideration if, as a client, you do not actually own the forward zone name server and do not want to share a symmetric key with the zone operator.
- If you run your nameserver on a shared/multi-user host, then accidentally divulging the key is not a concern, because the name server only has the public key portion of the key-pair.
Cons
- The configuration is slightly more complex on the server side.
- Only the dhclient-exit-hooks script can be used to perform the dynamic update, the built-in dhclient updater does not support SIG(0) dynamic update.
- dhclient-exit-hooks can be used only to call a BIND 9.3 (currently, an unreleased snapshot) nsupdate.
- It is not possible to use SIG(0) to update the reverse tree since the ISC DHCP server currently only supports TSIG.
Generating SIG(0) Keys
SIG(0) keys are generated with the following command:
$ dnssec-keygen -a -b -n HOST
- RSAMD5: 512 to 4096 (recommended size 1024)
- RSASHA1: 512 to 4096 (recommended size 1024)
- DSA: 512 to 1024 (must be divisible by 64, recommended size 1024)
The key will be stored in the file K++.private
There will also be a corresponding K++.key file that contains a DNS KEY resource record formatted for inclusion in the zone file.
One possible problem that can be encountered with dnssec-keygen is that it might use up all the entropy in /dev/random before it is done generating the key. This will make dnssec-keygen appear to hang, when in fact it is simply waiting for more entropy. One solution to this is to use the -r parameter that allows you to specify another random device, such as /dev/urandom.
Configuring the DNS Server
Configuring the server also depends on which type of key you choose.
TSIG Keys
The /etc/named.conf file must be edited to configure the server for dynamic update.
The first step is to configure the server to use the key. This is accomplished with the following lines in the /etc/named.conf file:
key {
algorithm HMAC-MD5;
secret "";
};
SIG(0) Keys
Only the zone file must be edited to configure the server for dynamic update with sig(0). No changes are needed in /etc/named.conf as the client's public, not private, key is in the zone file.
The first step is to add the generated key, using the K++.key file, to the zone file. This generated key file contains a properly formatted resource record that can be simply copy-and-pasted into the zone file.
If you are using DNSSEC signed zones, then the next step is to resign your zone.
Allowing Updates
The final step is to configure the zone to allow updates using the key. The following statements should be added to the zone options block in /etc/named.conf. The simplest configuration is to add:
update-policy {
grant name A TXT;
};
e.g.
zone "example.com" {
type master;
file "master/example.com";
update-policy {
grant foo.example.com. name foo.example.com. A TXT;
};
};
Complex example with a number of hosts allowed to update only their own A+TXT records and one master key allowed to update anything:
update-policy {
grant host1.example.com. name host1.example.com. A TXT;
grant host2.example.com. name host2.example.com. A TXT;
grant host3.example.com. name host3.example.com. A TXT;
grant host4.example.com. name host4.example.com. A TXT;
grant bofh.example.com. subdomain example.com. ANY;
};
Simple example where every key can update the A+TXT records of its matching hostname:
update-policy {
grant * self * A TXT;
};
Note: update-policy is described further in Section 6.2.22.4 of the BIND ARM.
The allow-update statement can also be used, which allows the key to modify any data in the zone. Using more fine grained access control with update-policy is recommended.
allow-update {
key ;
};
Configuring the DHCP Client
There are also two ways to configure the client:
- using the built-in dhclient updater, which you can use for TSIG keys
- using the dhclient-exit-hooks script, which you can use for TSIG or SIG(0) keys
These two options are mutually-exclusive, i.e., you can use either the built-in dhclient updater or the dhclient-exit-hooks script, but you cannot use both at the same time.
Using the Built-in dhclient Updater
The built-in dhclient updater only supports TSIG keys, so if you've chosen to use SIG(0) keys, you must use the dhclient-exit-hooks script.
The dhclient.conf file must be edited to configure the client for dynamic update using the built-in dhclient updater.
The first step is to configure the dhclient with the fully qualified domain name of the client along with some other dynamic update options. This is accomplished by placing the following lines in the dhclient.conf file:
send fqdn.fqdn "";
send fqdn.encoded on;
send fqdn.server-update off;
The second step is to configure the dynamic update key and zone. This is accomplished with the following lines in the dhclient.conf file:
key {
algorithm HMAC-MD5;
secret ";
}
zone {
key "";
}
Using the dhclient-exit-hooks Script
dhclient allows for external events to be called via scripts placed in certain locations. See the man page on dhclient-script(8) for details. In this example, we use /etc/dhclient-exit-hooks to invoke nsupdate.
dhclient does not need any specific configuration to enable use of the /etc/dhclient-exit-hooks script. If the script is present, and readable, then it will be automatically executed.
The dhclient-exit-hooks script uses nsupdate from the BIND distribution which must be available on the client machine. nsupdate supports both TSIG and SIG(0) keys.
If you're using TSIG keys and have decided to use the dhclient updater, then you must not use the dhclient-exit-hooks script.
The dhclient-exit-hooks script shown below can be used for both TSIG and SIG(0) keys, the only difference is which keyfile is specified. Both the .key and .private files of the generated keyfiles must be present in the same directory on the client for nsupdate to operate correctly.
TTL=3600
SERVER=
ZONE=
HOSTNAME=
KEYFILE=
nsupdate -v -k $KEYFILE > /dev/null <<>
TTL specifies the time to live of the updated records. [ NOTE: we need to probably discuss this somewhere ]
This script calls nsupdate, specifying -v to use TCP to send the dynamic update. The four lines "server...", zone...", update...", and update..." tell nsupdate what actions to perform on the specified zone at the specified server. The "send..." line tells nsupdate to finally send the query. See the nsupdate man page for more information.
No changes are needed to /etc/dhclient.conf other than:
send fqdn.fqdn "";
send fqdn.encoded on;
send fqdn.server-update off;
Assuming the use of TSIG to authenticate dynamic updates, three entities are involved in the updating of the "reverse map" zone corresponding to a DHCP server's IP allocations. The three entities are the DHCP server, the DHCP client, and the DNS server.
See the previous section Keys to generate TSIG keys.
Assuming the use of BIND's DNS implementation and ISC's dhcp (dhcpd and dhclient) implementation, three files need to be modified. The three files are /etc/named.conf (assuming default names of files), /etc/dhcpd.conf for the DHCP server, and /etc/dhclient.conf for the DHCP client.
The steps that need to be accomplished are:
- Configure the DHCP server and DNS server to use and require authenticated dynamic update messages.
- Configure the DHCP server to update the appropriate in-addr.arpa subzone each time that a lease is let or modified.
- Configure the DHCP client to give the DHCP server a domain name to insert in a PTR RR.
- Configure the DHCP client to prohibit the DHCP server from attempting to insert an A RR for the supplied name.
Step 1
This step is explained in detail elsewhere. What is needed is a shared secret (again, assuming TSIG) for to secure the messages between the DHCP server and DNS server. In /etc/named.conf, the key is needed, and granted the authorization to make prescribed changes. In /etc/dhcpd.conf, the DHCP server is also given the key (using the same syntax as in the /etc/named configuration file), and is configured to use the key. "Configured" means that there is a zone statement block, with the secret specified inside.
Configuration examples:
In /etc/named.conf:
key update.1.168.192.in-addr.arpa. {
algorithm hmac-md5;
secret "0huPr3nqFnxUETlrM/VxGg==";
};
zone "1.168.192.in-addr.arpa" {
type master;
file "zones/1.168.192.in-addr.arpa";
allow-update { key update.1.168.192.in-addr.arpa.; };
};
(Note that the use of allow-update may be too loose.)
In /etc/dhcpd.conf:
key update.1.168.192.in-addr.arpa. {
algorithm hmac-md5;
secret "0huPr3nqFnxUETlrM/VxGg==";
}
zone 1.168.192.in-addr.arpa {
key update.1.168.192.in-addr.arpa.;
}
To force dhcpd to send the update to a specific server, as opposed to searching the RRset of NS RRs, you can use the
primary ;
sub-statement of the zone statement above.
Step 2
The DHCP server needs to be configured to perform updates. This is done by inserting one line in statement "ddns-update-style interim;". In /etc/dhcpd.conf:
ddns-update-style interim;
Step 3
In order for the DHCP server to know how to properly form the PTR RR inserted into the reverse map zone, the DHCP server either makes up a name or uses one supplied by the client. Assuming the DHCP client wants a specific name to be used, the DHCP client must be configured to submit a name to the the server. For example, a DHCP client wanting the name "hostname.example.com" is let the address 192.168.1.40, and will see this PTR RR appear:
40.1.168.192.in-addr.arpa. 3600 IN PTR hostname.example.com
This is done with the send fqdn.fqdn option in /etc/dhclient.conf:
send fqdn.fqdn "hostname.example.com.";
send fqdn.encoded on;
The last line, "encoded on" tells the DHCP client to transmit the domain name in the DNS protocol format. This item should always be set "on."
Step 4
Assuming that the DHCP client machine is going to alter the "forward map" zone (the A RR), the DHCP server should not attempt to do this. There are two reasons why the DHCP server should not attempt to update the forward zone - the effort may be redundant of an effort by the DHCP client, and the DHCP server may lack the authorization that the DHCP client has to do this.
To inform the DHCP server to not attempt the forward map update, the DHCP client specifies an option (setting). To make the DHCP client do this, in /etc/dhclient.conf:
send fqdn.server-update off;
Summary
In summary, the configurations shown above are summarized as this:
In /etc/named.conf:
key update.1.168.192.in-addr.arpa. {
algorithm hmac-md5;
secret "0huPr3nqFnxUETlrM/VxGg==";
};
zone "1.168.192.in-addr.arpa" {
type master;
file "zones/1.168.192.in-addr.arpa";
allow-update { key update.1.168.192.in-addr.arpa.; };
};
In /etc/dhcpd.conf:
key update.1.168.192.in-addr.arpa. {
algorithm hmac-md5;
secret "0huPr3nqFnxUETlrM/VxGg==";
}
zone 1.168.192.in-addr.arpa {
key update.1.168.192.in-addr.arpa.;
}
ddns-update-style interim;
In /etc/dhclient.conf:
send fqdn.fqdn "hostname.example.com.";
send fqdn.encoded on;
send fqdn.server-update off;
Setting the TTL used for A and PTR records updated by the DHCP client and server
The DHCP client currently sets the TTL to one half of the lease duration. This means that if the client's IP address changes during that period, any cached versions of the client's A record will be wrong. The DHCP server sets the TTL of the A and PTR records to 3600 seconds, but can be configured to set it to any value. For DHCP clients, a very small value is probably appropriate - even as little as ten seconds. To set the TTL in the DHCP server, add the following to your /etc/dhcpd.conf file, where is the desired TTL in seconds:
ddns-ttl ;
Setting the hostname for clients not sending the fqdn or host-name options
To set the hostname for clients not sending the fqdn option, add something like following to your /etc/dhcpd.conf file. The actual hostname in the example below will, for ip address aaa.bbb.ccc.ddd, be dhcp-aaa.bbb.ccc.ddd. For more information on how to define your own hostname format, consult the dhcpd documentation.
ddns-hostname = pick (option fqdn.hostname, option host-name,
concat ("dhcp-",
binary-to-ascii (10, 8, "-", leased-address));
option host-name = config-option server.ddns-hostname;
The ISC server will accept a hostname sent in the host-name option as well as the fqdn option, so the function of the code we added is simply to make up a name in the event that the client sends neither option.
In order to monitor the behaviour of a setup, proper logging should be in place.
Configuring Logging for the DNS Server
There are several categories that log messages fall in to. For instance, all queries fall in to the "queries" category, all notify messages will fall in to the "notify" category, and so on. We are interested in the "dnssec", the "update" and the "security" categories.
The messages for every category are channeled into files or through syslog. The channel phrase can be used to specify which severity level should be logged, how the format of the log message should be, what extra information should be logged, where it should be logged, how many versions should be kept, and how large the zone file may grow.
For this setup we will log all above categories in one place:
logging {
category dnssec { security_log; };
category update { security_log; };
category security { security_log; };
channel security_log {
file "dns-security.log" versions 5 size 20m;
// every time the log grows over 20 Mbyte, it will
// backup and rollover. Maximum 5 backups will be kept.
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
};
Debugging DNS updates from the DHCP server and client
When debugging problems with DHCP server DNS updates, first make sure that the DHCP server is parsing the configuration file correctly. You can test this with "dhcpd -t". If the DHCP server prints error messages when you run it, you must fix these errors before proceeding. If you are also modifying the DNS configuration file, you may make the mistake of putting a ";" after a "}". This is allowed for the key declaration so that keys can be shared between the DHCP and DNS servers, but the DHCP server normally does not allow a ";" after a "}".
Once you have a clean parse of the config file, you can watch what the DHCP server is doing in syslog, or you can run "dhcpd -d" to have the DHCP server run in the foreground and print errors to the controlling terminal.
The DHCP server logs by default to the LOG_DAEMON facility. Errors are logged at LOG_ERROR, but a lot of additional information is logged at LOG_INFO or LOG_DEBUG, so if you are debugging, it's good to have a syslog file that records INFO- and DEBUG-level messages.
Assuming that you have your DHCP client configured to send an FQDN option as described elsewhere in this document, the DHCP server should not attempt to update the client's A record. When the client gets a lease, you should see a log message like this:
Jan 23 18:38:51 dhcpd dhcpd: added reverse map from 61.5.0.193.in-addr.arpa. to roam.randy.ws.sigz.net.
If, instead, you see a message like this, it means that the client is not sending a fully-qualified domain name:
Jan 23 18:38:51 dhcpd dhcpd: unable to add reverse map from 61.5.0.193.in-addr.arpa. to roam.randy.ws.sigz.net.
This can be either because it is not sending an FQDN option at all, or because it is sending an unqualified domain name in the FQDN option. It is possible to see this same problem even if your client is sending an FQDN option that contains more than one label. For example, you might see:
Jan 23 16:20:39 dhcpd dhcpd: Unable to add forward map from
laptop.yfd.example.yfd.example to 193.0.4.46: timed out
This means that the client has almost been configured with a fully-qualified domain name, except that the root label was left off. On the ISC DHCP client, you need to do this:
send fqdn.fqdn "laptop.yfd.example.";
not this:
send fqdn.fqdn "laptop.yfd.example";
Notice the trailing '.' in the first example. If the client doesn't send a fully-qualified domain name, the DHCP server assumes that the name is to be added in a forward zone that has been configured on the server. You will also see this behavior if the client has not been configured to tell the server that it will update its own A record. You must have this line in your dhclient.conf:
send fqdn.server-updates false;
If you see a message like this, it means either that your DHCP server isn' t using the right key to update the record, or that it is not using any key to update the record, or that the primary DNS server for the zone is not reachable. Make sure you have a zone statement, and that you used the same name for the key on both the DHCP and DNS servers:
Jan 23 16:29:47 dhcpd dhcpd: delete 43.5.0.193.in-addr.arpa. IN PTR add 43.
5.0.193.in-addr.arpa. 30 IN PTR laptop.yfd.example: timed out.
If you see this message, your key isn't a valid key to use to update the zone:
Jan 23 16:29:47 dhcpd dhcpd: delete 43.5.0.193.in-addr.arpa. IN PTR add 43.
5.0.193.in-addr.arpa. 30 IN PTR laptop.yfd.example: invalid TSIG key.
If you see this, your clocks are out of sync. Make sure you use "date -u" when comparing clock times. Clocks must be within five minutes of each other:
Jan 23 16:29:47 dhcpd dhcpd: delete 43.5.0.193.in-addr.arpa. IN PTR add 43.
5.0.193.in-addr.arpa. 30 IN PTR laptop.yfd.example: clock skew too great.
This message means that the zone statement in your configuration file doesn't refer to an actual zone in the DNS. It is possible to have a subdomain that is not a zone. In order for a domain to be a zone, it must have an SOA record. So if you get this message, find the most specific SOA record above the name you are updating and write a zone declaration for the name to which that SOA record is attached:
Jan 23 16:29:47 dhcpd dhcpd: delete 43.5.0.193.in-addr.arpa. IN PTR add 43.
5.0.193.in-addr.arpa. 30 IN PTR laptop.yfd.example: not a zone.
The same logging configuration described for the server applies to the client. The error messages described above also have the same meanings on the client.
General
Documentation
The documentation for the involved programs and protocols could be clearer and definitely need more and better examples. This has been reported and will hopefully be improved in the future.
Syntactic differences
There are unfortunate syntactic differences between dhclient.conf, dhcpd.conf, and /etc/named.conf. In some places a certain item is expected to be surronded by quotes ("), in other places not. Sometimes a command is terminated with semicolon (;), in other places the same command is not, etc. This is very confusing, and one has to read the documentation carefully.
Clocks
The clocks in the participating computers must be in sync, especially for updates for updates performed with TSIG. Use of NTP is strongly recommended.
Serial numbers
Since the SOA serial number is incremented for every update of the zone file, one can no longer depend on the correctness of numeric structures (such as the common YYYYMMDDnn formula) of serial numbers in zones subject to dynamic updates. Beware that if you lower the serial number in an existing zone, you have to take manual steps to re-synchronize all slave servers for the zone.
TTLs
The DNS TTL (time to live) property mixes poorly with dynamic updates and DHCP. There is no guarantee that the TTL will match the remaining DHCP lease time for the client at any given moment. This remains to be a discussion topic.
Deleting the updates in the forward tree
After one leaves the temporary network, the forward tree must be updated to remove the temporary IP address issued by the DHCP server. Many options were suggested, but all were rejected because of some issue or another.
- Do nothing - rejected because the IP address may be re-assigned before the DHCPclient can change it again.
- Delayed deletion - the client sends a pre-signed "delete" dynamic update message to the DHCP server to send after a lease expiring. Defeated becuase opens up a DoS attack (attacker issues replay attack after the lease renew, but before the TSIG fudge value expires).
- Forward server watchdog process that listens for remote host to leave the net - messy to implement, and may not work if remote connection is not consistant.
- Have the forward DNS server "lease" the change - also messy and may result in errors causing service denials.
Separate dynamic zones
It seems unlikely that dynamic update, regardless of its security, will be enabled for all zones. Among the reasons for this is the different traceability characteristics of a zone with "important servers" and a zone with "mobile laptops". In the server zone it is crucial to be able to keep track of who did exactly what change when and why, and typically the (static) zone file is under some sort of revision control that interacts extremely poorly with a dynamically updated zone.
But at the same time it seems unlikely that people using dynamically updated DNS entries for their machines will be satisfied with an longer (therefore percieved as "inferior") domainname like "laptop.dynamic.example.com."
The best suggestion we have to ameliorate this situation is to go the CNAME way. I.e.:
laptop.example.com. IN CNAME laptop.dynamic.example.com.
However, if and when doing that, it is probably desirable to have the reverse mapping point at the "exposed name, rather than the CNAME. I.e.:
x.y.z.w.in-addr.arpa. IN PTR laptop.example.com.
DNS Server Side
BIND only
The only DNS server available to the workshop participants that was able to deal with dynamic updates of secure zones at the time was BIND. Thus, we only give you instructions for platforms that are supported by BIND for the DNS serers.
Update policy
The zone subject to dynamic updates needs an update policy. Care should be exercised to not devise a too liberal update policy. Especially the zone apex records (SOA, NS, ...) need to be protected from updates by malicious/clueless clients.
Manual updates and journal files
When dynamic update is enabled for a zone, the zone can no longer be manually edited as normal. Attempting to do so may work in some cases, but will usually result in a name server error.
The DNS server keeps a journal file of incoming updates. The file is not automatically syncronized with the zone file, but can be forced with the "rndc stop" command. Extreme care has to be exercised when manually updating a zone subject to dynamic updates.
When using BIND 9.2, the following must be done to edit a master file of a zone maintained by dynamic update. Note that this stops named until the process is complete.
rndc stop- remove the journal file (.jnl)
- edit the zone
- start named
When using a recent BIND 9.3 snapshot (that is, newer than bind-9.3.0s20020122) , the following can be used instead, which does not require that named be stopped:
rndc freeze zone- edit the zone
rndc unfreeze zone
DHCP Client Side
MacOS
The DHCP client in MacOS does not know how to do dynamic updates, so it could not be used in the tests.
Windows
The DHCP client in Windows does do updates, but needs GSS-TSIG to have full functionality, so it could not be used either in the tests.
(Net|Free|Open)BSD/Linux
Updates seem to work with modern DHCP clients running on Unix or Linux.
First cycle bug
Several BSD platforms reported that when the dhclient was tasked with sending updates, the update would not reach the DNS server when the IP address was initially handed out, but when it was refreshed (half a lease time later) the update came and was processed orderly. This was found to be a race condition in the dhclient, and will be fixed in coming releases.
DHCP-ID
dhclient uses a DHCP-ID to indicate that a DNS record has been updated by a certain client. The DHCP-ID is either provided by the client as a configured value, or a hash value automatically computed over a combination of the FQDN of the host and its MAC address. Currently the DHCP-ID is stored in the DNS (by dhclient) as a TXT record (in lack of a proper DNS record). dhclient will only update the record if it either doesn't exist at all, or if the corresponding DHCP-ID matches. Otherwise it's left as it is. Therefore, if a DNS file contains a static record for a hostname, that you suddenly want to allow dynamic updates to, the record must first be removed manually. If there is another TXT record with the same owner name, the update will not take place.
No turning off forward updates
The DHCP server is told by the dhclient whether the server is expected to update the forward zone or not. The configuration is such that either the server is tasked to do this, or the client assumes that it should to it itself. There is no way to configure the client to neither tell the server to do it, nor perform the update itself. This is problematic if you want to do the update from a script outside the dhclient.
Multiple forward zones
dhclient does not yet deal with multiple forward zones, i.e., a laptop can not automatically update the two zones hostname.example.com, and hostname.myhomenet.org.
Updating Signed Zones
DNSSEC model changing
This document does not cover how to make your zone secure. Please be aware that the DNSSEC model is undergoing change, and the workshop was based on the available software that handles the RFC 2535 model. It is expected that this model will change when/if the "Delegation Signer (DS)" record is introduced. (See "draft-ietf-dnsext-delegation-signer-05.txt", work in progress). Since DS is not handled by current software, it could not be tested.
Deleting the last record
BIND 9.2.0 has a bug where if you try to delete the last data record (apart from the zone SOA and NS records) from a zone, it will fail to perform the update. The bug may show its ugly face under other circumstances too. The bug has been reported but not yet fixed.
Signing key on-line
If the server is to be able to update records in a signed zone, it must be able to sign new records added to the zone. Thus the private half of the zone key must be stored on line, at the name server's disposal, typically as a readable file in the directory specified in the "directory ".....";" statement in the /etc/named.conf file. This might be considered bad security practice.
TSIG vs. SIG(0)
The BIND 9.2.0 way of securing the update transaction is through TSIG. TSIG uses symmetric keys, which means, in a sense, a system with a higher built-in risk than one with asymmetric keys. If one side is compromised, the other one falls at the same time. The alternative method with asymmetric keys (usually referred to as SIG(0)) is not easily supported in BIND 9.2.0, but given the higher risk with symmetric keys, SIG(0) is the preferred method. There are patches for BIND 9.2.0 to support this, and it will hopefully be supported in future releases.
TTLs and signature lifetimes
As mentioned, TTLs mix poorly with dynamic updates, and even more so with DNSSEC signatures. Signature lifetimes can be specified for all records in a zone, but there is currently no way to specify them with better precision than days. This should probably be mended in the future, but it has complicated consequences for caching and signature validation, and it remains an open question how you should choose the signature lifetimes and whether all records should have the same lifetime.
It should also be noted that the server will not automatically re-sign records for which the signature has expired. The consequences of this are not fully penetrated.
Signing updates with multiple keys
If multiple zone keys are present in the zone, but not in the BIND working directory, a SERVFAIL error is returned for the update. This bug has been fixed and the fix will be part of future releases. The solution will be that the server will generate SIG records using any zone keys found in the directory.
Updating the zone apex - don't!
You must not update the KEY record at zone apex, since that will immediately invalidate entire zone, due to the fact that the KEY record set has changed, and the parent SIG is thereby no longer valid.
Key roll-over
Doing key roll-over is extremely complicated, especially if one wants to do it from a remote site. The following text demonstrates the issues involved wrt key-rollover in a dynamic updated zone. The steps described below is a rough generalisation on the actual steps involved.
This is the basic idea:
There are 3 states,
- "before" production state
- "rollover" state
- "after" production state
The purpose of this excersize is to minimize the "rollover-state" time, since production state is critical.
while in state 1):
- 1.1 Generate new key
- 1.2 Generate the key-set
- 1.3 Have the key-set signed by the parent
- 1.4 Change the configuration, so updates are not allowed
The following will transfer the nameserver from state 1 to state 2. A possible feature request may be (and is already issued :-) to have the two steps below in one (ie. rndc flush & dissallow update) (see issues section)
- 1.5 Stop the nameserver, so the journal-file gets flushed into the zone.
- 2.1 Start the nameserver. Now updates are not allowed.
while in state 2:
- 2.2 Add keyset to zone.
- 2.3 Resign zone.
- 2.4 Change configuration back to allow update.
The following command puts the status in state 3)
Issues
The above scenario demonstrates the clash between dynamicly updating the zone and manually updating the zone (one needs to re-sign the zone with the new key).
As shown above, during the re-sign of the zone, it needs to be physically on disk, and therefore new dynamic updates need to stop (temporarily) and current (pending) updates needs to be flushed to the zone on disk.
If there is a strong requirement for dynamic updates, stopping the nameserver from receiving dynamic updates poses a problem.
Several solutions to this problem came to mind:
- Dynamically resigning a zone (infinite ugliness!)
After the new private key is put on the nameserver, one can traverse the zone (through NXT records) and dynamically update all records. - Somehow accept and que pending updates (significant ugliness).
This introduces another problem. If the "rollover state" exceeds the time a dynamically updated record exists (i.e. add-delete during this time) the nameserver does redundant work, and meanwhile the client is not able to have its desired records published. - Somehow accept and propagate updates during the zone-signing session (moderate ugliness)
This means the journal file will already have the signatures of the new key, the file-on-disk is signed offline, and after a flush, the journal file will be included in the zone-file-on-disk. Eventhough the zone file is manually changed, there are no records deleted, no new names added, and only records (NXT SIG) with the same name changed. Since it is not allowed to manually update (delete) NXT and SIG records, there seems to be no clash. This makes it ofcourse impossible to perform an ixfr.
July 28th, 2008 at 3:32 pm
query-source address * port 53;
you should edit the article ASAP and add that they should remove this line…
http://www.google.com/search?q=dns+poisoning+kaminsky&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
July 28th, 2008 at 3:32 pm
or edit it, so it gets:
query-source address *;
July 29th, 2008 at 8:00 pm
@gp
updated article
August 1st, 2008 at 5:24 pm
dnsmasq is a much simpler solution for admins with small networks. It’s a combined DHCP/DNS server which automatically resolves queries for the hostnames of DHCP clients, has static DHCP/DNS entry support, etc.
That said, I do have a large network with 2nd and 3rd-level domains and multiple offices, and we use BIND/DHCPD. Thanks for writing this!
August 21st, 2008 at 4:46 am
No mention of the fact that you need to have DHCP3-Server, not just plain old DHCPD, for this to work.
September 25th, 2008 at 4:58 pm
hi, newbie here. i just installed ubuntu desktop in vmware and i am wondering if this tutorial will work with what i have. pls let me know so i can try it. thanks.
October 17th, 2008 at 4:18 pm
nice tutorial, but i have a problem:
sudo /etc/init.d/dhcp3-server restart
sudo /etc/init.d/bind9 restart
sudo rndc reload
can’t open /etc/bind/rndc.key: Permission denied