by Miek Gieben, NLnet Labs

"One Key to rule them all,
one Key to find them,
one Key to bring them all
and in the Resolver bind them."
—Modified from Lord of the Rings.

The Domain Name System (DNS) (RFCs 1034 and 1035) is a highly successful and critical part of the Internet infrastructure. Without it the Internet would not function. It is a globally distributed database, whose performance critically depends on the use of caching.

Unfortunately the current DNS is vulnerable to so-called spoofing attacks whereby an attacker can fool a cache into accepting false DNS data. Also various man-in-the-middle attacks are possible. The Domain Name System Security Extension (DNSSEC) is not designed to end these attacks, but to make them detectable by the end user. Or more technically correct: detectable by the security-aware resolver doing the work for the end user. This saves users from doing online banking on the wrong server even if a secured connection is used and the address in the browser looks correct.

DNSSEC is about protecting the end user from DNS protocol attacks. In order to make it work, zone owners (such as .com, .net, .nl, etc.) need to deploy DNSSEC in their zones. End users then need to update their resolvers to become security-aware (that is, understand DNSSEC) and add some trusted keys. These keys are called anchored keys; they are configured in the resolver and cannot be changed or updated very easily. If this is all configured, the end user will (finally) be able to detect attacks.

DNSSEC, as defined in (hopefully soon-to-be-obsoleted) RFC 2535, adds data origin authentication and data integrity protection to the DNS. The Public Key Infrastructure (PKI) in DNSSEC may be used as a means of public key distribution, which may be used by other protocols. IP Security (IPSec) and the Secure Shell (SSH) protocol, for example, are already considering the use of DNSSEC to carry their keying material.

In the course of early-deployment experiments carried out by various organizations, it became evident that RFC 2535 introduced an administrative key-handling and maintenance nightmare. This in turn would mean the DNSSEC deployment would never start (or be successful, for that matter).

The IETF DNSEXT working group decided to fix this problem, and to incorporate all drafts and RFCs written since RFC 2535 into a new DNSSEC specification.

This (still ongoing) effort became known as the RFC 2535bis DNSSEC specification. This work has resulted in three drafts, each handling a specific part of the new specification. These drafts follow:

1.	dnssec-intro [1] provides an introduction into DNSSEC.
2.	dnssec-records [2] introduces the new records for use in DNSSEC.
3.	dnssec-protocol [3] is the main document, which details all the protocol changes.

The documents are now almost ready (July 2004) to be submitted to the Internet Engineering Steering Group (IESG) for review. It is hoped that soon after this is done the drafts will become RFCs. It could be that 2004 will be the year of DNSSEC.

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—The data has signatures that are valid.
	Verifiable unsecure*—The data has no signatures.
	Old-style DNS—A non-DNSSEC lookup is done.

   * Yes, Unsecure. This word has somehow evolved from "insecure."

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.

The signing of data in DNSSEC is comparable to the Gnu Privacy Guard (GPG) signing of e-mail. If I trust a public key from someone, I can use that key to verify the GPG signature and authenticate the origin of the e-mail.

The problem with both DNSSEC and GPG lies in the "...If I trust the public key from someone." GPG solves this with public key servers, key signing parties at various events and thus the creation of a web of trust. For DNSSEC such solutions are impractical. DNSSEC uses a different, but very elegant mechanism called the chain of trust.

The chain of trust makes it possible to start with a root zone key, the highest possible key in the DNS tree, and following cryptographic pointers to lower zones. Each pointer is validated with the previous validated zone key. (The root key is the key used in the root zone of the Internet; it is the key used in the . (dot) zone. It could take a while before the root is signed.)

By using this mechanism only the root key is needed to validate all DNSSEC keys on the Internet. With these DNSSEC keys the DNS data in each zone can then be validated. So, unlike GPG, we need to distribute only one key. This can be done by publishing it on the World Wide Web or in a newspaper or putting an ad on TV, etc.

One of the current items in the DNSSEC community is to outline procedures and guidelines on how to update this root and other keys.

Chain of Trust
To start securely resolving in DNSSEC, a root key must be anchored in the resolver at your local computer or nameserver. Only when a resolver knows and trusts a zone key can it validate the signatures belonging to that zone. Because of the chain of trust, a resolver has to carry only a few zone keys to be able to validate DNSSEC data on the Internet.

The chain of trust works by following "secured pointers," which are called secured delegation in DNSSEC. A special, new record called the Delegation Signer (DS) record delegates trust from a parental key to a child's zone key.

The DS record holds a hash (Secure Hash Algorithm 1 [SHA-1]) of a child's zone key. This DS record is signed with the zone key from the parent. By checking the signature of the DS record, a resolver can validate the hash of the child's zone key. If this is successful, the resolver can compare this (validated) hash with the (yet-to-be-validated) hash of the child's zone key. If these two hashes match, the child's real zone key can be used for validation of data in the child's zone. Note: by successfully following a secured delegation, the amount of trust a resolver has in the parental key is transferred to a child's key. This is the crux of the chain of trust.

Figure 1: nlnetlabs.nl is a secured delegation under .nl. RTSIG(x)y denotes that a signature over a data x is created with key y.



In Figure 1 the following takes place.

The .nl zone contains the following:

nl.  IN  SOA  (soa-parameters)
; the zone key
nl.  IN  DNSKEY NLkey
nl.  IN  RRSIG(DNSKEY)NLkey
nl.  IN  RRSIG(SOA)NLkey

nl.  IN  NS ns5.domain-registry.nl.
; this NS is authoratitive
nl.  IN  RRSIG(NS) NLkey

nlnetlabs.nl.  IN  NS  open.nlnetlabs.nl.
; no RRSIG here (nonauthoritative data is not signed)

; DS record with a hash of the child's zone key
nlnetlabs.nl.  DS  hash(LabsKey)
; The signature of the parent
nlnetlabs.nl.  RRSIG(DS)NLkey

Note: It is important to see that we now have linked a parental signature to something that is almost the key of the child.

And the nlnetlabs.nl zone has the following:

nlnetlabs.nl.  IN  SOA (soa-parameters)
; The zone key
nlnetlabs.nl.  IN  DNSKEY LabsKey
nlnetlabs.nl.  IN  RRSIG(SOA)Labskey
; The (self) signature of the zone key
nlnetlabs.nl.  IN  RRSIG(DNSKEY)Labskey
nlnetlabs.nl.  IN  NS open.nlnetlabs.nl.
nlnetlabs.nl.  IN  RRSIG(NS)LabsKey

So the chain of trust looks like the following:

.nl DNSKEY -> nlnetlabs.nl DS -> nlnetlabs.nl DNSKEY

... and with that last key we can validate the data in the nlnetlabs.nl zone.

With this "trick" all keys from all the secure .nl zones can be chained from the .nl "master" key. So instead of one million (the number of zones in .nl currently) we need to configure only one key.

As you might have guessed, getting the root zone signed as soon as possible will make it possible to have one key that validates all other keys on the Internet.

We can also look at it from the resolver side. A resolver wants to get an answer. With DNSSEC it has to deal with signatures, keys, and DS records, but those are "side issues"; it still wants an answer.

Suppose .nl is secured and a secure delegation to nlnetlabs.nl exists. Our resolver has the key of .nl anchored. The nameservers of the root zone are also known to the resolver. We further assume the root is not signed. The resolver wants to resolve the address (A record) of www.nlnetlabs.nl. What does the actual resolving process look like in DNSSEC? Numerous steps need to be performed:

1.	Go to a root server and ask our question.
2.	The root server does not know anything about www.nlnetlabs.nl, but it does know something about .nl. The root nameserver refers us to the .nl nameservers. This kind of answer is called a referral.
3.	a. Notice that we have a key for .nl anchored. b. Go to the .nl nameserver and ask the .nl DNSKEY.
4.	a. Compare the two DNSKEYs. Continue with the secure lookup only if they match. The .nl DNSKEY is now validated. b. Optionally, the RRSIG on the DNSKEY also can be checked.
5.	Ask a .nl nameserver our question.
6.	The .nl nameserver is also oblivious about www.nlnetlabs.nl, but it does know something about nlnetlabs.nl. It returns a secure referral consisting of a DS record plus the RRSIG and some nameservers.
7.	The resolver now checks the signature on the DS record. If the signature is valid, the hash of the nlnetlabs.nl zone key is ok. The nameservers in the referral do not have any signatures on them. The hash of the nlnetlabs.nl DNSKEY is validated with the .nl DNSKEY.
8.	Go to the nameserver as specified in the referral and ask for the nlnetlabs.nl DNSKEY.
9.	Hash the DNSKEY of nlnetlabs.nl and compare this hash with the hash in the DS record. If they match continue with the secure lookup. The nlnetlabs.nl DNSKEY is now validated.
10.	Ask the nameserver of nlnetlabs.nl our question.
11.	The nameserver now responds with an answer consisting of the A record of www.nlnetlabs.nl and an RRSIG made with the nlnetlabs.nl DNSKEY.
12.	The resolver now uses the already validated nlnetlabs.nl DNSKEY to check the RRSIG. If that signature is valid the RR with the answer is ok and can be given to the application.
13.	After these steps we find out that the address of www.nlnetlabs.nl is 213.154.224.1. We also know it is not a spoofed answer.

This looks like a lot of work and it is—a recursive resolver is a complicated piece of software. Keep in mind, though, that only steps 3ab, 4ab, 7, 8, 9, and 12 are needed for DNSSEC; the rest is how resolving is done in the DNS today.

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.

1.	The zone key is added to the zone file.
2.	The zone file is sorted.
3.	Each owner name (for example, a host name) in the zone gets a Next SECure (NSEC) record. (Refer to the section "Authenticated Denial of Existence.")
4.	For each secured delegation, a DS record is added.
5.	The entire zone is then signed with the private key of the zone. Each authoritative RRset gets a signature, including the newly generated NSEC records.

Berkeley Internet Name Domain (BIND) [6] version 9—a popular implementation of the DNS protocols—contains a tool dnssec-signzone, which does steps 2 through 5 automatically; we only (manually) need to add the zone key to the zone file. The net result is that we have a bigger, signed, DNSSEC zone. A typical DNSSEC zone is 7 to 10 times larger than its DNS equivalent.

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)

1.

If a resolver asks information about b.nl, the nameserver tries to look up the record fails. Instead it finds a.nl. It must then return: a.nl NSEC d.nl together with the signature. The resolver must then be smart enough to process this information and conclude that b.nl does not exist. If the signature is valid, we have an authenticated denial of existence. These NSEC records together with their signatures are the major cause of the zone size increase in DNSSEC.

Road to the DS Record
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.

References
[1] Roy Arends, Rob Austein, Dan Massey, Matt Larson, and Scott Rose, "DNS Security Introduction and Requirements," Work In Progress.

[2] Roy Arends, Rob Austein, Dan Massey, Matt Larson, and Scott Rose, "Resource Records for the DNS Security Extensions," Work In Progress.

[3] Roy Arends, Rob Austein, Dan Massey, Matt Larson, and Scott Rose, "Protocol Modifications for the DNS Security Extensions," Work In Progress.

[4] DNS and BIND Talk Notes:
http://www.tfug.org/helpdesk/general/dnsnotes.html

[5] R. Gieben, "DNSSEC in NL,"

[6] BIND9, Berkeley Internet Name Domain, Version 9:
http://www.isc.org/sw/bind/

[7] R. Gieben, "Chain of Trust: The parent-child and keyholderkeysigner relations and their communication in DNSSEC," NIII report CSI-R0111:
http://www.cs.kun.nl/research/reports/info/CSI-R0111.html

[8] R. Gieben and T. Lindgreen, "Parent's SIG over Child's KEY"

[9] O. Kolkman and R. Gieben, "DNSSEC Operational Practices," Work In Progress, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-operational-practices-01.txt

[10] Netscape Communications Corporation, "Introduction to Public-Key Cryptography"

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/. E-mail: miekg@atoom.net