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 <tm>.
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 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 neighbor 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.
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 <keyname>
<keyname> is the name of the key and
can be virtually anything that is formatted as a DNS name. It is
recommended that the keyname be the fully qualified domain name of
the host so that the update-policy self works correctly. (see
Section 6.2.22.4 of the BIND ARM for more information on
update-policy).
The key will be stored in the file
K<keyname>+157+<keyid>.private
<keyid> is the unique id of the key.
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 <randomdev> 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 <keyalg> -b <keysize> -n HOST <keyname>
<keyalg> is the desired algorithm of
the key and can be any of the following values: RSAMD5, RSASHA1,
DSA. We recommend that you use RSAMD5.
<keysize> is the desired size in
bits of the key and the ranges are different depending on the
algorithm:
-
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)
<keyname> is the name of the key.
Since it must be published in the zone file, it should be a subname
of the zone that it is being published in. It is recommended that
the keyname be the fully qualified domain name of the host so that
the update-policy self works correctly. (see Section 6.2.22.4 of the
BIND ARM for more information on update-policy).
The key will be stored in the file
K<keyname>+<keyalg>+<keyid>.private
<keyid> is an identity tag to be
able to differentiate between different keys under the same name.
There will also be a corresponding
K<keyname>+<keyalg>+<keyid>.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 <randomdev> 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 <keyname> {
algorithm HMAC-MD5;
secret "<keydata>";
};
<keyname> is the name of the key
chosen when the key was generated (See the previous step, Generating
TSIG keys).
<keydata> is the string after the
Key: line in the generated key file (See the previous step,
Generating TSIG keys).
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<keyname>+<keyalg>+<keyid>.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 <keyname> name <hostname> 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 <keyname>;
};
<keyname> is the name of the key
chosen when the key was generated (See the previous step, Keys)
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 "<client-fqdn>";
send fqdn.encoded on;
send fqdn.server-update off;
<client-fqdn> is the fully qualified
domain name (including the trailing dot) of the client.
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 <keyname> {
algorithm HMAC-MD5;
secret "<keydata">;
}
zone <zone-fqdn> {
key "<keyname>";
}
<keyname> is the name of the key
chosen when the key was generated (See previous step, Generating
TSIG keys).
<keydata> is the string after the
Key: line in the generated key file (See previous step, Generating
TSIG keys).
<zone-fqdn> is the zone that will
receive the dynamic update. Note that the closing } on the zone
statement does not have a ; after it.
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=<qd.ip.of.ns>
ZONE=<zone-fqdn>
HOSTNAME=<fully-qualified-client-hostname>
KEYFILE=<generated-keyfile>
nsupdate -v -k $KEYFILE > /dev/null << EOF
server $SERVER
zone $ZONE
update delete $HOSTNAME A
update add $HOSTNAME $TTL A $new_ip_address
send
EOF
<qd.ip.of.ns> is the IP address of
the nameserver. The dns name of the nameserver (with a terminal dot)
may be used instead of the name, but will require a name lookup
first.
<zone-fqdn> is the zone that will
receive the dynamic update.
<fully-qualified-client-hostname> is
the fully qualified domain name of the client.
<generated-keyfile> is the filename
of the .private generated keyfile including the directory (See
previous section Keys).
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 "<client-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
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 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
<ttl> is the desired TTL in seconds:
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 behavior 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 surrounded 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 because 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 consistent.
-
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 perceived 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.INCNAMElaptop.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.INPTRlaptop.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 servers.
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 synchronized 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 with key-rollover in a dynamic
updated zone. The steps described below is a rough generalization 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 exercise is to minimize the
"rollover-state" time, since production state is critical.
while in state 1):
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 & disallow 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:
The following command puts the status in state 3)
Issues
The above scenario demonstrates the clash between
dynamically 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 queue 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. Even
though 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 of course impossible to perform an ixfr.
|
