|
|
11.4. The DNS Security ExtensionsTSIG, which we described earlier in this chapter, is well suited to securing the communications between two nameservers or between an updater and a nameserver. However, it won't protect you if one of your nameservers is compromised: if someone breaks into the host that runs one of your nameservers, he may also gain access to its TSIG keys. Moreover, because TSIG uses shared secrets, it isn't practical to configure TSIG among many nameservers. You couldn't use TSIG to secure your nameservers' communications with arbitrary nameservers on the Internet because you can't distribute and manage that many keys. The most common way to deal with key management problems like these is to use public-key cryptography. The DNS Security Extensions (DNSSEC), described in RFCs 4033, 4034, and 4035, use public-key cryptography to enable zone administrators to digitally sign their zone data, thereby proving its authenticity.
11.4.1. Public-Key Cryptography and Digital SignaturesPublic-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 keysa key pairare 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 slowmuch 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
11.4.2. The DNSKEY RecordIn 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. 11.4.3. The RRSIG RecordIf 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 signedin 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. 11.4.4. The NSEC RecordDNSSEC 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 namehence 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." 11.4.5. The DS Record and the Chain of TrustThere'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. 11.4.5.1. Islands of securityLet's say we want to begin using DNSSEC at Movie U. to improve the security of our zone data. We've signed the movie.edu zone but can't have edu certify our DNSKEY record because they haven't signed their zone yet and don't have a key pair. How can other nameservers on the Internet verify our zone data? How can our own nameservers verify our zone data, for that matter? BIND 9 nameservers provide a mechanism for specifying the public key that corresponds to a particular zone in the named.conf file: the trusted-keys statement. Here's the trusted-keys statement for movie.edu:
trusted-keys {
movie.edu. 257 3 5 "AQPWA4BRyjB3eqYNy/oykeGcSXjl+HQK9CciAxJfMcS1vEuwz9c
+QG7s EJnQuH5B9i5o/ja+DVitY3jpXNa12mEn";
};
It's basically the DNSKEY record without the class and type fields and with the key itself quoted. The domain name of the zone may be quoted, but it's not necessary. If movie.edu had more than one public keysay a DSA keywe could include it, too:
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";
};
This trusted-keys statement enables a BIND 9 nameserver to verify any records in the movie.edu zone. The nameserver can also verify any records in child zones such as fx.movie.edu, assuming their DNSKEY records are certified by a DS record and accompanying RRSIG record in movie.edu. In other words, movie.edu becomes a trust anchor, below which our nameserver can verify any signed zone data. 11.4.5.2. Delegating to unsigned zonesA DS record indicates that a particular delegated subdomain is signed and authorizes a particular DNSKEY record to verify signed data. But what if a subdomain isn't signed? Unsigned subdomains won't have DS records in the parent zone. They also won't have RRSIG records covering their DS records, of course. The NS records that implement the delegation will have one or more associated NSEC records, though, and the NSEC records will be covered with RRSIG records. If there are any glue address records, they won't have NSEC records or RRSIG records because these records really belong to the subdomain. What happens to name resolution when a nameserver follows delegation from a signed zone to an unsigned zone depends on the security policy of the querying nameserver. The nameserver might accept responses from the unsigned zone or insist that those responses be signed. 11.4.6. DO, AD, and CDYou'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 secureusing 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. 11.4.7. How the Records Are UsedLet'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 keyunless, 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. 11.4.8. DNSSEC and PerformanceIt 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 substantiallycurrent 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. 11.4.9. Zone-Signing Keys and Key-Signing KeysIn 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). 11.4.10. Signing a ZoneOkay, 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. 11.4.10.1. Generating your key pairsFirst, we generated a KSK key pair for movie.edu:[*]
# cd /var/named # dnssec-keygen -f KSK -a RSASHA1 -b 512 -n ZONE movie.edu. Kmovie.edu.+005+15480 Next, we generated a ZSK key pair (we don't need to specify a -f option because this is the default): # dnssec-keygen -a RSASHA1 -b 512 -n ZONE movie.edu. Kmovie.edu.+005+03674 We ran dnssec-keygen in our nameserver's working directory. That's mostly for convenience: the zone datafiles are in this directory, so we won't need to use full pathnames as arguments. If we want to use dynamic update with DNSSEC, however, the keys must be in the nameserver's working directory. The -f KSK option sets the SEP flag in the DNSKEY record. To leave the flag clear, omit the option. Recall dnssec-keygen's other options from the TSIG section of this chapter (oh, so long ago):
The only nonoption argument is the domain name of the zone, movie.edu. The dnssec-keygen program prints the basename of the files it's written the keys to. The numbers at the end of the basename (005 and 15494), as we explained in the "TSIG" section, are the key's DNSSEC algorithm number as used in the DNSKEY record (005 is RSA/SHA-1), and the key's fingerprint, used to distinguish one key from another when multiple keys are associated with the same zone. The public key is written to the file basename.key (e.g., Kmovie.edu.+005+15480.key). The private key is written to the file basename.private (e.g., Kmovie.edu.+005+15480.private). Remember to protect the private key; anyone who knows the private key can forge signed zone data. dnssec-keygen does what it can to help you: it makes the .private file readable and writable only by the user who ran the program. 11.4.10.2. Signing your zoneBefore signing our zone, we had to add the DNSKEY records to our plain-Jane zone datafile: # cat "$INCLUDE Kmovie.edu.+005+15480.key" >> db.movie.edu # cat "$INCLUDE Kmovie.edu.+005+03674.key" >> db.movie.edu Then, we signed the zone with dnssec-signzone: # dnssec-signzone -o movie.edu. db.movie.edu db.movie.edu.signed We used the -o option to specify the origin in the zone datafile, because dnssec-signzone doesn't read named.conf to determine which zone the file describes. The only nonoption argument is the name of the zone datafile. If the name of our zone datafile had been the same as the domain name of the zone, we could have omitted the -o option. dnssec-signzone is smart enough to look at the SEP field in the DNSKEY records to determine which key to sign which records with. It'll sign the whole zone with the ZSK and just the DNSKEY records with both the ZSK and the KSK. This produces a new zone datafile, db.movie.edu.signed, which begins like this:
; 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== )
Believe it or not, those are just the records attached to the domain name movie.edu. The zone datafile as a whole more than quintupled in length and quadrupled in size. Oy! Finally, we turned on DNSSEC support on our nameserver[*] and changed the zone statement in named.conf so that named would load the new zone datafile:
options { directory "/var/named"; dnssec-enable yes; }; zone "movie.edu" { type master; file "db.movie.edu.signed"; }; Then we reloaded the zone and checked syslog. dnssec-signzone does take some options that we didn't use:
You can also specify, as a second nonoption argument, which private key to use to sign the zone. By default, dnssec-signzone signs the zone with each of the zone's private keys in the directory. If you specify the name of one or more files that contain the zone's private keys as arguments, it will sign using only those keys. Remember, you'll need to re-sign the zone each time you change the zone data, though you certainly don't need to generate a new key pair each time. You can re-sign the zone by running dnssec-signzone on the signed zone data: # 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 The program is smart enough to recalculate NSEC records, sign new records, and re-sign records whose signature expiration times are approaching. By default, dnssec-signzone resigns records whose signatures expire within 7.5 days (a quarter of the difference between the default signature inception and expiration times). If you specify different inception and expiration times, dnssec-signzone adjusts the re-signing cycle time accordingly. Or you can simply specify a cycle time with the -i (formerly the -c) option. 11.4.10.3. Sending your keys to be signedNext, we sent our KSK to the administrator of our parent zone to sign. Conventiently, dnssec-signzone created a keyset file for us when we ran it. This is a small file, called keyset-movie.edu, which contains all of the DNSKEY records in our zone. The contents look like this:
$ORIGIN .
movie.edu 3600 IN DNSKEY 257 3 5 (
AQPWA4BRyjB3eqYNy/oykeGcSXjl+HQK9Cci
AxJfMcS1vEuwz9c+QG7sEJnQuH5B9i5o/ja+
DVitY3jpXNa12mEn
) ; key id = 15480
dnssec-signzone even creates a DS record for the edu administrators to insert into the edu zone and writes it to the file dsset-movie.edu.[*] The dsset file contains:
movie.edu. IN DS 15480 5 1 F340F3A05DB4D081B6D3D749F300636DCE3D6C17 Then, we sent our keyset file off to our parent zone's administrators to sign. Since the message included proof of our identity,[
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= )
Note the RRSIG record covering the DS record. This indicates the edu zone's certification of our DS record, and thus our KSK's DNSKEY record. If we didn't care about getting our DNSKEY record signed, we could have skipped this step. However, then only nameservers with a trusted-keys entry for movie.edu could verify our data. 11.4.10.4. Signing a parent zoneSigning a zone that's a parent to one or more subzones is straightforward. If the subzones aren't signed, there's really nothing different to do: run dnssec-signzone to sign the parent zone, just as you normally would. The records that make up delegation to unsigned subzones won't be changed. For example, here's what the delegation to the unsigned fx.movie.edu looked like after we signed movie.edu:
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
Note the NSEC record attached to fx.movie.edu: the domain name "counts" as far as NSEC records are concerned, but neither the NS records nor the glue A records are signed. Only the NSEC record itself is signed. If the fx.movie.edu administrators sign their zone, they need to submit only their keyset or dsset file to us (in some sufficiently secure fashion), just as we submitted ours to the edu administrators. If the keyset file is present in the working directory when we sign movie.edu, we can use the -g option to tell dnssec-signzone to create an fx.movie.edu DS record automatically. Otherwise, we can add the DS record from the dsset file manually and re-sign movie.edu. Here's how the signed delegation ends up looking:
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== )
Notice that the NS records still aren't signed (because technically they belong to the child zone), but the DS record is. 11.4.11. DNSSEC and Dynamic Updatednssec-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. 11.4.12. Changing KeysThough 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 validbut 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. 11.4.13. What Was That All About?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. |
|
|
]