TSIG provides authentication and data integrity through the use of a special type of mathematical formula called a one-way hash function. A one-way hash function, also known as a cryptographic checksum or message digest, computes a fixed-size hash value based on arbitrarily large input. The magic of a one-way hash function is that each bit of the hash value depends on each and every bit of the input. Change a single bit of the input, and the hash value changes dramatically and unpredictably—so unpredictably that it’s “computationally infeasible” to reverse the function and find an input that produces a given hash value.

TSIG uses a one-way hash function called MD5. In particular, it uses a variant of MD5 called HMAC-MD5. HMAC-MD5 works in a keyed mode in which the 128-bit hash value depends not only on the input, but also on a key.

We won’t cover the TSIG record’s syntax in detail because you don’t need to know it: TSIG is a “meta-record” that never appears in zone data and is never cached by a resolver or nameserver. A signer adds the TSIG record to a DNS message, and the recipient removes and verifies the record before doing anything further, such as caching the data in the message.

You should know, however, that the TSIG record includes a hash value computed over the entire DNS message as well as some additional fields. (When we say “computed over,” we mean that the raw, binary DNS message and the additional fields are fed through the HMAC-MD5 algorithm to produce the hash value.) The hash value is keyed with a secret shared between the signer and the verifier. Verifying the hash value proves both that the DNS message was signed by a holder of the shared secret and that it wasn’t modified after it was signed.

The additional fields in the TSIG record include the time the DNS message was signed. This helps combat replay attacks, in which a hacker captures a signed, authorized transaction (say a dynamic update deleting an important resource record) and replays it later. The recipient of a signed DNS message checks the time signed to make sure it’s within the allowable “fudge” (another field in the TSIG record).

Before using TSIG for authentication, we need to configure one or more TSIG keys on either end of the transaction. For example, if we want to use TSIG to secure zone transfers between the master and slave nameservers for movie.edu, we need to configure both nameservers with a common key:

key toystory-wormhole.movie.edu. {
    algorithm hmac-md5;
    secret "skrKc4Twy/cIgIykQu7JZA==";
};

The argument to the key statement in this example, toystory-wormhole.movie.edu , is actually the name of the key, though it looks like a domain name. (It’s encoded in the DNS message in the same format as a domain name.) The TSIG RFC suggests you name the key after the two hosts that use it. The RFC also suggests that you use different keys for each pair of hosts. This prevents the disclosure of one key from compromising all of your communications, and limits the use of each key.

It’s important that the name of the key—not just the binary data the key points to—be identical on both ends of the transaction. If it’s not, the recipient tries to verify the TSIG record and finds it doesn’t know the key that the TSIG record says was used to compute the hash value. That causes errors such as the following:

Jan  4 16:05:35 wormhole named[86705]: client 192.249.249.1#4666:
request has invalid signature: TSIG tsig-key.movie.edu: tsig verify failure (BADKEY)

The algorithm, for now, is always hmac-md5. The secret is the base 64 encoding of the binary key. You can create a base-64-encoded key using the dnssec-keygen program included in BIND 9 or the dnskeygen program included in BIND 8. Here’s how you’d create a key using dnssec-keygen, the easier of the two to use:

#dnssec-keygen -a HMAC-MD5 -b 128 -n HOST toystory-wormhole.movie.edu.
Ktoystory-wormhole.movie.edu.+157+28446

The -a option takes as an argument the name of the algorithm the key will be used with. (That’s necessary because dnssec-keygen can generate other kinds of keys, as you’ll see in the section "The DNS Security Extensions.”) The -b option takes the length of the key as its argument; the RFC recommends using keys 128 bits long. The -n option takes as an argument HOST, the type of key to generate. (DNSSEC uses ZONE keys.) The final argument is the name of the key.

dnssec-keygen and dnskeygen both create files in their working directories that contain the keys generated. dnssec-keygen prints the base name of the files to its standard output. In this case, dnssec-keygen created the files Ktoystory-wormhole.movie.edu.+157+28446.key and Ktoystory-wormhole.movie.edu.+157+28446.private. You can extract the key from either file. The funny numbers (157 and 28446), in case you’re wondering, are the key’s DNSSEC algorithm number (157 is HMAC-MD5) and the key’s fingerprint (28446), a hash value computed over the key to identify it. The fingerprint isn’t particularly useful in TSIG, but DNSSEC supports multiple keys per zone, so identifying which key you mean by its fingerprint is important.

Ktoystory-wormhole.movie.edu.+157+28446.key contains:

toystory-wormhole.movie.edu. IN KEY 512 3 157 skrKc4Twy/cIgIykQu7JZA==

and Ktoystory-wormhole.movie.edu.+157+28446.private contains:

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: skrKc4Twy/cIgIykQu7JZA==

If you prefer, you can choose your own key and encode it in base 64 using mmencode:

%mmencode
foobarbaz
Zm9vYmFyYmF6

Since the actual binary key is, as the substatement implies, a secret, we should take care in transferring it to our nameservers (e.g., by using ssh) and make sure that not just anyone can read it. We can do that by making sure our named.conf file isn’t world-readable or by using the include statement to read the key statement from another file, which isn’t world-readable:

include "/etc/dns.keys.conf";

There’s one last problem that we see cropping up frequently with TSIG: time synchronization. The timestamp in the TSIG record is useful for preventing replay attacks, but it tripped us up initially because the clocks on our nameservers weren’t synchronized. (They need to be synchronized to within five minutes, the default value for “fudge.”) That produced error messages like the following:

wormhole named[86705]: client 192.249.249.1#54331: request has
invalid signature: TSIG toystory-wormhole.movie.edu.: tsig verify failure (BADTIME)

We quickly remedied the problem using NTP, the network time protocol.^[*]

Now that we’ve gone to the trouble of configuring our nameservers with TSIG keys, we should probably configure them to use those keys for something. In BIND 8.2 and later and all BIND 9 nameservers, we can secure queries, responses, zone transfers, and dynamic updates with TSIG.

The key to configuring this is the server statement’s keys substatement, which tells a nameserver to sign queries and zone transfer requests sent to a particular remote nameserver. This server substatement, for example, tells the local nameserver, wormhole.movie.edu , to sign all such requests sent to 192.249.249.1 (toystory.movie.edu ) with the key toystory-wormhole.movie.edu :

server 192.249.249.1 {
    keys { toystory-wormhole.movie.edu.; };
};

If you’re only concerned about zone transfers (and not about general query traffic, for example), you can specify the key in the masters substatement for any slave zones:

zone "movie.edu" {
    type slave;
    masters { 192.249.249.1 key toystory-wormhole.movie.edu.; };
    file "bak.movie.edu";
};

Now, on toystory.movie.edu , we can restrict zone transfers to those signed with the toystory-wormhole.movie.edu key:

zone "movie.edu" {
    type master;
    file "db.movie.edu";
    allow-transfer { key toystory-wormhole.movie.edu.; };
};

toystory.movie.edu also signs the zone transfer, which allows wormhole.movie.edu to verify it.

You can also restrict dynamic updates with TSIG using the allow-update and update-policy substatements, as we showed you in the last chapter.

The nsupdate programs shipped with BIND 8.2 and later and BIND 9 support, sending TSIG-signed dynamic updates. If you have the key files created by dnssec-keygen lying around, you can specify either of those as an argument to nsupdate’s -k option. Here’s how you’d do that with BIND 9’s version of nsupdate:

%nsupdate -k Ktoystory-wormhole.movie.edu.+157+28446.key

or:

%nsupdate -k Ktoystory-wormhole.movie.edu.+157+28446.private

With the BIND 8.2 or later nsupdate, the syntax is a little different: -k takes a directory and a key name as an argument, separated by a colon:

%nsupdate -k /var/named:toystory-wormhole.movie.edu.

If you don’t have the files around (maybe you’re running nsupdate from another host), you can still specify the key name and the secret on the command line with the BIND 9 nsupdate:

%nsupdate -y toystory-wormhole.movie.edu.:skrKc4Twy/cIgIykQu7JZA==

The name of the key is the first argument to the -y option, followed by a colon and the base-64-encoded secret. You don’t need to quote the secret because base-64 values can’t contain shell metacharacters, but you can if you like.

Michael Fuhr’s Net::DNS Perl module also lets you send TSIG-signed dynamic updates and zone transfer requests. For more information on Net::DNS, see Chapter 15.

Now that we have a handy mechanism for securing DNS transactions, let’s talk about securing our whole nameserver.

One of the most important ways you can enhance the security of your nameserver is to run a recent version of BIND. All versions of BIND 8 before 8.4.7 and all versions of BIND 9 older than 9.3.2 are susceptible to at least a few known attacks. Check the ISC’s list of vulnerabilities in various BIND versions at http://www.isc.org/sw/bind/bind-security.php for updates.

But don’t stop there: new attacks are being thought up all the time, so you’ll have to do your best to keep abreast of BIND’s vulnerabilities and the latest “safe” version of BIND. One good way to do that is to read the comp.protocols.dns.bind newsgroup or its mailing list equivalent, bind-users, regularly. If you’d prefer less noise, there’s always the bind-announce mailing list, which carries only announcements of patches and new releases of BIND.^[*]

There’s another aspect of BIND’s version relevant to security: if a hacker can easily find out which version of BIND you’re running, he may be able to tailor his attacks to that version of BIND. And, wouldn’t you know it, since about BIND 4.9, BIND nameservers have replied to a certain query with their version. If you look up TXT records in the CHAOSNET class attached to the domain name version.bind, BIND graciously returns something like this:

%dig txt chaos version.bind.

; <<>> DiG 9.3.2 <<>> txt chaos version.bind.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14286
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; ANSWER SECTION:
version.bind.           0       CH      TXT     "9.3.2"

;; AUTHORITY SECTION:
version.bind.           0       CH      NS      version.bind.

;; Query time: 17 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Sat Jan  7 16:14:39 2006
;; MSG SIZE  rcvd: 62

To address this, BIND versions 8.2 and later let you tailor your nameserver’s response to the version.bind query:

options {
    version "None of your business";
};

Of course, receiving a response like “None of your business” will tip off the alert hacker to the fact that you’re likely running BIND 8.2 or better, but that still leaves a number of possibilities. If you’d rather the reply was less obvious, you can use “version none” with BIND 9.3.0 and later:

options {
    directory "/var/named";
    version none;
};

Now your nameserver will respond to version queries like this:

; <<>> DiG 9.3.2 <<>> txt chaos version.bind.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21957
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; AUTHORITY SECTION:
version.bind.           86400   CH      SOA     version.bind.
hostmaster.version.bind. 0 28800 7200 604800 86400

;; Query time: 2 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Sat Jan  7 16:16:43 2006
;; MSG SIZE  rcvd: 77

Back in the old days of BIND 4, administrators had no way to control who could look up names on their nameservers. That makes a certain amount of sense; the original idea behind DNS was to make information easily available all over the Internet.

The neighborhood is not such a friendly place anymore, though. In particular, people who run Internet firewalls may have a legitimate need to hide certain parts of their namespace from most of the world while making it available to a limited audience.

The BIND 8 and 9 allow-query substatement lets you apply an IP address-based access control list to queries. The ACL can apply to queries for data in a particular zone or to any queries received by the nameserver. In particular, the ACL specifies which IP addresses are allowed to send queries to the server.

options {
      allow-query { address_match_list; };
};

options {
      allow-query { 192.249.249/24; 192.253.253/24; 192.253.254/24; };
};

acl "HP-NET" { 15/8; };

zone "hp.com" {
      type slave;
      file "bak.hp.com";
      masters { 15.255.152.2; };
      allow-query { "HP-NET"; };
};

Arguably even more important than controlling who can query your nameserver is ensuring that only your real slave nameservers can transfer zones from your nameserver. Users on remote hosts that can query your nameserver’s zone data can only look up records (e.g., addresses) for domain names they already know, one at a time. Users who can start zone transfers from your server can list all the records in your zones. It’s the difference between letting random folks call your company’s switchboard and ask for John Q. Cubicle’s phone number and sending them a copy of your corporate phone directory.

BIND 8 and 9’s allow-transfer substatement lets administrators apply an ACL to zone transfers. allow-transfer restricts transfers of a particular zone when used as a zone substatement and restricts all zone transfers when used as an options substatement. It takes an address match list as an argument.

The slave servers for our movie.edu zone have the IP addresses 192.249.249.1 and 192.253.253.1 (wormhole.movie.edu ) and 192.249.249.9 and 192.253.253.9 (zardoz.movie.edu ). The following zone statement:

zone "movie.edu" {
      type master;
      file "db.movie.edu";
      allow-transfer { 192.249.249.1; 192.253.253.1; 192.249.249.9; 192.253.253.9; };
};

allows only those slaves to transfer movie.edu from the primary master nameserver. Note that because the default for BIND 8 or 9 is to allow zone transfer requests from any IP address, and because hackers can just as easily transfer the zone from your slaves, you should probably also have a zone statement like this on your slaves:

zone "movie.edu" {
      type slave;
      masters { 192.249.249.3; };
      file "bak.movie.edu";
      allow-transfer { none; };
};

BIND 8 and 9 also let you apply a global ACL to zone transfers. This applies to any zones that don’t have their own explicit ACLs defined as zone substatements. For example, we might want to limit all zone transfers to our internal IP addresses:

options {
      allow-transfer { 192.249.249/24; 192.253.253/24; 192.253.254/24; };
};

Finally, as we mentioned earlier in the chapter, those newfangled BIND 8.2 and later and BIND 9 nameservers let you restrict zone transfers to slave nameservers that include a correct transaction signature with their request. On the master nameserver, you need to define the key in a key statement and then specify the key in the address match list:

key toystory-wormhole. {
    algorithm hmac-md5;
    secret "UNd5xYLjz0FPkoqWRymtgI+paxW927LU/gTrDyulJRI=";
};

zone "movie.edu" {
    type master;
    file "db.movie.edu";
    allow-transfer { key toystory-wormhole.; };
};

On the slave’s end, you need to configure the slave to sign zone transfer requests with the same key:

key toystory-wormhole. {
    algorithm hmac-md5;
    secret "UNd5xYLjz0FPkoqWRymtgI+paxW927LU/gTrDyulJRI=";
};

server 192.249.249.3 {
    keys { toystory-wormhole.; };  // sign all requests to 192.249.249.3
                                   // with this key
};

zone "movie.edu" {
    type slave;
    masters { 192.249.249.3; };
    file "bak.movie.edu";
};

For a primary nameserver accessible from the Internet, you probably want to limit zone transfers to just your slave nameservers. You probably don’t need to worry about securing zone transfers from nameservers inside your firewall, unless you’re worried about your own employees listing your zone data.

Running a network server like BIND as the root user can be dangerous, and BIND normally runs as root. If a hacker finds a vulnerability in the nameserver through which he can read or write files, he’ll have unfettered access to the filesystem. If he can exploit a flaw that allows him to execute commands, he’ll execute them as root.

BIND 8.1.2 and later and all BIND 9 nameservers include code that allows you to change the user and group the nameserver runs as. This allows you to run the nameserver with what’s known as least privilege: the minimal set of rights it needs to do its job. That way, if someone breaks into your host through the nameserver, at least that person won’t have root privileges.

These nameservers also include an option that allows you to chroot() the nameserver: to change its view of the filesystem so that its root directory is actually a particular directory on your host’s filesystem. This effectively traps your nameserver in this directory, along with any attackers who successfully compromise your nameserver’s security.

Here are the command-line options that implement these features:

If you opt to use the -u and -g options, you’ll have to decide what user and group to use. Your best bet is to create a new user and group for the nameserver to run as, such as bind or named. Since the nameserver reads named.conf before giving up root privileges, you don’t have to change that file’s permissions. However, you may have to change the permissions and ownership of your zone datafiles so that the user the nameserver runs as can read them. If you use dynamic update, you’ll have to make the zone datafiles for dynamically updated zones writable by the nameserver.

If your nameserver is configured to log to files (instead of to syslog), make sure that those files exist and are writable by the nameserver before starting the server.

The -t option takes a little more specialized configuration. In particular, you need to make sure that all the files named uses are present in the directory you’re restricting the server to. Here’s a procedure to set up your chrooted environment, which we’ll assume lives under /var/named:^[*]

If you’re hooked on using ndc to control your BIND 8 nameserver, you can continue to do so as long as you specify the pathname to the Unix domain socket as the argument to ndc’s -c option:

#ndc -c /var/named/var/run/ndc reload

rndc will continue to work as before with your BIND 9 nameserver because it just talks to the server via port 953.

Nameservers really have two major roles: answering iterative queries from remote nameservers and answering recursive queries from local resolvers. If we separate these roles, dedicating one set of nameservers to answering iterative queries and another to answering recursive queries, we can more effectively secure those nameservers.

options {
     recursion no;
};

options {
      fetch-glue no;
};

options {
    allow-query { 192.249.249/24; 192.253.253/24; 192.253.254/24; };
};

options {
    use-id-pool yes;
};

What if you have only one nameserver to advertise your zones and serve your resolvers, and you can’t afford the additional expense of buying another computer to run a second nameserver on? There are still a few options open to you. Two are single-server solutions that take advantage of the flexibility of BIND 8 and 9. One of these configurations allows anyone to query the nameserver for information in zones it’s authoritative for, but only our internal resolvers can query the nameserver for other information. While this doesn’t prevent remote resolvers from sending our nameserver recursive queries, those queries have to be in its authoritative zones so they won’t induce our nameserver to send additional queries.

Here’s a named.conf file to do that:

acl "internal" {
    192.249.249/24; 192.253.253/24; 192.253.254/24; localhost;
};

acl "slaves" {
    192.249.249.1; 192.253.253.1; 192.249.249.9; 192.253.253.9;
};

options {
    directory "/var/named";
    allow-query { "internal"; };
    use-id-pool yes;
};

zone "movie.edu" {
    type master;
    file "db.movie.edu";
    allow-query { any; };
    allow-transfer { "slaves"; };
};

zone "249.249.192.in-addr.arpa" {
    type master;
    file "db.192.249.249";
    allow-query { any; };
    allow-transfer { "slaves"; };
};

zone "." {
    type hint;
    file "db.cache";
};

Here, the more permissive zone-specific ACLs apply to queries in the nameserver’s authoritative zones, but the more restrictive global ACL applies to all other queries.

If we were running BIND 8.2.1 or newer, or any version of BIND 9, we could simplify this configuration somewhat using the allow-recursion substatement:

acl "internal" {
    192.249.249/24; 192.253.253/24; 192.253.254/24; localhost;
};

acl "slaves" {
    192.249.249.1; 192.253.253.1; 192.249.249.9; 192.253.253.9;
};

options {
    directory "/var/named";
    allow-recursion { "internal"; };
    use-id-pool yes;
};

zone "movie.edu" {
    type master;
    file "db.movie.edu";
    allow-transfer { "slaves"; };
};

zone "249.249.192.in-addr.arpa" {
    type master;
    file "db.192.249.249";
    allow-transfer { "slaves"; };
};

zone "." {
    type hint;
    file "db.cache";
};

We don’t need the allow-query substatements anymore: although the nameserver may receive queries from outside our internal network, it’ll treat those queries as nonrecursive, regardless of whether they are or not. Consequently, external queries won’t induce our nameserver to send any queries. This configuration also doesn’t suffer from a gotcha the previous setup is susceptible to: if your nameserver is authoritative for a parent zone, it may receive queries from remote nameservers resolving domain names in a delegated subdomain of the zone. The allow-query solution will refuse those legitimate queries, but the allow-recursion solution won’t.

Another option is to run two named processes on a single host. One is configured as an advertising nameserver, another as a resolving nameserver. Since we have no way of telling remote servers or configuring resolvers to query one of our nameservers on a port other than 53, the default DNS port, we have to run these servers on different IP addresses.

Of course, if your host already has more than one network interface, that’s no problem. Even if it has only one, the operating system may support IP address aliases. These allow you to attach more than one IP address to a single network interface. One named process can listen on each. Finally, if the operating system doesn’t support IP aliases, you can still bind one named against the network interface’s IP address and one against the loopback address. Only the local host will be able to send queries to the instance of named listening on the loopback address, but that’s fine if the local host’s resolver is the only one you need to serve.

First, here’s the named.conf file for the advertising nameserver, listening on the network interface’s IP address:

acl "slaves" {
    192.249.249.1; 192.253.253.1; 192.249.249.9; 192;253.253.9;
};

options {
    directory "/var/named-advertising";
    recursion no;
    fetch-glue no;
    listen-on { 192.249.249.3; };
    pid-file "/var/run/named.advertising.pid";
};

zone "movie.edu" {
    type master;
    file "db.movie.edu";
    allow-transfer { "slaves"; };
};

zone "249.249.192.in-addr.arpa" {
    type master;
    file "db.192.249.249";
    allow-transfer { "slaves"; };
};

Next, here’s the named.conf file for the resolving nameserver, listening on the loopback address:

options {
    directory "/var/named-resolving";
    listen-on { 127.0.0.1; };
    pid-file "/var/run/named.resolving.pid";
    use-id-pool yes;
};

zone "." {
    type hint;
    file "db.cache";
};

Note that we didn’t need an ACL for the resolving nameserver because it’s only listening on the loopback address and can’t receive queries from other hosts. (If our resolving nameserver were listening on an IP alias or a second network interface, we could use allow-query to prevent others from using our nameserver.) We turn off recursion on the advertising nameserver, but we must leave it on on the resolving nameserver. We also give each nameserver its own PID file so that the servers don’t try to use the same default filename for their PID files, and we give each nameserver its own directory so debug files and statistics files are saved in separate locations.

To use the resolving nameserver listening on the loopback address, the local host’s resolv.conf file must include the following:

nameserver 127.0.0.1

as the first nameserver directive.

If you’re running BIND 9, you can even consolidate the two nameserver configurations into one using views:

options {
    directory "/var/named";
};

acl "internal" {
    192.249.249/24; 192.253.253/24; 192.253.254/24; localhost;
};

view "internal" {
    match-clients { "internal"; };
    recursion yes;

    zone "movie.edu" {
        type master;
        file "db.movie.edu";
    };

    zone "249.249.192.in-addr.arpa" {
        type master;
        file "db.192.249.249";
    };

    zone "." {
        type hint;
        file "db.cache";
    };
};

view "external" {
    match-clients { any; };
    recursion no;

    zone "movie.edu" {
        type master;
        file "db.movie.edu";
    };

    zone "249.249.192.in-addr.arpa" {
        type master;
        file "db.192.249.249";
    };

    zone "." {
        type hint;
        file "db.cache";
    };
};

It’s a fairly simple configuration: two views, internal and external. The internal view, which applies only to our internal network, has recursion on. The external view, which applies to everyone else, has recursion off. The zones movie.edu and 249.249.192.in-addr.arpa are defined identically in both views. You could do a lot more with it—define different versions of the zones internally and externally, for example—but we’ll hold off on that until the next section.

Before you start configuring BIND to work with your firewall, it’s important to understand what your firewall is capable of. Your firewall’s capabilities will influence your choice of DNS architecture and determine how you implement it. If you don’t know the answers to the questions in this section, track down someone in your organization who does know and ask. Better yet, work with your firewall’s administrator when designing your DNS architecture to ensure it will coexist with the firewall.

Note that this is far from a complete explanation of Internet firewalls. These few paragraphs describe only the two most common types of Internet firewalls and only in enough detail to show how the differences in their capabilities affect nameservers. For a comprehensive treatment of Internet firewalls, see Building Internet Firewalls by Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman (O’Reilly).

Packet filters

The first type of firewall we’ll cover is the packet-filtering firewall. Packet-filtering firewalls operate largely at the transport and network levels of the TCP/IP stack (layers three and four of the OSI reference model, if you dig that). They decide whether to route a packet based on packet-level criteria such as the transport protocol (e.g., whether it’s TCP or UDP), the source and destination IP address, and the source and destination port (see Figure 11-1).

Figure 11-1. Packet filters operate at the network and transport layers of the stack

What’s most important to us about packet-filtering firewalls is that you can typically configure them to allow DNS traffic selectively between hosts on the Internet and your internal hosts. That is, you can let an arbitrary set of internal hosts communicate with Internet nameservers. Some packet-filtering firewalls can even permit your nameservers to query nameservers on the Internet, but not vice versa. All router-based Internet firewalls are packet-filtering firewalls. Checkpoint’s FireWall-1, Cisco’s PIX, and Juniper’s NetScreen are popular commercial packet-filtering firewalls.

A Gotcha with BIND 8 or 9 and Packet-Filtering Firewalls

BIND 4 nameservers always sent queries from port 53, the well-known port for DNS servers, to port 53. Resolvers, on the other hand, usually send queries from high-numbered ports (above 1023) to port 53. Though nameservers clearly have to send their queries to the DNS port on a remote host, there’s no reason they have to send the queries from the DNS port. And, wouldn’t you know it, BIND 8 and 9 nameservers don’t send queries from port 53 by default. Instead, they send queries from high-numbered ports, the same as resolvers do.

This can cause problems with packet-filtering firewalls that are configured to allow nameserver-to-nameserver traffic but not resolver-to-nameserver traffic, because they typically expect nameserver-to-nameserver traffic to originate from port 53 and terminate at port 53.

There are two solutions to this problem:

• Reconfigure the firewall to allow your nameserver to send and receive queries from ports other than 53 (assuming this doesn’t compromise the security of the firewall by allowing packets from Internet hosts to high-numbered ports on internal nameservers).

• Configure BIND to revert to its old behavior with the query-source substatement.

query-source takes as arguments an address specification and an optional port number. For example, the statement:

options { query-source address * port 53; };

tells BIND to use port 53 as the source port for queries sent from all local network interfaces. You can use a nonwildcard address specification to limit the addresses that BIND will send queries from. For example, on wormhole.movie.edu , the statement:

options { query-source address 192.249.249.1 port *; };

tells BIND to send all queries from the 192.249.249.1 address (i.e., not from 192.253.253.1) and to use a dynamic, high-numbered port.

The use of query-source with a wildcard address is broken in BIND 9 before 9.1.0, though you can tell an early BIND 9 nameserver to send all queries from a particular address’s port 53.

Proxies

Proxies operate at the application protocol level, several layers higher in the OSI reference model than most packet filters (see Figure 11-2). In a sense, they “understand” the application protocol in the same way that a server for that particular application does. An FTP proxy, for example, can make the decision to allow or deny a particular FTP operation, such as a RETR (a get) or a STOR (a put).

Figure 11-2. Proxies operate at the application layer of the stack

The bad news, and what’s important for our purposes, is that most proxy-based firewalls handle only TCP-based application protocols. DNS, of course, is largely UDP-based. This implies that if you run a proxy-based firewall, your internal hosts will likely not be able to communicate directly with nameservers on the Internet.

The original Firewall Toolkit from Trusted Information Systems (now part of McAfee) was a suite of proxies for common Internet protocols such as Telnet, FTP, and HTTP. Secure Computing’s Sidewinder firewall products are also based on proxies, as are Symantec’s firewalls.

Note that these two categories of firewall are really just generalizations. The state of the art in firewalls changes very quickly. New packet filter-based firewalls can inspect application protocol-layer data, while some proxy-based firewalls include DNS proxies. Which family your firewall falls into is important only because it suggests what that firewall is capable of; what’s more important is whether your particular firewall will let you permit DNS traffic between arbitrary internal hosts and the Internet.

The simplest configuration is to allow DNS traffic to pass freely through your firewall (assuming you can configure your firewall to do that). That way, any internal nameserver can query any nameserver on the Internet, and any Internet nameserver can query any of your internal nameservers. You don’t need any special configuration.

Unfortunately, this is a really bad idea, for two main reasons:

For the rest of this chapter, we’ll try to set a good example.

Given the dangers of allowing bidirectional DNS traffic through the firewall unrestricted, most organizations limit the internal hosts that can “talk DNS” to the Internet. In a proxy-based firewall, or any firewall without the ability to pass DNS traffic, the only hosts that can communicate with Internet nameservers are the bastion hosts (see Figure 11-3).

Figure 11-3. A small network, showing the bastion host

In a packet-filtering firewall, the firewall’s administrator can configure the firewall to let any set of internal nameservers communicate with Internet nameservers. Often, this is a small set of hosts that run nameservers under the direct control of the network administrator (see Figure 11-4).

Figure 11-4. A small network, showing select internal nameservers

Internal nameservers that can directly query nameservers on the Internet don’t require any special configuration. Their root hints files contain the Internet’s root nameservers, which enables them to resolve Internet domain names. Internal nameservers that can’t query nameservers on the Internet, however, need to know to forward queries they can’t resolve to one of the nameservers that can. This is done with the forwarders substatement, introduced in Chapter 10.

Figure 11-5 illustrates a common forwarding setup, with internal nameservers forwarding queries to a nameserver running on a bastion host.

Figure 11-5. Using forwarders

At Movie U., we put in a firewall to protect ourselves from the Big Bad Internet several years ago. Ours is a packet-filtering firewall, and we negotiated with our firewall administrator to allow DNS traffic between Internet nameservers and two of our nameservers, toystory.movie.edu and wormhole.movie.edu . Here’s how we configured the other internal nameservers at the university. For our BIND 8 and 9 nameservers, we used the following:

options {
    forwarders { 192.249.249.1; 192.249.249.3; };
    forward only;
};

We vary the order in which the forwarders appear to help spread the load between them, though that’s not necessary with BIND 8.2.3 and later or 9.3.0 and later nameservers, which choose a forwarder to query according to roundtrip time.

When an internal nameserver receives a query for a name it can’t resolve locally, such as an Internet domain name, it forwards that query to one of our forwarders, which can resolve the name using nameservers on the Internet. Simple!

options {
    directory "/var/named";
    forwarders { 192.249.249.1; 192.253.253.3; };
};

zone "movie.edu" {
    type slave;
    masters { 192.249.249.3; };
    file "bak.movie.edu";
};

options {
    directory "/var/named";
    forwarders { 192.249.249.1; 192.253.253.3; };
};

zone "movie.edu" {
    type slave;
    masters { 192.249.249.3; };
    file "bak.movie.edu";
    forwarders {};
};

zone "249.249.192.in-addr.arpa" {
    type stub;
    masters { 192.249.249.3; };
    file "stub.192.249.249";
    forwarders {};
};

zone "253.253.192.in-addr.arpa" {
    type stub;
    masters { 192.249.249.3; };
    file "stub.192.253.253";
    forwarders {};
};

zone "254.253.192.in-addr.arpa" {
    type stub;
    masters { 192.253.254.2; };
    file "stub.192.253.254";
    forwarders {};
};

zone "20.254.192.in-addr.arpa" {
    type stub;
    masters { 192.253.254.2; };
    file "stub.192.254.20";
    forwarders {};
};

If you want to avoid the scalability problems of forwarding, you can set up your own root nameservers. These internal roots will serve only the nameservers in your organization. They’ll know only about the portions of the namespace relevant to your organization.

What good are they? By using an architecture based on root nameservers, you gain the scalability of the Internet’s namespace (which should be good enough for most companies), plus redundancy, distributed load, and efficient resolution. You can have as many internal roots as the Internet has roots—13 or so—whereas having that many forwarders may be an undue security exposure and a configuration burden. Most of all, the internal roots don’t get used frivolously. Nameservers need to consult an internal root only when they time out the NS records for your top-level zones. Using forwarders, nameservers may have to query a forwarder once per resolution.

The moral of our story is that if you have, or intend to have, a large namespace and lots of internal nameservers, internal root nameservers will scale better than any other solution.

movie.edu.  86400  IN  NS  toystory.movie.edu.
            86400  IN  NS  wormhole.movie.edu.
            86400  IN  NS  zardoz.movie.edu.
toystory.movie.edu.    86400  IN  A  192.249.249.3
wormhole.movie.edu.    86400  IN  A  192.249.249.1
                       86400  IN  A  192.253.253.1
zardoz.movie.edu.      86400  IN  A  192.249.249.9
                       86400  IN  A  192.253.253.9

249.249.192.in-addr.arpa.  86400  IN  NS  toystory.movie.edu.
                           86400  IN  NS  wormhole.movie.edu.
                           86400  IN  NS  zardoz.movie.edu.
253.253.192.in-addr.arpa.  86400  IN  NS  toystory.movie.edu.
                           86400  IN  NS  wormhole.movie.edu.
                           86400  IN  NS  zardoz.movie.edu.
254.253.192.in-addr.arpa.  86400  IN  NS  bladerunner.fx.movie.edu.
                           86400  IN  NS  outland.fx.movie.edu.
                           86400  IN  NS  alien.fx.movie.edu.
20.254.192.in-addr.arpa.   86400  IN  NS  bladerunner.fx.movie.edu.
                           86400  IN  NS  outland.fx.movie.edu.
                           86400  IN  NS  alien.fx.movie.edu.

$TTL 1d
.  IN  SOA  rainman.movie.edu.  hostmaster.movie.edu.  (
            1    ; serial
            3h   ; refresh
            1h   ; retry
            1w   ; expire
            1h ) ; negative caching TTL

   IN  NS  rainman.movie.edu.
   IN  NS  awakenings.movie.edu.

rainman.movie.edu.    IN  A  192.249.249.254
awakenings.movie.edu. IN  A  192.253.253.254

$TTL 1d
.  IN  SOA  rainman.movie.edu.  hostmaster.movie.edu.  (
            1    ; serial
            3h   ; refresh
            1h   ; retry
            1w   ; expire
            1h ) ; negative caching TTL

   IN  NS  rainman.movie.edu.
   IN  NS  awakenings.movie.edu.

rainman.movie.edu.    IN  A  192.249.249.254
awakenings.movie.edu. IN  A  192.253.253.254

movie.edu.  IN  NS  toystory.movie.edu.
            IN  NS  wormhole.movie.edu.
            IN  NS  zardoz.movie.edu.

toystory.movie.edu.    IN  A  192.249.249.3
wormhole.movie.edu.    IN  A  192.249.249.1
                       IN  A  192.253.253.1
zardoz.movie.edu.      IN  A  192.249.249.9
                       IN  A  192.253.253.9

249.249.192.in-addr.arpa.  IN  NS  toystory.movie.edu.
                           IN  NS  wormhole.movie.edu.
                           IN  NS  zardoz.movie.edu.
253.253.192.in-addr.arpa.  IN  NS  toystory.movie.edu.
                           IN  NS  wormhole.movie.edu.
                           IN  NS  zardoz.movie.edu.
254.253.192.in-addr.arpa.  IN  NS  bladerunner.fx.movie.edu.
                           IN  NS  outland.fx.movie.edu.
                           IN  NS  alien.fx.movie.edu.
20.254.192.in-addr.arpa.   IN  NS  bladerunner.fx.movie.edu.
                           IN  NS  outland.fx.movie.edu.
                           IN  NS  alien.fx.movie.edu.

zone "." {
    type master;
    file "db.root";
};

; Internal root hints file, for Movie U. hosts without direct
; Internet connectivity
;
; Don't use this file on a host with Internet connectivity!
;

.  99999999  IN  NS  rainman.movie.edu.
   99999999  IN  NS  awakenings.movie.edu.

rainman.movie.edu.     99999999  IN  A  192.249.249.254
awakenings.movie.edu.  99999999  IN  A  192.253.253.254

*        IN    MX    5 postmanrings2x.movie.edu.
*.edu.   IN    MX    10 postmanrings2x.movie.edu.

%nslookup -type=mx nic.ddn.mil.  Matches the MX record for *
Server:  rainman.movie.edu
Address:  192.249.249.19

nic.ddn.mil
     preference = 5, mail exchanger = postmanrings2x.movie.edu
postmanrings2x.movie.edu    internet address = 192.249.249.20

%nslookup -type=mx vangogh.cs.berkeley.edu.  Matches the MX record for *.edu
Server:  rainman.movie.edu
Address:  192.249.249.19

vangogh.cs.berkeley.edu
     preference = 10, mail exchanger = postmanrings2x.movie.edu
postmanrings2x.movie.edu    internet address = 192.249.249.20

; holygrail.movie.ac.uk is at the other end of our U.K. Internet link
*.uk.    IN    MX    10 holygrail.movie.ac.uk.
holygrail.movie.ac.uk.    IN   A    192.168.76.4

Many organizations would like to advertise different zone data to the Internet than they advertise internally. In most cases, much of the internal zone data is irrelevant to the Internet because of the organization’s Internet firewall. The firewall may not allow direct access to most internal hosts and may also translate internal, unregistered IP addresses into a range of IP addresses registered to the organization. Therefore, the organization might need to trim out irrelevant information from the external view of the zone or change internal addresses to their external equivalents.

Unfortunately, BIND doesn’t support automatic filtering and translation of zone data. Consequently, many organizations manually create what have become known as split namespaces. In a split namespace, the real namespace is available only internally, while a pared-down, translated version of it called the shadow namespace is visible to the Internet.

The shadow namespace contains the name-to-address and address-to-name mappings of only those hosts on your perimeter network (i.e., outside your firewall) or accessible from the Internet through the firewall. The addresses advertised may be the translated equivalents of internal addresses. The shadow namespace may also contain one or more MX records to direct mail from the Internet through the firewall to a mail server.

Since Movie U. has an Internet firewall that greatly limits access from the Internet to the internal network, we elected to create a shadow namespace. For the zone movie.edu, the only information we need to give out is about the domain name movie.edu (an SOA record and a few NS records); the bastion host (postmanrings2x.movie.edu ); our new external nameserver, ns.movie.edu ; and our external web server, www.movie.edu. The address of the external interface on the bastion host is 200.1.4.2, the address of the nameserver is 200.1.4.3, and the address of the web server is 200.1.4.4. The shadow movie.edu zone datafile looks like this:

$TTL 1d
@    IN    SOA    ns.movie.edu.    hostmaster.movie.edu. (
                           1    ; Serial
                           3h   ; Refresh
                           1h   ; Retry
                           1w   ; Expire
                           1h ) ; Negative caching TTL

    IN    NS    ns.movie.edu.
    IN    NS    ns1.isp.net.        ; our ISP's name server is a movie.edu slave

    IN    A     200.1.4.4    ; for people who try to access http://movie.edu
    IN    MX    10 postmanrings2x.movie.edu.
    IN    MX    100 mail.isp.net.

www             IN    A     200.1.4.4

postmanrings2x  IN    A     200.1.4.2
                IN    MX    10 postmanrings2x.movie.edu.
                IN    MX    100 mail.isp.net.

;postmanrings2x.movie.edu handles mail addressed to ns.movie.edu
ns              IN    A     200.1.4.3
                IN    MX    10 postmanrings2x.movie.edu.
                IN    MX    100 mail.isp.net.

*               IN    MX    10 postmanrings2x.movie.edu.
                IN    MX    100 mail.isp.net.

Note that there’s no mention of any of the subdomains of movie.edu, including any delegation to the nameservers for those subdomains. The information simply isn’t necessary because there’s nothing in any of the subdomains that you can get to from the Internet, and inbound mail addressed to hosts in the subdomains is caught by the wildcard.

The db.200.1.4 file, which we need in order to reverse-map the two Movie U. IP addresses that hosts on the Internet might see, looks like this:

$TTL 1d
@    IN    SOA    ns.movie.edu.    hostmaster.movie.edu. (
                           1    ; Serial
                           3h   ; Refresh
                           1h   ; Retry
                           1w   ; Expire
                           1h ) ; Negative caching TTL

    IN    NS    ns.movie.edu.
    IN    NS    ns1.isp.net.

2    IN    PTR    postmanrings2x.movie.edu.
3    IN    PTR    ns.movie.edu.
4    IN    PTR    www.movie.edu.

One precaution we have to take is to make sure that the resolvers on our bastion host, on our mail server, and on our web server aren’t configured to use the server on ns.movie.edu . Since that server can’t see the real, internal movie.edu, using it renders these hosts unable to map internal domain names to addresses or internal addresses to names.

Configuring the bastion host

The bastion host is a special case in a split namespace configuration. It has a foot in each environment: one network interface connects it to the Internet and another connects it to the internal network. Now that we have split our namespace in two, how can our bastion host see both the Internet namespace and our real internal namespace? If we configure it with the Internet’s root nameservers in its root hints file, it will follow delegation from the Internet’s edu nameservers to an external movie.edu nameserver with shadow zone data. It would be blind to our internal namespace, which it needs to see to log connections, deliver inbound mail, and more. On the other hand, if we configure it with our internal roots, it won’t see the Internet’s namespace, which it clearly needs to do in order to function as a bastion host. What to do?

If we have internal nameservers that can resolve both internal and Internet domain names—using forward zones per the configuration earlier in this chapter, for example—we can simply configure the bastion host’s resolver to query those nameservers. But if we use forwarding internally, depending on the type of firewall we’re running, we may also need to run a forwarder on the bastion host itself. If the firewall won’t pass DNS traffic, we’ll need to run at least a caching-only nameserver, configured with the Internet roots, on the bastion host so that our internal nameservers will have somewhere to forward their unresolved queries.

If our internal nameservers don’t support forward zones, the nameserver on our bastion host must be configured as a slave or stub for movie.edu and any in-addr.arpa zones in which it needs to resolve addresses. This way, if it receives a query for a domain name in movie.edu, it uses its local authoritative data to resolve the name (in the case of a slave zone) or follows internal NS records to the authoritative nameservers (for a stub zone). (If our internal nameservers support forward zones and are configured correctly, the nameserver on our bastion host will never receive queries for names in movie.edu.) If the domain name is in a delegated subdomain of movie.edu, it follows NS records that are in the movie.edu zone data or received from a movie.edu nameserver to query an internal nameserver for the name. Therefore, it doesn’t need to be configured as a slave or stub for any movie.edu subdomains, such as fx.movie.edu, just the “topmost” zone (see Figure 11-6).

Figure 11-6. A split DNS solution

The named.conf file on our bastion host looks like this:

options {
    directory "/var/named";
};

zone "movie.edu" {
    type slave;
    masters { 192.249.249.3; };
    file "bak.movie.edu";
};

zone "249.249.192.in-addr.arpa" {
    type slave;
    masters { 192.249.249.3; };
    file "bak.192.249.249";
};

zone "253.253.192.in-addr.arpa" {
    type slave;
    masters { 192.249.249.3; };
    file "bak.192.253.253";
};

zone "254.253.192.in-addr.arpa" {
    type slave;
    masters { 192.253.254.2; };
    file "bak.192.253.254";
};

zone "20.254.192.in-addr.arpa" {
    type slave;
    masters { 192.253.254.2; };
    file "bak.192.254.20";
};

zone "." {
    type hint;
    file "db.cache";
};

options {
    directory "/var/named";
    allow-query { 127/8; 192.249.249/24; 192.253.253/24;
        192.253.254/24; 192.254.20/24; };
};

acl "internal" {
    127/8; 192.249.249/24; 192.253.253/24;
    192.253.254/24; 192.254.20/24;
};

options {
    directory "/var/named";
    allow-query { "internal"; };
    allow-transfer { none; };
};

zone "movie.edu" {
    type slave;
    masters { 192.249.249.3; };
    file "bak.movie.edu";
};

zone "249.249.192.in-addr.arpa" {
    type slave;
    masters { 192.249.249.3; };
    file "bak.192.249.249";
};

zone "253.253.192.in-addr.arpa" {
    type slave;
    masters { 192.249.249.3; };
    file "bak.192.253.253";
};

zone "254.253.192.in-addr.arpa" {
    type slave;
    masters { 192.253.254.2; };
    file "bak.192.253.254";
};

zone "20.254.192.in-addr.arpa" {
    type slave;
    masters { 192.253.254.2; };
    file "bak.192.254.20";
};

zone "." {
    type hint;
    file "db.cache";
};

options {
    directory "/var/named";
};

acl "internal" {
    127/8; 192.249.249/24; 192.253.253/24; 192.253.254/24; 192.254.20/24;
};

view "internal" {
    match-clients { "internal"; };
    recursion yes;

    zone "movie.edu" {
        type slave;
        masters { 192.249.249.3; };
        file "bak.movie.edu";
     };

    zone "249.249.192.in-addr.arpa" {
        type slave;
        masters { 192.249.249.3; };
        file "bak.192.249.249";
    };

    zone "253.253.192.in-addr.arpa" {
        type slave;
        masters { 192.249.249.3; };
        file "bak.192.253.253";
    };

    zone "254.253.192.in-addr.arpa" {
        type slave;
        masters { 192.253.254.2; };
        file "bak.192.253.254";
    };

    zone "20.254.192.in-addr.arpa" {
        type slave;
        masters { 192.253.254.2; };
        file "bak.192.254.20";
    };

    zone "." {
        type hint;
        file "db.cache";
    };
};

acl "ns1.isp.net" { 199.11.28.12; };

view "external" {
    match-clients { any; };
    recursion no;

    zone "movie.edu" {
        type master;
        file "db.movie.edu.external";
        allow-transfer { "ns1.isp.net"; };
    };

    zone "4.1.200.in-addr.arpa" {
        type master;
        file "db.200.1.4";
        allow-transfer { "ns1.isp.net"; };
    };

    zone "." {
        type hint;
        file "db.cache";
    };
};

Public-key cryptography solves the key distribution problem by using asymmetric cryptographic algorithms. In an asymmetric cryptographic algorithm, one key is used to decrypt data that another has encrypted. These two keys—a key pair—are generated at the same time using a mathematical formula. That’s the only easy way to find two keys that have this special asymmetry (one decrypts what the other encrypts): it’s very difficult to determine one key given the other. (In the most popular asymmetric cryptographic algorithm, RSA, that determination involves factoring very large numbers, a notoriously hard problem.)

In public-key cryptography, an individual first generates a key pair. Then, one key of the key pair is made public (e.g., published in a directory), while the other is kept private. Someone who wants to communicate securely with that individual can encrypt a message with the individual’s public key and then send the encrypted message to the individual. (Or he could even post the message to a newsgroup or on a web site.) If the recipient has kept his private key private, only he can decrypt the message.

Conversely, the individual can encrypt a message with his private key and send it to someone. The recipient can verify that it came from that individual by attempting to decrypt it with the individual’s public key. If the message decrypts to something reasonable (i.e., not gibberish), and the sender kept his private key to himself, the individual must have encrypted it. Successful decryption also proves that the message wasn’t modified in transit (e.g., while passing through a mail server), because if it had been, it wouldn’t have decrypted correctly. So the recipient has authenticated the message.

Unfortunately, encrypting large amounts of data with asymmetric encryption algorithms tends to be slow—much slower than encryption using symmetric encryption algorithms. But when using public-key encryption for authentication (and not for privacy), we don’t have to encrypt the whole message. Instead, we run the message through a one-way hash function first. Then we can encrypt just the hash value, which represents the original data. We attach the encrypted hash value, now called a digital signature, to the message we want to authenticate. The recipient can still authenticate the message by decrypting the digital signature and running the message through his own copy of the one-way hash function. If the hash values match, the message is authentic. We call the process of computing the hash value and encrypting it signing, and the process of validating the digital signature verifying. The process of signing and verifying a message is shown in Figure 11-7.

Figure 11-7. Signing and verifying a message

In the DNS Security Extensions, each signed zone has a key pair associated with it. The zone’s private key is stored somewhere safe, often in a file on the primary nameserver’s filesystem. The zone’s public key is advertised as a new type of record attached to the domain name of the zone, the DNSKEY record.

The previous version included a general-purpose KEY record: you could use the record to store different kinds of cryptographic keys, not just zones’ public keys for use with DNSSEC. However, the revised DNSSEC uses the DNSKEY record only to store a zone’s public key.

A DNSKEY record looks like this:

movie.edu. IN DNSKEY 257 3 5 AQPWA4BRyjB3eqYNy/oykeGcSXjl+HQK9CciAxJfMcS1vEuwz9c
+QG7s EJnQuH5B9i5o/ja+DVitY3jpXNa12mEn

The owner is the domain name of the zone that owns this public key. The first field after the type, 257, is the flags field. The flags field is two bytes long and encodes a set of two one-bit values:

  0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|                           |ZK |                           |SEP|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

The first seven bits (0 through 6) and bits 8 through 14 are reserved and must have a value of 0.

The eighth bit encodes the type of key:

The last bit (15) is the Secure Entry Point (SEP) flag, which has an experimental use documented in RFC 3757. We’ll discuss it in more detail later in the chapter.

In the DNSKEY record shown earlier, the flags field (the first field in the record after the type) says that this DNSKEY is movie.edu’s zone key.

The next field in the record, which in the example has the value 3, is called the protocol field. This is a holdover from the older version of DNSSEC, when you could use KEY records for different purposes. In the current version of DNSSEC, however, you can use DNSKEY records only with DNSSEC, so this field is always set to 3, which historically indicated a DNSSEC key.

The next (third) field in the DNSKEY record, which here has the value 5, is the algorithm field. DNSSEC can work with a number of public-key encryption algorithms, so you need to identify which algorithm a zone uses and which algorithm this key is used with here. The following values are defined:

We’ll use RSA/SHA-1 keys in our examples, naturally.

The final field in the DNSKEY record is the public key itself, encoded in base 64. DNSSEC supports keys of many lengths, as we’ll see shortly when we generate the movie.edu public key. The longer the key, the more secure (because it’s harder to find the corresponding private key), but the longer it takes to sign zone data with the private key and verify it with the public key, and the longer the DNSKEY record and signatures created.

If the DNSKEY record stores a zone’s public key, then there must be a new record to store the corresponding private key’s signature, right? Sure enough, that’s the RRSIG record. The RRSIG record stores the private key’s digital signature on an RRset. An RRset is a group of resource records with the same owner, class, and type; for example, all of wormhole.movie.edu ’s address records make up an RRset. Likewise, all of movie.edu’s MX records are another RRset.

Why sign RRsets rather than individual records? It saves time. There’s no way to look up just one of wormhole.movie.edu ’s address records; a nameserver will always return them as a group. So why go to the trouble of signing each one individually when you can sign them together?

Here’s the RRSIG record that “covers” wormhole.movie.edu ’s address records:

wormhole.movie.edu.        86400   RRSIG   A 5 3 86400 20060219233605 (
                                        20060120233605 3674 movie.edu.
                                        ZZP9AV28r824SZJqyIT+3WKkMQgcu1YTuFzp
                                        LgU3EN4USgpJhLZbYBqTHL77mipET5aJr8Od
                                        RxZvfFHHYV6UGw== )

The owner name is wormhole.movie.edu , the same as the owner of the records signed. The first field after the type, which holds the value A, is called the type covered. That tells us which of wormhole.movie.edu ’s records were signed—in this case, its address records. There would be a separate RRSIG record for each type of record wormhole.movie.edu might own.

The second field, which has the value 5, is the algorithm field. This is one of the same values used in the DNSKEY record’s algorithm field, so 5 means RSA/SHA-1. If you generate an RSA/SHA-1 key and use it to sign your zone, you’ll get RSA/SHA-1 signatures, naturally. If you sign your zone with multiple types of keys, say an RSA/SHA-1 key and a DSA key, you’ll end up with two RRSIG records for each RRset, one with an algorithm number of 5 (RSA/SHA-1) and one with an algorithm number of 3 (DSA).^[*]

The third field is called the labels field. It indicates how many labels there are in the owner name of the records signed. wormhole.movie.edu obviously has three labels, so the labels field contains 3. When would the labels field ever differ from the number of labels in the RRSIG’s owner? When the RRSIG record covered a wildcard record of some type. We won’t cover the nuances of wildcards in signed zones in this book.

The fourth field is the original TTL on the records in the RRset that was signed. (All the records in an RRset are supposed to have the same TTL.) The TTL needs to be stored here because a nameserver caching the RRset that this RRSIG record covers will decrement the TTLs on the cached records. Without the original TTL, it’s impossible to reconstruct the original address records to feed them through the one-way hash function to verify the digital signature.

The next two fields are the signature expiration and inception fields, respectively. They’re both stored as an unsigned integer number of seconds since the Unix epoch, January 1, 1970, but in the RRSIG record’s text representation, they’re presented in the format YYYYMMDDHHMMSS for convenience. (The signature expiration time for the RRSIG record we showed you earlier is just after 11:36 p.m. on February 19, 2006.) The signature inception time is usually the time you ran the program to sign your zone. You choose the signature expiration time when you run that program, too. After the signature’s expiration, the RRSIG record is no longer valid and can’t be used to verify the RRset. Bummer. This means you have to re-sign your zone data periodically to keep the signatures valid. Fun. Thankfully, re-signing takes much less work than signing it for the first time.

The next (seventh) field in the RRSIG record, which in this record contains 3674, is the key tag field. The key tag is a fingerprint derived from the public key that corresponds to the private key that signed the zone. If the zone has more than one public key (and yours probably will), DNSSEC verification software uses the key tag to determine which key to use to verify this signature.

The eighth field, which contains movie.edu, is the signer’s name field. As you’d expect, it’s the domain name of the public key that a verifier should use to check the signature. It, together with the key tag, identifies the DNSKEY record to use. The signer’s name field is always the domain name of the zone the signed records are in.

The final field is the signature field. This is the digital signature of the zone’s private key on the signed records and the right side of the RRSIG record itself, minus this field. Like the key in the DNSKEY record, this signature is encoded in base 64.

DNSSEC introduces another new record type: the NSEC record. We’ll explain what it’s for.

What happens if you look up a domain name that doesn’t exist in a signed zone? If the zone weren’t signed, the nameserver would simply respond with the “no such domain name” response code. But how do you sign a response code? If you signed the whole response message, it would be difficult to cache. You need something unique to sign, something that proves that the domain name you looked up doesn’t exist.

The NSEC record solves the problem of signing negative responses. It spans a gap between two consecutive domain names in a zone, telling you which domain name comes next after a given domain name—hence the name of the record: “Next SECure.”

But doesn’t the notion of “consecutive domain names” imply a canonical order to the domain names in a zone? Why, yes, it does.

To order the domain names in a zone, you begin by sorting by the rightmost label in those domain names, then by the next label to the left, and so on. Labels are sorted case-insensitively and lexicographically (by dictionary order), with numbers coming before letters and nonexistent labels before numbers (in other words, movie.edu would come before 0.movie.edu ). So the domain names in movie.edu sort to the following:

movie.edu
carrie.movie.edu
cujo.movie.edu
fx.movie.edu
bladerunner.fx.movie.edu
outland.fx.movie.edu
horror.movie.edu
localhost.movie.edu
mi.movie.edu
misery.movie.edu
monsters-inc.movie.edu
shining.movie.edu
shrek.movie.edu
toys.movie.edu
toystory.movie.edu
wh.movie.edu
wh249.movie.edu
wh253.movie.edu
wormhole.movie.edu

Notice that just as movie.edu comes before carrie.movie.edu , fx.movie.edu precedes bladerunner.fx.movie.edu .

Once the zone is in canonical order, the NSEC records make sense. Here’s one NSEC record (the first, in fact) from movie.edu:

movie.edu.                     NSEC     carrie.movie.edu. NS SOA MX RRSIG NSEC DNSKEY

This record says that the next domain name in the zone after movie.edu is carrie.movie.edu , which we can see from our sorted list of domain names. It also says that movie.edu has NS records, an SOA record, MX records, RRSIG records, an NSEC record, and a DNSKEY record.

The last NSEC record in a zone is special. Since there’s really no next domain name after the last one, the last NSEC record wraps around to the first record in the zone:

wormhole.movie.edu.            NSEC     movie.edu. A RRSIG NSEC

In other words, to indicate that wormhole.movie.edu is the last domain name in the zone, we say that the next domain name is movie.edu, the first domain name in the zone. Call it circular logic.

So how do NSEC records provide authenticated negative responses? Well, if you look up www.movie.edu internally, you get back the wormhole.movie.edu NSEC record, telling you that there’s no www.movie.edu because there are no domain names in the zone after wormhole.movie.edu . Similarly, if you try to look up TXT records for movie.edu, you get the first NSEC record we showed you, which tells you there are no TXT records for movie.edu, just NS, SOA, MX, RRSIG, NSEC, and DNSKEY records.

An RRSIG record covering the NSEC record accompanies it in the response, authenticating the nonexistence of the domain name or type of data you asked for.

It’s important that the NSEC records, in toto, identify specifically what doesn’t exist in the zone. A single catch-all record that simply says “That doesn’t exist” could be sniffed off the wire and replayed to claim falsely that existing domain names or records don’t actually exist.

For those of you worried about the prospects of adding these new records to your zone and keeping them up to date manually—“Uh-oh, now that I’ve added a host, I’ve got to adjust my NSEC records”—take heart: BIND provides a tool to add NSEC and RRSIG records for you automatically.

Some of you may also worry about the information NSEC records reveal about your zone. A hacker could, for example, look up the NSEC record attached to the domain name of your zone to find the record types attached to that domain name and the lexicographically next domain name, then repeat the process to learn all the domain names and RRsets in the zone. That, unfortunately, is an unavoidable side effect of signing your zone. Just repeat this mantra: “My zone data is secure, but public.”

There’s one more aspect of DNSSEC theory that we should discuss: the chain of trust. (No, this isn’t some touchy-feely team-building exercise.) So far, each RRset in our signed zone has an RRSIG record associated with it. To let others verify those RRSIG records, our zone advertises its public key to the world in a DNSKEY record. But imagine if someone breaks into our primary nameserver. What’s to keep her from generating her own key pair? Then she could modify our zone data, resign our zone with her newly generated private key, and advertise her newly generated public key in a DNSKEY record.

To combat this problem, our public key is “certified” by a higher authority. This higher authority attests to the fact that the movie.edu public key in our DNSKEY record really belongs to the organization that owns and runs the zone, and not to some random yahoo. Before certifying us, this higher authority demanded some sort of proof that we were who we said we were and that we were the duly authorized administrators of movie.edu.

This higher authority is our parent zone, edu. When we generated our key pair and signed our zone, we also sent our public key to the administrators of edu, along with proof of our identity and of our positions as the Two True Administrators of movie.edu.^[*] They indicated their approval of our credentials and of our public key by inserting a DS record to the edu zone, then signing the record with their private key. Here are the resulting records:

movie.edu.              86400   DS      15480 5 1 (
                                        F340F3A05DB4D081B6D3D749F300636DCE3D
                                        6C17 )
                        86400   RRSIG   DS 5 2 86400 20060219234934 (
                                        20060120234934 23912 edu.
                                        Nw4xLOhtFoP0cE6ECIC8GgpJKtGWstzk0uH6
                                        nd2cz28/24j4kz1Ahznr/+g5oU3AADyv86EK
                                        CnWZtyOeqnfhMZ3UW0yyPcF3wy73tYLQ/KjN
                                        gPm1VPQA/Sl3smauJsFW7/YPaoQuxcnREPWf
                                        YWInWvWx12IiPKfkVU3F0EbosBA= )

DS stands for delegation signer. The DS record identifies the public key authorized to sign the movie.edu zone’s data. The first field after the type is a key tag, as in the RRSIG record, that helps identify the DNSKEY record authorized to do the signing. The second field is another algorithm field, as in both the DNSKEY and RRSIG records, also used to help identify the relevant DNSKEY record in case we used multiple cryptographic algorithms. The third field is the digest type field, which tells a verifier which digest mechanism to use to verify the digest, the final field. The only currently supported digest type is 1, for an SHA-1 digest. The digest is a 20-byte, hexadecimal-encoded, one-way hash of the movie.edu DNSKEY record.^[*]

Accompanying the DS record is an RRSIG record, showing that the administrators of the edu zone signed the movie.edu DS record, thereby vouching for it.

When following a referral from the edu nameservers to the movie.edu servers and verifying the movie.edu DNSKEY record, a nameserver first verifies the RRSIG record covering the DS record. Assuming the RRSIG verified, the nameserver looks up DNSKEY records attached to movie.edu and looks for one matching the key tag and algorithm listed in the DS record. Once the correct DNSKEY record was identified, the nameserver runs the record through the one-way hash algorithm and checks whether the digest matches the digest from the DS record. If it does, the DNSKEY record is authentic, and the nameserver can use it to verify the RRSIG record covering the DNSKEY RRset or other RRsets signed by the corresponding private key.

What if someone breaks into the edu zone’s primary nameserver? The edu zone’s DNSKEY record is certified by a DS record in the root zone, so they can’t simply replace it or any data signed by it. And the root zone? Well, the root zone’s public key is very widely known and configured on every nameserver that supports DNSSEC.^[†]

That is, the root zone’s public key will be configured on every nameserver once DNSSEC is widely implemented. Right now, neither the root zone nor the edu zone is signed, and neither has a key pair. Until DNSSEC is widely implemented, though, it’s possible to use DNSSEC piecemeal.

trusted-keys {
    movie.edu. 257 3 5 "AQPWA4BRyjB3eqYNy/oykeGcSXjl+HQK9CciAxJfMcS1vEuwz9c
+QG7s EJnQuH5B9i5o/ja+DVitY3jpXNa12mEn";
};

trusted-keys {
    movie.edu. 257 3 5 "AQPWA4BRyjB3eqYNy/oykeGcSXjl+HQK9CciAxJfMcS1vEuwz9c
+QG7s EJnQuH5B9i5o/ja+DVitY3jpXNa12mEn";
    movie.edu. 257 3 3 "AMnD8GXACuJ5GVnfCJWmRydg2A6JptSm6tjH7QoL81SfBY/kcz1Nbe
    Hh z4l9AT1GG2kAZjGLjH07BZHY+joz6iYMPRCDaPOIt9LO+SRfBNZg62P4 aSPT5zVQPahDIMZmTIvv
    O7FV6IaTV+cQiKQl6noro8uTk4asCADrAHw0 iVjzjaYpoFF5AsB0cJU18fzDiCNBUb0VqE1mKFuRA/K
    1KyxM2vJ3U7IS to0IgACiCfHkYK5r3qFbMvF1GrjyVwfwCC4NcMsqEXIT8IEI/YYIgFt4 Ennh";
};

You’ve now seen examples of the four new DNSSEC record types, so you know how long they can be. But the classical limit on the length of a UDP-based DNS message is just 512 bytes. Including all those RRSIGs would cause a lot of truncated responses.

To cope with this, DNSSEC requires support for EDNS0, which we introduced in Chapter 10. EDNS0 allows the use of UDP-based DNS messages as long as 4,096 bytes. DNSSEC also uses a new EDNS0 flag, called the DO flag, for DNSSEC OK, as an indication that a querier supports DNSSEC and wants DNSSEC-related records in the response. Through this use of the DO flag, nameservers don’t needlessly include a bunch of useless records in responses to queriers that don’t support DNSSEC.

DNSSEC uses two other flags in queries: AD and CD. Both are part of the standard DNS query header; they were allocated from previously unused space.^[*]

AD stands for Authenticated Data. It’s set by DNSSEC-capable nameservers in responses only if they’ve verified all the DNSSEC-related records included in the message. A nameserver returning any records that failed to verify, or simply weren’t from a signed zone, would clear the AD bit.

The AD bit is designed to allow resolvers that query a nameserver that supports DNSSEC but can’t themselves verify DNSSEC records to determine whether a response has been validated. However, these resolvers should only trust the setting of the AD bit if their communications channel to the nameserver is secure—using IPSEC or TSIG, for example.

The CD bit, on the other hand, is meant for use by resolvers that can verify DNSSEC records. CD, which is an abbreviation for Checking Disabled, tells the nameserver not to bother verifying DNSSEC records on the resolver’s behalf because it can handle the job itself.

Let’s go through what a DNSSEC-capable nameserver does to verify a record in movie.edu. In particular, let’s see what happens when it looks up the address of wormhole.movie.edu . We’ll use dig, since we can’t set the DO bit with nslookup.

First, of course, the nameserver sends a query for the address:

%dig +dnssec +norec wormhole.movie.edu.

; <<>> DiG 9.3.2 <<>> +dnssec +norec wormhole.movie.edu.
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32579
;; flags: qr aa ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;wormhole.movie.edu.            IN      A

;; ANSWER SECTION:
wormhole.movie.edu.     86400   IN      A       192.253.253.1
wormhole.movie.edu.     86400   IN      A       192.249.249.1
wormhole.movie.edu.     86400   IN      RRSIG   A 5 3 86400
20060219233605 20060120233605 3674 movie.edu. ZZP9AV28r824SZJqyIT+
3WKkMQgcu1YTuFzpLgU3EN4USgpJhLZbYBqT HL77mipET5aJr8OdRxZvfFHHYV6UGw==

;; AUTHORITY SECTION:
movie.edu.              86400   IN      NS      outland.fx.movie.edu.
movie.edu.              86400   IN      NS      wormhole.movie.edu.
movie.edu.              86400   IN      NS      toystory.movie.edu.
movie.edu.              86400   IN      RRSIG   NS 5 2 86400
20060219233605 20060120233605 3674 movie.edu. bwiM/R56VVV0pHrzIERVADLat7BoTR+eeFuCfgYc/
GMXecdTxnUahLig RKsbNSsY+Uz8RVkcewFSiExExFoqwA==

;; ADDITIONAL SECTION:
toystory.movie.edu.     86400   IN      A       192.249.249.3
toystory.movie.edu.   86400   IN      RRSIG   A 5 3 86400 20060219233605
20060120233605 3674 movie.edu. hlz+W41UlcfIaCMdzoKVAuTPjnyqZhxY3TKOOm/
2i7FPAkfnVyWMyTwG iBns7Z1ws6QVj7+ZedDFx7xs+V0Iyw==

;; Query time: 13 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 20 16:52:54 2006
;; MSG SIZE  rcvd: 474

Notice that we had to specify +dnssec on the command line. That sets the DO flag we just described, telling the nameserver to include DNSSEC records in the response. You can see that the DO flag is set in dig’s output: look for the line that begins with ; EDNS:. The flags show that DO was set, and that the maximum UDP message size was negotiated to a full 4,096 bytes.

Also notice that the response includes three RRSIG records: one covering the records in the answer section, one covering the records in the authority section, and one covering toystory.movie.edu ’s address record in the additional section.

To verify the RRSIG records, the nameserver must look up movie.edu’s DNSKEY record. But before using the key, it must verify the key—unless, of course, the nameserver has previously verified it or knows the movie.edu public key from a trusted-keys statement. Verifying the key may require additional queries: one to an edu nameserver for the movie.edu DS record and the RRSIG records covering it, and possibly a query to a root nameserver for the edu DS record and its associated RRSIG records.

It should be evident from this dig output that DNSSEC increases the average size of a DNS message; that it requires substantially more computational horsepower from nameservers verifying zone data; that verification can entail several successive queries, each of which may result in additional data that requires verifying; and that signing a zone increases its size substantially—current estimates are that signing multiplies the size of a zone by a factor of three to four. Each effect has its consequences:

In fact, DNSSEC’s complexity meant that BIND 8’s architecture couldn’t support DNSSEC completely. DNSSEC also provided part of the impetus for developing BIND 9 and for ensuring it supported multiprocessor hosts. If you’re planning on signing your zones, make sure your authoritative nameservers have enough memory to load the new, larger zones. If your nameservers are resolving more records in signed zones, make sure they have enough processor power to verify all those digital signatures.

In practice, administrators are expected to use two types of keys per zone: zone-signing keys (ZSKs) and key-signing keys (KSKs). An administrator signs his zone data with the zone-signing key (duh) and publishes the corresponding public key in a DNSKEY record. The key-signing key also appears in the DNSKEY records, and the administrator uses the private key-signing key to sign just the DNSKEY records.

The SPE flag in the DNSKEY record serves as a hint to software to determine which of a zone’s DNSKEY records corresponds to the key-signing key (the one with the SEP flag set). When we generate our key pair, we’ll specify which one is the key-signing key.

Why bother with two keys for a zone? Cryptography wonks know that the more data encrypted using a cryptographic key, the greater the danger that someone will crack it. In the case of public-key cryptography, that means determining the corresponding private key. Zone-signing keys are used all the time: every time you modify your zone, you re-sign it. With a large zone, there’s lots of available encrypted data subject to cryptanalysis. Consequently, you must generate new zone-signing keys frequently. If that entails resubmitting your DNSKEY record to your parent zone’s administrators, having them replace your zone’s DS record and re-signing it, that’ll take a lot of time and effort. Using separate zone-signing and key-signing keys allows you to re-sign your zone data without involving your parent zone’s administrators. You’ll only need to contact them if you rotate your key-signing key, which doesn’t need to be done as often because it isn’t used to encrypt much data (just enough to produce an RRSIG for the DNSSEC RRset).

Okay, now you have the theoretical background you need to actually sign your zone. We’ll show you how we signed movie.edu. Remember, we used the BIND 9.3.2 tools, which support the newest version of DNSSEC.

#cd /var/named
# dnssec-keygen -f KSK -a RSASHA1 -b 512 -n ZONE movie.edu.
Kmovie.edu.+005+15480

#dnssec-keygen -a RSASHA1 -b 512 -n ZONE movie.edu.
Kmovie.edu.+005+03674

# echo "$INCLUDE Kmovie.edu.+005+15480.key" >> db.movie.edu
# echo "$INCLUDE Kmovie.edu.+005+03674.key" >> db.movie.edu

#dnssec-signzone -o movie.edu. db.movie.edu
db.movie.edu.signed

; File written on Fri Jan 20 16:36:05 2006
; dnssec_signzone version 9.3.2
movie.edu.              86400   IN SOA  toystory.movie.edu. al.movie.edu. (
                                        2006011700 ; serial
                                        10800      ; refresh (3 hours)
                                        3600       ; retry (1 hour)
                                        604800     ; expire (1 week)
                                        3600       ; minimum (1 hour)
                                        )
                        86400   RRSIG   SOA 5 2 86400 20060219233605 (
                                        20060120233605 3674 movie.edu.
                                        joujDnvBovW1h+GJ2ZEhvmXQTGqVL4cZBCHM
                                        ByFitPRLINe/dKj8VCZg87ZUHQ/eAZSSGDuw
                                        XVIlT46ByG5AOg== )
                        86400   NS      outland.fx.movie.edu.
                        86400   NS      wormhole.movie.edu.
                        86400   NS      toystory.movie.edu.
                        86400   RRSIG   NS 5 2 86400 20060219233605 (
                                        20060120233605 3674 movie.edu.
                                        bwiM/R56VVV0pHrzIERVADLat7BoTR+eeFuC
                                        fgYc/GMXecdTxnUahLigRKsbNSsY+Uz8RVkc
                                        ewFSiExExFoqwA== )
                        86400   MX      10 postmanrings2x.movie.edu.
                        86400   RRSIG   MX 5 2 86400 20060219233605 (
                                        20060120233605 3674 movie.edu.
                                        rm7R0Ib451iK49+bRhch4pIP11F4xZMWtqll
                                        8rQ9tKIOg+jTunNXxix5XnyVKoMQwoa8C5Tu
                                        ZFeDcbHN0UB5ow== )
                        3600    NSEC    misery.movie.edu. NS SOA MX RRSIG NSEC DNSKEY
                        3600    RRSIG   NSEC 5 2 3600 20060219233605 (
                                        20060120233605 3674 movie.edu.
                                        V4ipZI5SHGdFNOVEFn43gsRdYffUH6COrPxn
                                        RNfUMv6gfgwkythXXr5rx0NTOSfa+Dp4CZrC
                                        qwn+CLryUN8vZg== )
                        86400   DNSKEY  256 3 5 (
                                        AQO/T4DRCAbi1diCB+UT4fDOeCvsa+1NKkO8
                                        UJMF5TlfRvokChybhHaDG5U98xw4XgA01/4R
                                        gSlAcSDvhQeKu9n9
                                        ) ; key id = 3674
                        86400   DNSKEY  257 3 5 (
                                        AQPWA4BRyjB3eqYNy/oykeGcSXjl+HQK9Cci
                                        AxJfMcS1vEuwz9c+QG7sEJnQuH5B9i5o/ja+
                                        DVitY3jpXNa12mEn
                                        ) ; key id = 15480
                        86400   RRSIG   DNSKEY 5 2 86400 20060219233605 (
                                        20060120233605 3674 movie.edu.
                                        b35F2azzAY6QDghak0RqJzPacmAhcsw3lDoA
                                        zKCFPQRnqVpwl4l7tAgKw2T1Cy9GPmdHMTBx
                                        fo0DB2smQQJjog== )
                        86400   RRSIG   DNSKEY 5 2 86400 20060219233605 (
                                        20060120233605 15480 movie.edu.
                                        J267HbxKdzGq6iIKywZT6xOFQY7Ev1JWYWEc
                                        PKRyZLY2WQ9S3ro0rIUGJRIhHS5oBtzN1g0K
                                        3DL2edi1Hgy+0A== )

options 
 {
    directory "/var/named";
    dnssec-enable yes;
};

zone "movie.edu" {
    type master;
    file "db.movie.edu.signed";
};

#dnssec-signzone -o movie.edu -f db.movie.edu.signed.new db.movie.edu.signed
# mv db.movie.edu.signed db.movie.edu.signed.bak
# mv db.movie.edu.signed.new db.movie.edu.signed
# rndc reload movie.edu

$ORIGIN .
movie.edu               3600    IN DNSKEY 257 3 5 (
                                        AQPWA4BRyjB3eqYNy/oykeGcSXjl+HQK9Cci
                                        AxJfMcS1vEuwz9c+QG7sEJnQuH5B9i5o/ja+
                                        DVitY3jpXNa12mEn
                                        ) ; key id = 15480

movie.edu.              IN DS 15480 5 1 F340F3A05DB4D081B6D3D749F300636DCE3D6C17

movie.edu.              86400   IN NS   outland.fx.movie.edu.
                        86400   IN NS   wormhole.movie.edu.
                        86400   IN NS   toystory.movie.edu.
                        86400   DS      15480 5 1 (
                                        F340F3A05DB4D081B6D3D749F300636DCE3D
                                        6C17 )
                        86400   RRSIG   DS 5 2 86400 20060219234934 (
                                        20060120234934 23912 edu.
                                        Nw4xLOhtFoP0cE6ECIC8GgpJKtGWstzk0uH6
                                        nd2cz28/24j4kz1Ahznr/+g5oU3AADyv86EK
                                        CnWZtyOeqnfhMZ3UW0yyPcF3wy73tYLQ/KjN
                                        gPm1VPQA/Sl3smauJsFW7/YPaoQuxcnREPWf
                                        YWInWvWx12IiPKfkVU3F0EbosBA= )
                        86400   NSEC    edu. NS DS RRSIG NSEC
                        86400   RRSIG   NSEC 5 2 86400 20060219234934 (
                                        20060120234934 23912 edu.
                                        LpOmh/SZMonQUBUil5MYfIrxld5g6pVeyTxl
                                        deDvJ7OIMdI+X0vXmRI3RgmKaRJKYBr4BcNO
                                        jrNU8fQo5Ox5WvEeKn1St1NvdB62/Nqjfz6F
                                        I+LNXe6diq1uDZZUB3hx5PF+Flp28D75KHnZ
                                        5YE9+vVJryOHHsGawklSrUAJAUg= )

fx.movie.edu.           86400   IN NS   alien.fx.movie.edu.
                        86400   IN NS   outland.fx.movie.edu.
                        86400   IN NS   bladerunner.fx.movie.edu.
                        3600    NSEC    misery.movie.edu. NS RRSIG NSEC
                        3600    RRSIG   NSEC 5 3 3600 20060220215231 (
                                        20060121215231 3674 movie.edu.
                                        maFMyIVEdjg5BUTKMUyCZvBu6ZrtrQwJyJRo
                                        9A9PDO3bTpWcpCAp4Q0cQ5FwQcveIq15LMit
                                        CWyOwN745dJ86Q== )
alien.fx.movie.edu.     86400   IN A    192.254.20.3
bladerunner.fx.movie.edu. 86400 IN A    192.253.254.2
outland.fx.movie.edu.   86400   IN A    192.253.254.3

fx.movie.edu.           86400   IN NS   alien.fx.movie.edu.
                        86400   IN NS   outland.fx.movie.edu.
                        86400   IN NS   bladerunner.fx.movie.edu.
                        86400   DS      2847 5 1 (
                                        F495606120C4927FB4BEB04D0C354BBE5ED8
                                        CA31 )
                        86400   RRSIG   DS 5 3 86400 20060220230640 (
                                        20060121230640 3674 movie.edu.
                                        OuZCLrqLZlaEgePAxzhUCneV6FyOq6hQwRWF
                                        4bsHPrvIrLMIuftxfB8M3mmgkKlpOlJIJFvH
                                        Qc4RUfYOGkMkdg== )
                        3600    NSEC    misery.movie.edu. NS DS RRSIG NSEC
                        3600    RRSIG   NSEC 5 3 3600 20060220230640 (
                                        20060121230640 3674 movie.edu.
                                        TUTCnZFvr0YqCD7H0OMTxRs3kAb5OkR74YP3
                                        ZxaBN9S0XxokkeUwHIlWq4JxFJrlZJjMaamp
                                        uKf+WSgdF+v3iA== )

dnssec-signzone isn’t the only way to sign zone data. The BIND 9 nameserver is capable of signing dynamically updated records on the fly.^[*] Color us impressed!

As long as the private key for a secure zone is available in the nameserver’s working directory (in the correctly named .private file), a BIND 9 nameserver signs any records that are added via dynamic update. If any records are added to or deleted from the zone, the nameserver adjusts (and re-signs) the neighboring NSEC records, too.

Let’s show you this in action. First, we’ll look up a domain name that doesn’t yet exist in movie.edu:

%dig +dnssec perfectstorm.movie.edu.

; <<>> DiG 9.3.2 <<>> +dnssec perfectstorm.movie.edu.
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47491
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;perfectstorm.movie.edu.                IN      A

;; AUTHORITY SECTION:
movie.edu.              3600    IN      SOA     toystory.movie.edu.
al.movie.edu. 2006011700 10800 3600 604800 3600
movie.edu.              3600    IN      RRSIG   SOA 5 2 86400 20060219233605
20060120233605 3674 movie.edu. joujDnvBovW1h+GJ2ZEhvmXQTGqVL4cZBCHMByFitPRLINe/
dKj8VCZg 87ZUHQ/eAZSSGDuwXVIlT46ByG5AOg==
movie.edu.              3600    IN      NSEC    misery.movie.edu. NS SOA MX
RRSIG NSEC DNSKEY
movie.edu.              3600    IN      RRSIG   NSEC 5 2 3600
20060219233605 20060120233605 3674 movie.edu.
V4ipZI5SHGdFNOVEFn43gsRdYffUH6COrPxnRNfUMv6gfgwkythXXr5r
x0NTOSfa+Dp4CZrCqwn+CLryUN8vZg==
misery.movie.edu.       3600    IN      NSEC    monsters-inc.movie.edu. A RRSIG NSEC
misery.movie.edu.       3600    IN      RRSIG   NSEC 5 3 3600
20060219233605 20060120233605 3674 movie.edu.
AFTF8DBjDtIzM/QkEajY4lUkbuEyDM5yt/Kpe++Jrp1K1kArUSdGPuxj
xDZUXujbRzPY6JoAOgBO4bU8UDx2tA==

;; Query time: 16 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 20 17:02:51 2006
;; MSG SIZE  rcvd: 502

Notice misery.movie.edu’s NSEC record, indicating that the domain name doesn’t exist. Now we’ll use nsupdate to add an address record for perfectstorm.movie.edu:

%nsupdate
> update add perfectstorm.movie.edu. 3600 IN A 192.249.249.91
> send

Now let’s look up perfectstorm.movie.edu again:

%dig +dnssec perfectstorm.movie.edu.

; <<>> DiG 9.3.2 <<>> +dnssec perfectstorm.movie.edu.
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52846
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 6

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;perfectstorm.movie.edu.        IN      A

;; ANSWER SECTION:
perfectstorm.movie.edu. 3600    IN      A       192.249.249.91
perfectstorm.movie.edu. 3600    IN      RRSIG   A 5 3 3600
20060220010558 20060121000558 3674 movie.edu.
Fdp9EwdP6ze2siolli7wtYRgZdts+A+HTt5g8uqsgBavMml3TKFe+ba3
ppXvFosGHD7j3i6r1rfYUBF+aupEnQ==
perfectstorm.movie.edu. 3600    IN      RRSIG   A 5 3 3600 20060220010558
20060121000558 15480 movie.edu.
o46m/V762W90HqZ1R5mCTFSBYagjCqgpuIwflg/06QvX9Ce67WSoHD3/
YjSh5oag5eSmAAn2iozZYVCLSoIzjA==

;; AUTHORITY SECTION:
movie.edu.              86400   IN      NS      outland.fx.movie.edu.
movie.edu.              86400   IN      NS      wormhole.movie.edu.
movie.edu.              86400   IN      NS      toystory.movie.edu.
movie.edu.              86400   IN      RRSIG   NS 5 2 86400
20060219233605 20060120233605 3674 movie.edu.
bwiM/R56VVV0pHrzIERVADLat7BoTR+eeFuCfgYc/GMXecdTxnUahLig RKsbNSsY+Uz8RVkcewFSiExExFoqwA==

;; ADDITIONAL SECTION:
wormhole.movie.edu.     86400   IN      A       192.253.253.1
wormhole.movie.edu.     86400   IN      A       192.249.249.1
toystory.movie.edu.     86400   IN      A       192.249.249.3
wormhole.movie.edu.     86400   IN      RRSIG   A 5 3 86400 20060219233605
20060120233605 3674 movie.edu. ZZP9AV28r824SZJqyIT+
3WKkMQgcu1YTuFzpLgU3EN4USgpJhLZbYBqT HL77mipET5aJr8OdRxZvfFHHYV6UGw==
toystory.movie.edu.   86400     IN      RRSIG   A 5 3 86400 20060219233605
20060120233605 3674 movie.edu. hlz+W41UlcfIaCMdzoKVAuTPjnyqZhxY3TKOOm/
2i7FPAkfnVyWMyTwG iBns7Z1ws6QVj7+ZedDFx7xs+V0Iyw==

;; Query time: 18 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 20 17:06:22 2006
;; MSG SIZE  rcvd: 713

Not only was an address record added, but there is also an RRSIG record generated from movie.edu’s ZSK.^[*] The signature expiration is set to 30 days from the update by default, but you can change it with the sig-validity-interval substatement, which takes a number of days as an argument:^[†]

options {
    sig-validity-interval 7;  // We want RRSIGs on updated records to last a week
};

The signature inception is always set to one hour before the update to allow for verifiers with clocks that may be slightly skewed from ours.

If we look up perfectstorm2.movie.edu (though how there’d be a sequel to that movie I don’t know), we find the following:

%dig +dnssec perfectstorm2.movie.edu.

; <<>> DiG 9.3.2 <<>> +dnssec perfectstorm2.movie.edu.
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8402
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;perfectstorm2.movie.edu.       IN      A

;; AUTHORITY SECTION:
movie.edu.              3600    IN      SOA     toystory.movie.edu.
al.movie.edu. 2006011701 10800 3600 604800 3600
movie.edu.              3600    IN      RRSIG   SOA 5 2 86400 20060220010558
20060121000558 3674 movie.edu. vwiC+
zBzw8VFmrmFnARkNPLLmYEbSJRCiCsqjnvwVc5CMSzXu6kBkatN bWE9Iqd//brLiOA3E9G02BM3j+5Wkg==
movie.edu.              3600    IN      RRSIG   SOA 5 2 86400 20060220010558
20060121000558 15480 movie.edu. HVlniwE8N8Fy+IdRSmTLw3XTVyLae0eOr26C5MAkzNoMr3OzRrDfbZUm
4+N1a6gC9P+EMzUYM1yflVQFs3Cehg==
movie.edu.              3600    IN      NSEC    misery.movie.edu. NS SOA
MX RRSIG NSEC DNSKEY
movie.edu.              3600    IN      RRSIG   NSEC 5 2 3600
20060219233605 20060120233605 3674 movie.edu.
V4ipZI5SHGdFNOVEFn43gsRdYffUH6COrPxnRNfUMv6gfgwkythXXr5r
x0NTOSfa+Dp4CZrCqwn+CLryUN8vZg==
perfectstorm.movie.edu. 3600    IN      NSEC    shining.movie.edu. A RRSIG NSEC
perfectstorm.movie.edu. 3600    IN      RRSIG   NSEC 5 3 3600
20060220010558 20060121000558 3674 movie.edu. EC/HwFtyrDtcf27QYvnSrJTypnAg3LsimFH+
lTO/VbB/dD7Wzj0am1Yy+/SF3u6nrJ1nV2hZBgSqmYB9plpM3Q==
perfectstorm.movie.edu. 3600    IN      RRSIG   NSEC 5 3 3600 20060220010558 200601210
00558 15480 movie.edu. H2XwAMRYkxsv721q0fOQk7g7j1SPPurKNGBDqlEDpeLnRkde8NHtlFOx
VbqWDsWzq15sxoV4NRZyK14cQcbG7Q==

;; Query time: 14 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 20 17:15:58 2006
;; MSG SIZE  rcvd: 726

Notice the second NSEC record: it was added automatically when we added perfectstorm.movie.edu’s address record because perfectstorm.movie.edu was a new domain name in the zone. Sweet!

As impressive as this is, you should be careful when allowing dynamic updates to signed zones. You should make sure that you use strong authentication (e.g., TSIG) to authenticate the updates, or you’ll give a hacker an easy backdoor to use to modify your “secure” zone. And you should ensure you have enough horsepower for the task: normally, dynamic updates don’t take much to process. But dynamic updates to a secure zone require the recalculation of NSEC records and, more significantly, asymmetric encryption (to calculate new RRSIG records), so you should expect your nameserver to take longer and need more resources to process them.

Though we said you don’t need to generate a new key each time you sign your zone, there are occasions when you’ll need to create a new key, either because you’ve “used up” a private key or, worse, because one of your private keys has been cracked.

After a certain amount of use, it becomes dangerous to continue signing records with a private key. While there’s no simple rule to tell you when a private key’s time is up, here are some guidelines:

Since movie.edu isn’t a high-value target, we change our zone-signing key pair every six months. We’re only a university, after all. If we were more concerned about our zone data, we would use longer keys or change keys more frequently.

Unfortunately, rolling over to a new key isn’t as easy as just generating a new key and replacing the old one with it. If you did that, you’d leave nameservers that had cached your zone’s data with no way to retrieve your zone-signing DNSKEY record and verify that data. So rolling over to a new key is a multistep process:

Let’s go through the process. First, we generated a new key pair:

#dnssec-keygen -a RSA -b 512 -n ZONE movie.edu.
Kmovie.edu.+005+15494

Next, we added the new DNSKEY record to the zone data:

#cat Kmovie.edu.+005+15494.key >> db.movie.edu.signed

We had to tell dnssec-signzone the keys to sign to zone with, and specify the KSK:

#dnssec-signzone -o movie.edu -k Kmovie.edu.+005+15480 db.movie.edu.signed
Kmovie.edu.+005.15494

This will sign the zone with the new ZSK and leave the set of RRSIG records signed with the old ZSK in the zone, but won’t regenerate RRSIGs with the old ZSK. Here’s how the resulting file began:

; File written on Tue Feb 21 02:41:09 2006
; dnssec_signzone version 9.3.2
movie.edu.              86400   IN SOA  toystory.movie.edu. al.movie.edu. (
                                        2006022100 ; serial
                                        10800      ; refresh (3 hours)
                                        3600       ; retry (1 hour)
                                        604800     ; expire (1 week)
                                        3600       ; minimum (1 hour)
                                        )
                        86400   RRSIG   SOA 5 2 86400 20060220210704 (
                                        20060121210704 3674 movie.edu.
                                        otYTiIHqJ4K0c6M5JZ9uC8q7AvXO1Gjp5FXJ
                                        5SRO+UL/ilAZXGSfJSCJrUDetb7R0H27NqHe
                                        yKujxcec69FoLw== )
                        86400   RRSIG   SOA 5 2 86400 20060320094111 (
                                        20060221094111 15494 movie.edu.
                                        zD/IGbzgO3sB5sPvYbb3vLmvULRQ05fV21Yz
                                        DO8gq2E+v575ag469h+J2Dzs6XheMxShmIpk
                                        YwjYxgMLcc1SjA== )

Although the zone includes two DNSKEY records, the other records in the zone (such as the SOA record, shown here) were signed only by the new private key, with key tag 15494. The old RRSIG records, generated from the private key with key tag 3674, were still included because they were still valid—but not for much longer. Note the expirations of the two RRSIG records covering the SOA record: key tag 3674’s RRSIG record expires a month earlier because it wasn’t regenerated.

After the old RRSIG records expired, we deleted the old DNSKEY record and the key files (so the signer wouldn’t use them) and re-signed the zone with just the new ZSK and the KSK:

#dnssec-signzone -o movie.edu db.movie.edu.signed
# mv db.movie.edu.signed.signed db.movie.edu.signed

That removed the old, invalid RRSIGs and re-signed the DNSKEY RRset with the KSK.

Changing KSKs is similar, and doesn’t need to be done as often:

We’re guessing that after reading this, you’ll probably decide to use the longest keys available just to avoid ever needing to roll your keys over.

We realize that DNSSEC is a bit, er, daunting. (We nearly fainted the first time we saw it.) But it’s designed to do something very important: make DNS spoofing much, much harder. And as people do more and more business over the Internet, knowing you’re really getting where you thought you were going becomes crucial.

That said, we realize that DNSSEC and the other security measures we’ve described in this chapter aren’t for all of you. (Certainly they’re not all for all of you.) You should balance your need for security against the cost of implementing it, in terms of the burden it places both on your infrastructure and on your productivity.