|
"One Key to rule them all,
In this article I use the terms domain and zone . These are important concepts in the DNS and in DNSSEC. The difference between a zone and a domain is worth highlighting. A domain is a part of the DNS tree. A zone contains the domain names and data that that domain contains except for the domain names and data that are delegated elsewhere. Also refer to [4]. Consider, for instance, the .com domain, which includes everything that ends in .com . CNN.com is in the .com domain. The .com zone , however, is the entity handled by VeriSign. One other important concept in DNS is the Resource Record (RR) and the Resource Record Set (RRset). An RR in DNS is, for instance: www.example.org. IN A 127.0.0.1 ... where www.example.org is the "ownername" or "name." IN is the class (IN stands for Internet). A 127.0.0.1 is the type (together with its rdata). A stands for "address." This 3-tuple (name, class, type) together make up the resource record. RRset are all the RRs that have an identical name, class and type. Only the rdata is different. Thus: www.example.org. IN A 127.0.0.1 www.example.org. IN A 192.168.0.1 ... together form a RRset, but: www.example.org. IN A 127.0.0.1 www.example.org. IN MX mail.example.org. ... do not (their type is different). In the DNS an RRset is considered atomic and the smallest data item. In DNSSEC each RRset gets a signature. What Is DNSSEC? DNSSEC adds data origin authentication and data integrity to the DNS. To achieve this, DNSSEC uses public key cryptography; (almost) everything in DNSSEC is digitally signed. Public key cryptography uses a single key split in two parts: a private and a public component. The private component, also known as the private key , must be kept secret. The public component (the public key ) can be made public. Both these keys can be used for cryptographic operations, albeit with different goals. If a message is scrambled with the public key, it can be decrypted only with the private key. This is called encryption of the message and it ensures that only the holder of the private key can read the original message. When the private key is used to scramble a message, everybody can use the available public key to decipher the message. This last operation is called (digitally) signing a message (for increased speed usually a hash of the message is signed). In this case you know where the message comes from ( authenticated data origin in cryptographic jargon). An added benefit of signing messages is that when the data is mangled during transport the signature is no longer valid. This last property is called authenticated data integrity . A more lengthy introduction on public key cryptography can be found at [10]. In DNSSEC only digital signatures (signing) are used, and nothing is ever encrypted. For every secure zone there must be a public key in the DNS for use by DNSSEC. Each zone administrator generates a key to be used for securing a zone. The private key is (of course) kept private and is used in the "signing process" to create the signatures. The public key is published in DNSSEC as a DNSKEY record, which is the zone key. The generated signatures are published as RRSIG records. If RRsets in DNSSEC do not have a valid signature, they are labeled bogus by the resolver. Bogus data should not be trusted, because probably somebody is trying to conduct a spoof attack. DNSSEC further distinguishes between:
Verifiable secure data is data that has valid signatures, and the key used to create those signatures is trusted (anchored in the resolver). Verifiable unsecure data is data for which we know for sure we do not need to do signature validation. Old-style DNS is the current (insecure) method of getting DNS data.
In Figure 1 the following takes place.
Deployment As mentioned earlier, each zone owner generates its own key. To make the secure delegation actually work, this key must somehow be securely transferred to the parent, which is usually the local registry. The registry must have procedures in place to determine whether or not the uploaded key really belongs to the domain it claims to come from. During the Secure Registry (SECREG) experiment [5] NLnet Labs has researched the impact DNSSEC has on registries. But even before the key can be actually uploaded to the parent, a zone administrator still has to do some work; the DNS zone must be signed. This process, called zone signing , turns a DNS zone into a DNSSEC zone. The signing is done offline; first you sign, and then you load the zone. This setup was chosen because at the time (late 1990) computers were not fast enough to generate the signature in real time. Currently it would be possible to do this, but having a server sign every answer it gives is a Denial-of-Service (DoS) attack waiting to happen. Especially root servers will be unable to do this. In DNSSEC a zone can have multiple keys. The signed zone then has multiple signatures per RRset (one for each key). There is no protocol limit on the number of keys. Here we sign with only one zone key. Also signatures in DNSSEC have a start and end date, that is, before and after a certain date interval the signature can no longer be used for validation. If you use DNSSEC, you must re-sign your zone to generate new signatures with a new validity interval.
Experiments have shown that this does not pose much of a problem, even for such so-called country code Top Level Domains (ccTLDs) as .nl . The signed .nl zone was 350 megabytes, slightly more than a half a CD-ROM. And even if scaling problems are occurring, 64-bit machines would certainly help. A few years ago there was much concern about the signing time. There was fear that it would be impossible to sign large zones, such as .com . Experiments disproved this fear. Furthermore, a zone can be split up in pieces and each piece can be signed on a different machine. Later all the signed pieces can be put back together. Signing DNS zones is a highly parallel process. After signing the zone, it can be loaded in the nameserver. If a resolver is DNSSEC-aware and has been configured with a trusted key that has a chain of trust to the zone key, it can validate the answers. If an answer does not validate, something is wrong and the DNS data must not be used. The actual Internet-wide deployment of DNSSEC can happen incrementally. Each zone can decide to join independently. It is expected that initially DNSSEC is deployed in subsections of the Internet. These socalled Islands of Trust can appear anywhere on the Internet or even in intranets. The only requirement is that the key of the island of trust is distributed to the resolver. Resolvers configured with the key of a certain island of trust are called the resolvers of interest . Of course when DNSSEC is widely deployed on the Internet all resolvers are resolvers of interest and will have that key preconfigured. Authenticated Denial of Existence As mentioned previously, all records are signed offline. When a nameserver receives a query it looks up the answer plus the signature and returns the two (RRSIG + RRset) to the resolver. The signature is thus not created in real time. How can a secure-aware nameserver then respond to a query for something it does not know (that is, give an NXDOMAIN answer)? The only way to have offline signing and NXDOMAIN answers work together is to somehow sign the data you do not have. In DNSSEC this is accomplished by the Next SECure (NSEC) record. This NSEC record holds information about the next record; it spans the nonexistence gaps in a zone, so to say. For this to work, a DNSSEC zone must be sorted (this is where that requirement stems from). To clarify this, consider an example. We have a DNS zone, with (for the sake of clarity only the NSEC records are shown): a.nl d.nl e.nl Next we generate (with the signer) our DNSSEC zone: a.nl a.nl NSEC d.nl (span from a.nl to d.nl) d.nl d.nl NSEC e.nl (span from d.nl to e.nl) e.nl e.nl NSEC a.nl (loop back to a.nl)
This section briefly considers the history of DNSSEC and, in particular, why the DNSEXT working group has invented this peculiar DS record, which can only exist at the parent side of a zone cut. In RFC 2535 the DS record did not exist, and this is the reason that the key management in RFC 2535-DNSSEC is very, very cumbersome. In 2000 NLnet Labs ran its first experiment to test deployment of DNSSEC in the Netherlands. Because .nl.nl was chosen as the zone under which the secure tree would grow, this experiment became known as the nl-nl-experiment . With this experiment it was shown that the current DNSSEC standard (the soon-to-be-obsoleted RFC 2535) was difficult to deploy [7]. An update of a zone key in a child zone required up to 11 (coordinated and sequential) steps with the parent zone. The .nl zone now has more than 1 million delegations, so updating all the child zones would require more than 11 million steps. Because these updates could be quite frequent (once a month is typical), this is clearly an administrative nightmare. Worse yet, if .nl lost its private key, all child-zone administrators would have to be notified and they would have to resubmit their public key for re-signing with the new .nl key. And because under these conditions the DNS may have been hacked and is thus untrusted, .nl is limited in its communication through the Internet; e-mail may not be the preferred method. A telephone call would be more safe, but what kind of organization can make up to one million phone calls in a few days ..? After various failed attempts (sig@parent [8]) to fix this behavior, the DS record was introduced [1,3]. With this record the administration nightmare is solved, because DS introduces an indirection from the parent zone to a child's zone key. If .nl loses its private key, it can easily resign its own zone, without contacting all its children. The DS to child key indirection is still valid, and only the signature of the DS record needs to be updated. This is a local operation. To test this new DNSSEC specification, a new experiment was set up, which would build a shadow DNSSEC tree in the .nl zone. This experiment, called SECREG , was to test the new procedures in DNSSEC and, of course, the new DS record. Detailing the conclusions of this experiment is beyond the scope of this article, but in short the conclusion was that the new DNSSEC procedures do not pose much difficulty. At some point, more than 15,000 zones were delegated from the secure tree. A writeup of the experiment and the conclusions can be found in "DNSSEC in NL" [5]. Settings and Parameters in DNSSEC DNSSEC brings many new parameters to the DNS, including cryptographic ones such as key sizes, algorithm choices, and key and signature lifetimes. Because DNS never has involved cryptography, the best values for these parameters are still open for debate. There is, however, some documentation and knowledge available on this topic (refer to [9] for instance). One of the major issues is how large (bit length) to make a zone key and how often to re-sign a zone file. The current view is that a parent zone should use larger keys and re-sign more often than a child zone. Also the signature lifetime should be shorter in a parent zone. Because a parent zone has a DS record (and signature) of a child's zone key, it can decide how long this DS RRSIG must be valid. The shorter this validity interval is, the better protected the child. If a cracker steals a child's zone key, it can forge DNS data. This data looks genuine because the cracker has access to the private key. As long as there is a valid chain of trust to this hijacked key, the child is vulnerable. This chain of trust is broken as soon as the RRSIG of the DS record expires. This argues in favor of a very short parental RRSIG over the DS record. However, making this interval too short opens the door for accidental mishaps. If a child zone makes an error and somehow the chain of trust is broken, it has until the RRSIG expires to fix the problem. This would recommend a longer signature lifetime. In DNSSEC these and other trade-offs have to be made. The IETF DNSOP working group is currently addressing these parameters and their trade-offs. The current data came (and comes) from workshops and early test deployments. Outlook and Prospects Because DNSSEC requires some additions to the (cc/g)TLD registration process, it could be a while before ccTLDs are capable of deploying DNSSEC. If the protocol is completed this year (2004), it will probably take a few years before registries can advertise DNSSEC domain names. It is important to consider what DNSSEC actually wants to accomplish; it makes spoofing attacks in the DNS visible—and nothing more. It is not a PKI with all the extra features because key revocation is, for instance, not implemented in DNSSEC. Seen in this light, the protection of private keys in DNSSEC is important, but when a private key is compromised we are just back to plain old DNS. On the other hand, because DNSSEC does introduce cryptographic material in the DNS and allows for the addition of other (non-DNS) keys, some interesting possibilities emerge. Many technologies on the Internet want to have some kind of simple key distribution mechanism in place; for example: SSH and IPSec. What DNSSEC promises is a system in which we can validate the SSH key from an unknown host with only one key. If the validation is successful, we are quite certain the SSH host key comes from the host from which it claims to come. We get this without any extra effort or cost (from a client's perspective at least). The possibilities are probably endless. |
By Miek Gieben, NLnet Labs Reprinted with permission from The Internet Protocol Journal (IPJ), June 2004 issue (Vol 7no 2) . IPJ is published by Cisco Systems. All contents are Copyright © 1992--2002 Cisco Systems, Inc. About the Author: MIEK GIEBEN graduated in Computer Science in 2001 from the University of Nijmegen (Netherlands) on the subject of DNSSEC. He has been employed by NLnet Labs since that time. He has been using Linux and the Internet since 1995. Currently he is involved in DNSSEC deployment and has co-written parts of NSD2 (which is now fully DNSSEC aware). His personal home page can be found at http://www.miek.nl/ . The home page of NLnet Labs can be found at http://www.nlnetlabs.nl/ . References About Articles of Interest Articles of interest to the International Internet community, reprinted with permission by: 4, rue des Falaises Series Editor: Martin Kupres
The Internet Society |
