The NXT RR. The SIG and KEY RRs are strong enough to authenticate existing DNS records, but DNSSEC wouldn't be truly secure without a mechanism to authenticate nonexistent records. For example, consider the unsecured www.us.example.com zone file that Listing 1 shows. If a client queries a nonexistent record, product.us.example.com, the DNS server running the unsecured zone will return the SOA RR and an NXDOMAIN error, which indicates that the queried record doesn't exist.
If DNSSEC used the same method to reply to such a query—even if DNSSEC provided a corresponding SIG RR for the signed SOA RR—an intruder could easily wreak havoc. The intruder could query the zone or listen to the wire to determine us.example.com's SOA and corresponding SIG RRs. Then, when a client queried the DNS server for the existing record www.us.example.com, the intruder could send that client the SOA and SIG RRs and the NXDOMAIN error before the DNS server could respond. The client would verify the SOA RR's signature and determine that www.us.example.com didn't exist.
To prevent such problems, DNSSEC introduced the NXT RR, which indicates the record-owner names that don't exist within a specified name interval. (For example, if a client knows that within the name interval 1 through 4, the current record is 1 and the next record is 4, the client can infer that the records 2 and 3 are nonexistent.)
DNSSEC arranges a signed zone's record sets in canonical order (i.e., zone name, wildcard—*—record—if any, then the other records in alphabetical order) and inserts a NXT RR for each record. A NXT RR's syntax is
next_record_owner record_types_
in_current_set
For example, ns1.us.example.com's NXT RR, which callout C in Figure 1 shows, states that the next record's owner name is www.us.example.com and that the current record (i.e., ns1.us.example.com) contains the RR types A, SIG, and NXT. From this NXT RR, the client can determine that no other records exist between ns1.us.example.com and www.us.example.com. A zone's final NXT RR always points back to the zone's first record (i.e., the zone name). DNSSEC signs each NXT RR with an associated SIG RR, and the NXT record's syntax prevents intruders from using the NXT RR to make a client believe an existing record doesn't exist.
Using DNSSEC in BIND
To use DNSSEC in BIND 9.1.3, you must set up a secure zone on a BIND 9.1.3 server. This process involves four steps: generating keys, creating a keyset, signing the child zone's keyset, and signing the zone.
Generating keys. A secure zone must have one or more public and private key pairs, called zone keys. You use the zone's private key to sign the zone. DNS clients use the corresponding public key to verify signatures. When the parent zone (e.g., example.com) delegates a secure child zone (e.g., us.example.com), you can use the parent zone's private key or keys to sign the child zone's key or keys. If the parent zone has multiple key pairs, you can use different keys to sign the parent and child zones' key or keys.
You use the dnssec-keygen command to generate keys on a BIND 9.1.3 server. (Enter the command without any parameters to see command-usage information.) For example, to generate a key pair for the child zone us.example.com in Listing 1, enter the following command on the BIND server:
dnssec-keygen -a DSA -b 1024 -n ZONE us.example.com.
The -a option defines which digital signature algorithm the generated keys will use. According to RFC 2535, DSA is the mandatory algorithm for DNSSEC interoperability, but BIND 9.1.3 also supports Diffie-Hellman, Hash Message Authentication Code (HMAC)—MD5, RSA, and RSA/MD5. The -b option specifies the key length (1024 bits in this example). The -n option defines the keys' name type, which can be zone, host, entity, or user. The final parameter in the sample command is the key name, which must be the same as the zone name if the specified name type is zone.
The dnssec-keygen command also lets you choose the protocol that the generated keys will support; DNSSEC is the default. The command automatically saves the generated keys in two output files in the current directory; the parameters you use in the command determine the filenames. The sample command would store the public key in the file Kus.example.com.+003+51297.key and store the private key in the file Kus.example.com.+003+51297.private. The first number set represents the digital algorithm (in this example, DSA, which DNSSEC represents by the number 3). The second number set (51297 in this example) is the key tag, which distinguishes the keys from other key pairs and appears in the signed zone's SIG records. You need to protect the private key file and keep it secret, but you need to include the public key filename in the child zone's unsecured zone file, as callout A in Listing 1 shows.
Creating a keyset. Before the parent zone can sign a child zone's public key, you need to create a keyset containing the child zone's public key that the parent zone can recognize and sign. You use the dnssec-makekeyset command to create this keyset. For example, the command
dnssec-makekeyset -t 7200 -e 20011231235959 Kus.example
.com.+003+51297
creates a keyset for the child zone us.example.com. The -t option defines the SIG and KEY records' TTL value. The sample command specifies the TTL as 7200 seconds; 3600 seconds is the default. The -e option defines the end time of the parent zone's signature. The sample command specifies that the signature expires at 23:59:59 on December 31, 2001 (i.e., 20011231235959); the default signature end time is 30 days after the start time. (The sample command accepts the default signature start time, which is now, but you can use the -s option to specify a start time.) The command saves the keyset output file as keyset-zone. in the current directory. (The ending period is part of the filename.) For example, the output file keyset-us.example.com. would result from the sample command.
