The ISP Column
An occasional column on things Internet
Other Formats:    

DNSSEC - A Review
June 2010

Geoff Huston

After many years, the root of the DNS is evidently going to be signed in the coming weeks using DNSSEC with a verifiable root key, or at least that's the plan if the National Telecommunications and Information Administration of the United States Federal Department of Commerce follow through with their proposed actions that have been foreshadowed in the Federal Register of the United States bureaucracy of Wednesday, 9 June 2010. It will all happen by July 15 2010, if all happens in accordance with the plans outlined in that notice, and on that date we should have a DNSSEC-signed root of the DNS. Given that this is an event that has taken more than fifteen years to come to fruition, I thought it might to useful to have another look at DNSSEC to mark this long anticipated milestone.

Figure 1 The View of DNSSEC in 2006 - T-Shirt by Olaf Kolkman

DNSSEC and the DNS

In looking at the general topic of trust and the Internet, one of the more critical parts of the Internet's infrastructure that appears to be a central anchor point of trust is that of the Domain Name Service, or DNS. The mapping of “named” service points to the protocol-level address is a function that every Internet user relies upon, one way or another. While almost every single user transaction deals with names, such as, every single network packet has to deal with protocol level addresses, such as or 2401:2000:6660::2.

Given that every single Internet user and every Internet service provider ultimately relies on the integrity of the DNS, then how is the DNS itself protected against malicious attack? If the DNS is the cornerstone upon which the integrity of operation of all other user level Internet applications are constructed, then how can we be assured that the DNS itself is working as intended?

The ability to corrupt the operation of the DNS is one of the more effective ways of corrupting the integrity of Internet-based applications and services. If a malicious attacker can, in some fashion, alter a DNS response without being detected, then a large set of attack vectors are exposed.

For example, an altered DNS response may cause some users of your service to believe that your online services are associated with the addresses of the attacker's servers. For those unfortunate users who attempt to communicate with your servers, their traffic will be redirected by the DNS to communicate with the attacker's servers. While at one level this can appear to be simply an annoying piece of vandalism, when the same form of attack is directed against financial services or critical public emergency services or other forms of valuable or critical service elements, then this is an extremely serious form of attack with serious financial or even political implications. Web servers, email, VOIP services, and indeed any service where the initial rendezvous is made through the DNS is vulnerable to such forms of attack on the DNS, and most services do indeed rely on the DNS.

The DNS was designed as a widely distributed database to enable it to scale and to perform extremely efficiently under a wide variety of operational conditions. There are, unfortunately, many ways in which the Internet's name resolution function is vulnerable to attack, and it appears that the DNS has been the subject of many forms of attack over the years. However, the purpose of this article is not intended to be a collection of recipes on how to attack the DNS, or even a description of the weaknesses of DNS. RFC 3833 contains an excellent summary of the vulnerabilities in the DNS [RFC3833].

Figure 2 Potential Vulnerabilities in the DNS

The more useful question here is whether it is possible to strengthen the DNS such that such efforts to corrupt the DNS are detectable. The DNS is a query-response application, and the critical question in terms of strengthening its operation is whether it is possible to authenticate the responses provided by the DNS. The question of "securing" the DNS becomes one of establishing whether it is possible to add some form of credentials to DNS responses that would allow the client to check that the data provided in the response corresponds exactly to the data as it was entered into the authoritative zone. The client would like to validate that they have received the entirety of the answer, and that no part has been altered in any way.

The way DNSSEC achieves this is through the use of public key cryptography and digital signing of DNS data. When data is entered into the DNS via the original zone data, the zone data is signed by the zone administrator. When the client performs a DNS query, the signature is provided to the client as part of the DNS response, and the client can verify the signature and in so doing be assured that the response is an accurate representation of the original zone data.

Figure 3 DNSSEC and the operation of the DNS

What is DNSSEC?

In answering this question, it may first help to look at what DNSSEC is not.

DNSSEC is not a security panacea. It is not a robust defence against all forms of attack against DNS servers and clients. DNSSEC is not an exercise in encryption of DNS data. Within the scope of DNSSEC, DNS protocol interactions remain in the clear, and DNS transactions can be prone to eavesdropping with DNSSEC. DNSSEC does not attempt to construct secured private DNS realms that are protected from third party inspection. Encryption of DNS exchanges using mechanisms such as TSIG for data protection between DNS servers (see RFC 2845), address a different set of functional objectives than that of DNSSEC. DNSSEC does not support secure communications channels between clients and resolvers, nor between primary and secondary servers of a domain. DNSSEC does not prevent various forms of DNS denial of service attacks, nor does it prevent the DNS being used as part of an amplification attack.

The DNSSEC objective is a tightly focused objective of allowing clients to authenticate the contents of a DNS response. It is focused on allowing a client to detect various forms of "man-in-the-middle" attacks where the attacker has modified the original information that is in the authoritative zone file. It does not prevent the possibility of such an attempt to manipulate a DNS response, but it is intended to allow a client to detect that such an alteration of a DNS response has occurred. Again this is not a universal level of protect, but one that is qualified such that the detection is possible in those cases where evidence that the DNS zone from which the DNS response has been assembled has been DNSSEC-signed is still visible to the client.

DNSSEC is a specification of an extension to the DNS through the definition of additional DNS Resource Records (RRs) that can be used by DNS clients to validate the authenticity of a DNS response, the data integrity of the DNS response. In addition, where the DNS response indicates no such name, or no such resource type exists, DNSSEC allows for this negative information to also be authenticated by the client. In other words, if an attacker attempts to create a DNS response that substantively differs from the original authentic response in some fashion, and the attacker then attempts to pass the response off as an authentic response, then a DNSSEC-aware client should be able to detect the fact that the response has been altered and that the response does not correspond to the authoritative DNS information for that zone.

A succinct summary of the problem that DNSSEC is intended to address is that DNSSEC is intended to protect DNS clients from believing forged DNS data.

The way this is achieved in DNSSEC is by using public key cryptography (see Appendix I). The DNS zone administrator digitally signs every Resource Record set (RRset) in the zone, and publishing this collection of digital signatures, along with the zone administrator's public key, in the DNS itself. DNSSEC does not make use of Digital certificates or any other form of external credentials. The intention with DNSSEC is to publish all the necessary security credentials in the DNS itself, and use the DNS for both the storage of such security credentials and the means of distribution of this information.

In checking a DNS response for a given RRset, a DNSSEC-aware client can retrieve the related digital signature RRs and then check this signature using the zone administrator's published public key against the locally calculated hash value of the RRset. The client can then validate the zone administrator's public key using a hierarchical signature path that leads to a point of trust. If all these checks succeed than the client has some confidence that the DNS response was complete and authentic.

To achieve its objective, DNSSEC defines a number of new DNS RRs, namely the DNSKEY, RRSIG, NSEC and DS RRs (see Appendix II). DNSSEC also introduces two new message header bits: checking Disabled (CD) and Authenticated Data (AD), and it uses functions provided by Extended DNS mechanisms (EDNS). This creates a backwards compatible extension to DNS.

Implementing DNSSEC implies different actions for different roles. For a DNS zone administrator, DNSSEC is essentially the process of signing all RRsets with a private key, publishing these signatures for each RRset in the zone file, and also publishing the public key in the zone file. In addition the zone administrator has to ensure that the zone's public key is signed by the parent zone administrator and published in the parent's zone. For a parent DNS zone administrator DNSSEC also includes the task of validation of the DNSSEC zone's public keys of the zone's children, signing over them using the zone's private key, and publishing this material as RRs in this DNS zone. For a DNS client DNSSEC is the ability to perform a number of additional checks on a DNS response that can result in greater trust in the authenticity and accuracy of the DNS response. And for the DNS itself, DNSSEC essentially represents a number of additional Resource Records that hold digital signatures of DNS information, as well as key information.

The technical specifications for DNSSEC are in RFC4033 (Security Requirements), RFC4034 (DNSSEC Resource Record Types) and RFC4035 (DNS Protocol Modifications). Further specifications related to the NSEC RR are in RFC4470 (Epsilon Functions for NSEC responses) and RFC5155 (NSEC3 Resource Record). RFC4641 describes DNSSEC operational practices.

How does DNSSEC work?

When requested by the client in the DNS query, the authoritative DNS server will add additional DNSSEC data to the DNS responses. This additional data is, in effect the digital signature of the DNS data contained in the response. This is intended to allow the DNS client to authenticate the DNS response. The way in which this is done is by the addition of a RRSIG part to the additional data of the DNS response. If there is no authoritative DNS data to respond to the query, such as when no such domain name exists, then the DNS response will include an NSEC RR response, plus its accompanying RRSIG record. In addition to an RRSIG response covering the RRset records in the answer section of the DNS response, there is also an RRSIG response covering the records in the authority section and one or more RRSIG responses relating to records in the additional response section.

The first task that the DNSSEC-aware client should perform is to use the RRSIG data to check the validity of the DNS response. To do this the client can take the RRset response and use the algorithm referenced in the RRSIG record to generate the hash of the data. The second task is to take the RRSIG value and encrypt it using the DNSKEY public key. To do this the client must also have at hand the DNSKEY record for the zone. This will result in decrypting the hash in the RRSIG record. The results of these two operations are now compared. If the DNS response is authentic then the hash of the RRset data will match the decrypted RRSIG hash value.

The DNSKEY RR would normally be provided as part of the additional section of a DNSSEC response. If the client has not already validated the DNSKEY within some locally defined period, then the client should also validate the DNSKEY value.

The DNSKEY may match a local trust anchor, in which the DNSKEY can be accepted without further tests. Otherwise the DNSKEY RR will need to be validated.

This validation procedure entails verifying the RRSIG record associated with the DNSKEY RR, using the same procedure as described above for other RRs. However domain zone key validation also entails the construction of a trust chain back to a trust anchor point. If this domain key is not already a trust anchor then the client needs to query the parent zone for the DS record of the child zone. This DS query should return both a public key value as the value of the DS RR, an RRSIG RR associated with the DS RR, and a DNSKEY RR for the parent zone. The DS RR can be validated against the RRSIG RR, using the public key contained in the DNSKEY RR. This public key, in turn, must be validated. This iterative process constructs a trust chain that, hopefully, leads back to a locally configured trust anchor. At that point the DNS response can be considered to be validated.

Figure 4 - DNSSEC val;idatin framework

DNSSEC: For and Against

There are some very useful properties of this DNSSEC approach to the use of public key cryptography to the DNS.

Record Level Granularity

Signed "No Data" Responses

Validation exploits the DNS delegation hierarchy.

DNSSEC is not without some additional issues that change the nature of the DNS and have some significant implications for it's performance.

Larger Zone Files

Larger Responses

More Queries

Higher Client Overhead

Higher Server Overhead

Increased Potential for Zone Administration Errors

The use of absolute times in the RRSIG records imposes a new regime of some level of time synchronization across the DNS as part of the signature validation process. Previously, DNS had only a concept of elapsed time, whereas in DNSSEC if a client has a skewed concept of time it may believe that expired signatures are still valid. If a zone administrator has a skewed time then the signature validity timestamps it generates in its RRSIG records would be incorrect.

Zone Enumeration with NSEC RRs

DNSSEC Deployment

Deployment of DNSSEC has been quite piecemeal and it has yet to gather any significant momentum so far. There are a number of reasons why this is the case.

The first, and perhaps the hardest, is that the Internet of today is now a very large system, and every large system tends to resist change. Any change, and particularly a change to a technology that is as universally pervasive as the DNS, will take time, and the larger the realm of deployment, the longer the period to get to a critical mass of deployment.

There are a few other issues with DNSSEC that hinder deployment. One is that the economics of DNS deployment do not work directly in favour of DNSSEC. It would be good if a security measure could create outcomes that were simpler, cheaper and more robust, as well as creating mechanisms to deflect various forms of hostile attack. DNSSEC cannot readily be described in such terms. There are additional tasks placed on the zone administrator, additional load placed on DNS servers, additional responsibilities placed on DNS clients, and the potential for additional tasks to be undertaken by applications. Even in such a situation, deployment proceeds where the cost of the measure is offset by direct benefits achieved through the measure. Here it is not clear that there is a cost and benefit equation at work for each player. The DNS zone administrator inherits a significantly more complex issue, for the existing issues of securing the DNS servers and ensuring that they can resist various forms of attack do not go away with DNSSEC, and on top of that DNS places an additional workload of key management and signature generation for each change to the zone. The benefits that arise from this additional cost in zone administration are not readily apparent to the DNS zone administrator or to the DNS server system administrator. The initial benefit would appear to accrue to the client, whose additional work in validating the DNSSEC responses would lead to a greater level of confidence in the accuracy in the DNS. When cost and benefit are decoupled to such an extent there is often significant impediment to widespread deployment as a consequence.

It is also possible that an indirect benefit of DNSSEC is that the DNS is able to be used as a relatively efficient means of distribution of authenticable data. There is a well established and high value certificate-based reputation industry. One potential use of DNSSEC is to provide an alternate distribution and verification framework for short data items, as a potentially lower cost alternative to certificate-based frameworks. However the history of the DNS is full of inventive proposals to extend the DNS in various ways, and the number of successful and widely adopted extensions is far lower than the number of proposals, so the likelihood of DNSSEC assuming a broader role in service security and integrity and superseding much of the role currently undertaken by certificate-based frameworks is at best a remote possibility.

The other part of the consideration of the economics of DNSSEC deployment is the observation that all security measures are ultimately an exercise in risk evaluation, and the cost of deployment of the measure has to be evaluated against the practical probability of attack and the potential consequent costs of the attack. DNS cache poisoning is not a prevalent form of attack in current DNS implementations, and DNS resolvers are relatively adept at resisting various forms of cache poisoning. That does not imply that the DNS without DNSSEC is perfect in this respect, indeed far from it, but it does make the business case for deployment of DNSSEC one that requires some considerable thought. However it should also be remembered that the costs of a successful attack in the DNS are potentially quite considerable.

The other aspect of DNSSEC that appears to be a hindrance rather than an asset is that piecemeal deployment of DNSSEC makes DNSSEC resolution harder in some respects rather than easier. The issue here is that of the identification of trust anchors in the key chains. DNSSEC does not permit indirection of any form, and either the zone's immediate parent must be in a position to countersign the zone's public key signing key, or the zone must become a trust anchor in its own right. Now if everyone adopted DNSSEC the task of the client would be very straight forward: load the key signing key of the root zone of the DNS into DNSSEC and everything else will validate indirectly via a signing chain against that single trust key. But when there is only piecemeal deployment then a client needs to track down all the instances of local trust points where there is no "upward" signature link back towards the root zone. This poses some quite difficult practical questions: How does a DNS client establish a trusted relationship with all the current DNSSEC signed zones which have no immediate DNSSEC delegation parent? How does a DNS client become aware of zone key rollovers of these trust points? How can this process be managed in some automated fashion outside of the DNS delegation hierarchy? What is the potential role of intermediaries in this process? Who can a client tell between a genuine intermediary and a malign intermediary?

And, of course, there is the ultimate issue of use of DNSSEC. It has been commonly reported that when a browser generates a pop-up screen warning that a browser certificate has expired and requesting whether the user wishes to proceed in any case, the common response is for the user to simply request the application to proceed! What form of application behaviour would be appropriate in the case of a DNSSEC validation failure? In applications that are intended for direct interaction with a human end user, then there is always the option of a dialog box and some user direction as to how to proceed. But DNS resolution occurs in many contexts, and it is often the case that there is no option to enter into a user dialog as to how to proceed. Should an application deliberately fail if DNSSEC validation fails? Would widespread use of DNSSEC be opening up a new form of denial of service attack by deliberately corrupting a DNSSEC response in order to trigger application failure on the end system?

On the other hand, there is the view that exposure of vulnerabilities leads inexorably to exploitation, and leaving the DNS without the form of data protection provided by DNSSEC will inevitably lead to more prevalent forms of exploitation. From this perspective measures to allow a client to validate that a DNS response is authentic and complete is a valuable tool, and deployment experience with DNSSEC should stimulate the creation of DNS zone management tools that master the inherent complexities of this technology.

Where are we now?

DNSSEC is a standards-based mechanism that allows a client to validate DNS responses. It can expose attempts to pass off false DNS data as authentic using an approach of incrementally signed data and an interlocking hierarchy of signing keys to allow data verification. DNSSEC is a backwards compatible extension of DNS, and it works entirely within the existing structure of the DNS.

However, DNSSEC will work best when we all use it. In such a scenario of universal adoption clients will need to be equipped with a simple single local trust key that will "unlock" the entire key hierarchy of the DNS. If everyone uses DNSSEC we will not need to rely on the integrity and good intentions of a bevy of intermediate crypto key brokers to assemble useful and current lookaside lists to compensate for the lack of a complete interlocking structure of DNS zone keys.

And here "everyone" really means "everyone, from the root all the way down". Within a few days from now the root of the DNS will be DNSSEC signed with a verifiable key. A critical part of the scenario of universal adoption of DNSSEC, that of the apex of the key hierarchy will have been achieved. But when and how will the other parts of the DNS follow? Some DNS registrars are currently offering DNSSEC DS key registration as an extra cost option for name holders. While this provides some marginal incentive from the registration side for DNSSEC adoption, its difficult to see the path towards universal use of DNSSEC taking off when many of the incremental costs are loaded onto the name holder and the zone administrator while the majority of the benefits of adoption of DNSSEC lie in the intangible area of risk mitigation on the DNS client side.

So the signing of the root of the DNS does not in and of itself cure the DNS of all known security pitfalls. This particular root zone signing lifts the expectation that widespread adoption of DNSSEC is a feasible ambition, but its not the complete solution by any means.

It is perhaps more realistic to view the signing of the root of the DNS as one more milestone, albeit a very important and significant milestone, in a far longer DNSSEC path, rather than thinking that we've reached the ultimate destination of this particular journey.


References and Further Reading


Appendix I

Public Key Cryptography and PKIs

One of the longstanding approaches to this question of authenticity of data is that of public key cryptography.

Communications networks support interaction at a distance. I can't touch you, see you, or hear you, nor can you touch, see or hear me, yet we need to exchange information, or messages. When I receive a message from you, how can I be absolutely sure that it was you who originally sent it? How can I be assured that the message has not been tampered with? How can I be assured that you cannot subsequently deny that you sent this message? And if the message was intended to be a private communication between just the two of us, then how can we ensure that no one else other than myself, the intended recipient, can read this message?

None of these objectives relating to the authenticity and secrecy of communications are particularly novel, and the various forms of response to these rather demanding requirements over the years form the rich and colourful history of cryptography.

A common means of assuring communications is through the use of shared secrets. If you and I can meet in some secure location, and swap a collection of secret "keys", or cryptographic seeds, then I can encipher my messages to you using my private enciphering key and then pass the result into a second encipher process using your shared secret encipher key. If anyone else intercepts the message it is intended to be unintelligible. When you receive my message you first decipher it with your private decipher key, and then decipher the result with my shared decipher key.

This model of secure communication using shared keys still not very useful in the real world. It is not clear that we are ever able to actually meet and exchange keys, nor is it clear that we are able to meet every time I want to replace my keys, or you wish to replace your keys.

Some terminology that may help at this juncture: If the key is symmetric the encipher and decipher keys are the same. If the key is asymmetric the encipher and decipher keys will differ. The asymmetric keys may be one way, in which case the decipher key can only decipher material that was enciphered by the corresponding encipher key, or they may be two way in which case either key can be used to encipher material that only the corresponding partner key can decipher.

What we would like is an asymmetric two way key pair, such that messages enciphered using one of the keys can only be deciphered using the other key, and knowledge of one key can never lead to deducing the value of the other key in the pair. If one key value is kept as a closely guarded personal secret, and the other is made public knowledge, then we have managed to provide a useful framework for secure messages.

This form of key pair is very useful. If I encipher a message using your public key, then only your private key can decipher it. Anyone who intercepts the message cannot make any sense of it, as they do not possess your private key. Similarly, if I encipher a message using my private key, then only my public key can decipher it. While anyone is then able to decipher the message, the value here lies in the ability to authenticate the fact that only I could've enciphered the message as I am the only person who has possession of my private key.

Now, if I use my private key to encipher a message, and then encipher the result using your public key, then I have constructed a message that only I could've generated and only you can read. And for you to read it, you need to use your private key to decipher the message, and then use my public key to decipher that message to end up with the original message. In other words such a system allows for secrecy and authenticity. Importantly, neither of us have had to use a shared secret. I only need to have knowledge of your public key, together with my secret private key, to construct the message, and you only need to have knowledge of my public key, together with your secret private key, to decipher the message. We don't have to meet to share a secret, and I can conduct secure conversations with many different folk using my single private key and their respective public keys.

So now we know how useful such an asymmetric two way key system can be, do such keys actually exist?

One of the keystones to public key cryptography lies in the area of modular mathematics. Imagine two functions, f() and g(), that are related such that one is the logical inverse of the other. Applying function f() and then function g() to a value will result in the same original value. Equally, the same result happens when applying g() and then f() to the value. i.e. x = f(g(x)) = g(f(x)). For example, the pair of functions can be f(x) = x + 1 and g(x) = x - 1.

Now lets add a further constraint, namely that knowledge of one function provides no useful clue as to the other function. Simple additive and multiplicative functions fail with this latter constraint, as do exponentiation functions. However, an example of such a pair of functions can be constructed using exponentiation modulo a prime value. The basic mathematical property that is exploited by public key cryptography is given a prime integer p, and a primitive g, then (ga mod p)b = (gab) mod p = (gb mod p)a.

Now we appear to be getting close to a desired outcome, with a pair of functions which are the inverse of each other, but where knowledge of one function does not necessarily allow one to deduce the inverse function. In this case the function itself can be made public, as can the parameter for the initial transform, while the parameter for the inverse operation can be kept secret. Using the above function of exponentiation using modular arithmetic with a prime base, then the calculation of the inverse parameter value is similar to the calculation of prime factors. For extremely large integer values this problem will take an exceptionally long time to compute.

Back to the private / public key pairs, as long as you are confident that the public key that you believe is mine really is mine, and that I have been careful and never divulged my private key to anyone else, then we can set up a secure communication. I can send you messages that are encrypted using my private key, that only I could've generated, as only my public key 'unlocks' the message, and I cannot subsequently repudiate that I was the author of the message. If I apply a second encryption pass using your public key over the message once I've used my private key, then only your private key can unlock this operation, resulting in a tamper-proof message that only I could've sent and only you can read.

It would appear that the critical assumption behind this operation is that the public key that you believe is my public key really is my public key, and not that of anyone else. How can you be more confident about this assumption? This is perhaps the most significant question in any public key cryptography system. Again if we could meet, and exchange credentials and public keys then the problem is solved for a while, or at least until either you or I choose to re-key. But what if we can never meet? How can we trust the authenticity of our alleged public keys?

The perennial issue in public key cryptography is that of the means of validation of the public key. If an attacker manages to intercept all your traffic, signs responses using their own private key and represents their public key as that of the party you thought you were communicating with, then how are you to tell that the communication has been corrupted? In public key cryptography the conventional answer is to find other parties who are willing to attest as to the validity of a public key, and find yet more parties who are willing to attest as to the validity of the first group of attesters, and so on until you find a link with a party that you feel able to trust. Assuming that trust is a transitive quantity (always a risky assumption of course), then you can construct a chain of trust from your trust point to the party whose public key you are attempting to validate.

This can be generalized into an approach of using chains of knowledge and role authorities to create chains of trust. If you and I both trust some third party, and this same third party is willing to vouch for my public key, then you have some grounds to trust my public key, as long as you trust this intermediary third party. This chain of trust indirection can be lengthened so that you trust party A, who trusts party B, and so on, and I trust party Z, who trusts party Y, and so on, then if these two chains of trust intersect, then we may have grounds to believe the public key assertions.

There are various ways to construct such chains of trust, using strict hierarchies, using arbitrary bilateral trust relationships, such as a "web of trust" model, or using a collective trust thresholds. The resultant structure of trust relationships and associated credential relationships, whatever its chosen form, is generally collectively referred to as a public key infrastructure, or PKI.

A PKI allows a set of parties, who adhere to a set of common operational practices and policies that collectively define the PKI, the ability to validate the association of a particular entity with a given public key value.


Appendix II

DNSSEC Resource Records

DNSSEC introduces four additional RRs to carry security information. These resource records are:



The Signature field contains the cryptographic signature that covers both the RRset specified by the RRSIG owner name, RRSIG class, and RRSIG Type Covered field and the the RRSIG RDATA itself.

An example RRSIG record for the zone is as follows: 86400 IN RRSIG A 5 3 86400 20030322173103 (
                                  20030220173103 2642
                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )


NSEC records can be used to enumerate the entire contents of a zone file. While DNS data is public information, there is some concern over the implicit publication of the entire zone in this manner. We'll come back to this with the NSEC3 RR.




Appendix III

A DNSSEC Worked Example

The following is an example walk-through of the creation of a DNSSEC-signed zone using the suite of tools provided wit release 9.7.1 of the DNS BIND software from ISC ( I'll use as a guide for this worked example the "DNSSEC HOWTO" tutorial by Olaf Kolkman (

The zone we'll sign here is

The first step is to ensure that the zone's servers are capable of supporting DNSSEC. The way to achieve this will vary according to the DNS Server software being used.

In the case of the BIND server, the essential first step is to compile the software with openssl, and enabling the use of DNSSEC with the "dnssec-enable yes;" directive as part of the options specified in named.conf.

$ cat /etc/namedb/named.conf
options {
      dnssec-enable yes;

The next step is key creation. Common operational practice today is to use two distinct key functions: the key-signing keys (KSKs) as the anchor point of the chain of authority to the data that needs to be validated, and zone-signing keys (ZSKs) that are used to sign the zone data.

In the case of BIND, this can be achieved using the dnssec-keygen command, creating a zone signing key, then a key signing key.

$ dnssec-keygen –r /dev/random -a RSASHA1 -b 1024 -n ZONE

$ dnssec-keygen –r /dev/random -f KSK -a RSASHA1 -b 1280 -n ZONE 

The public key parts of these key pairs are added to the zone to be signed.

$ cat
; example dnssec-signed zone
$TTL	1d
@  	IN	SOA	dns0.potaroo.netnet. (
	2010062101	; Serial
	3h		; Refresh
	1h		; Retry
	1w		; Expire
	3h )		; Neg. cache TTL

;	name servers
;	zone contents
bogong  A
bogong  AAAA	  2401:2000:6660::6
wally   A
wally   AAAA    2001:388:1:4007:20e:cff:fe4b:f987
;          zone keys
$include     ; KSK
$include     ; ZSK

The zone is then signed, using the dnssec-signzone command.

$ dnssec-signzone -r /dev/random -o \ 
                  –k \

Verifying the zone using the following algorithms: RSASHA1.
Zone signing complete:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                    ZSKs: 1 active, 0 stand-by, 0 revoked

The signed zone is as follows:

$ cat 
; File written on Mon Jun 21 02:49:13 2010
; dnssec_signzone version 9.7.1	86400	IN SOA	dns0.potaroo.netnet. (
					2010062101 ; serial
					10800      ; refresh (3 hours)
					3600       ; retry (1 hour)
					604800     ; expire (1 week)
					10800      ; minimum (3 hours)
			86400	RRSIG	SOA 5 3 86400 20100721014913 (
					20100621014913 16482
					JS0yeDkb3BM0fikwbevTUjrqOB8= )
			86400	NS
			86400	RRSIG	NS 5 3 86400 20100721014913 (
					20100621014913 16482
					bDzLjMFXFTVtwn9Vk9rbZmLsEyM= )
			10800	RRSIG	NSEC 5 3 10800 20100721014913 (
					20100621014913 16482
					hStzqMOLlc4Rcu30LQO1zGqtHc8= )
			86400	DNSKEY	256 3 5 (
					) ; key id = 16482
			86400	DNSKEY	257 3 5 (
					) ; key id = 64273
			86400	RRSIG	DNSKEY 5 3 86400 20100721014913 (
					20100621014913 16482
					HPMja4kFAnhd/lRjR85tcKOlk7I= )
			86400	RRSIG	DNSKEY 5 3 86400 20100721014913 (
					20100621014913 64273
					+b5tcHdYIGT7My4ELbdc0nn2BYuQAGjx0g== ) 86400	IN A
			86400	RRSIG	A 5 4 86400 20100721014913 (
					20100621014913 16482
					l0lRT1lEC/SUBjb2w45aYzIo/cA= )
			86400	AAAA	2001:388:1:4007:20e:cff:fe4b:f987
			86400	RRSIG	AAAA 5 4 86400 20100721014913 (
					20100621014913 16482
					UsbJ0vHTEjGbpHP2gR/M9JLUfwc= )
			10800	RRSIG	NSEC 5 4 10800 20100721014913 (
					20100621014913 16482
					ZL0X92Rxo6cG+BLrEoJrx8DG4qg= ) 86400 IN A
			86400	RRSIG	A 5 4 86400 20100721014913 (
					20100621014913 16482
					X3Em9kX7lYK4xUh3bdnb003VosE= )
			86400	AAAA	2401:2000:6660::6
			86400	RRSIG	AAAA 5 4 86400 20100721014913 (
					20100621014913 16482
					6lvMAhswVnJ+uLloiSW1uH87YI8= )
			10800	RRSIG	NSEC 5 4 10800 20100721014913 (
					20100621014913 16482
					t4CsezFvupSVU6mBQC0NsWiTeIM= )

The signed zone is added to the set of served zones, and the BIND server configuration is reloaded.

$ tail -5 named.conf

zone "" { 
        type master; 
        file "master/" ; 

$ kill –HUP `cat /var/run/named/pid`

The KSK is added to the set of local trust keys for a DNSSEC-aware resolver:

$ cat named.conf
trusted-keys {
""        257 3 5 "AwEAAdmfkEMaaUrwh3+vxkTlvcn+2KJLC/

This resolver can be queried:

$ dig +dnssec +multiline DNSKEY

; <<>> DiG 9.7.1 <<>> +dnssec +multiline DNSKEY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42734
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags: do; udp: 4096

;; ANSWER SECTION:	86400 IN DNSKEY	256 3 5 (
				) ; key id = 16482	86400 IN DNSKEY	257 3 5 (
				) ; key id = 64273	86400 IN RRSIG DNSKEY 5 3 86400 20100721014913 (
				20100621014913 16482
				Vy1ns4fXkQpfHPMja4kFAnhd/lRjR85tcKOlk7I= )	86400 IN RRSIG DNSKEY 5 3 86400 20100721014913 (
				20100621014913 64273
				JHyg+b5tcHdYIGT7My4ELbdc0nn2BYuQAGjx0g== )

;; Query time: 205 msec
;; WHEN: Mon Jun 21 07:30:11 2010
;; MSG SIZE  rcvd: 763

The "ad" flag in the response indicates that the response was authenticated using DNSSEC. The local resolver's log also shows this local validation result:

$ more named-dnssec.log 

21-Jun-2010 07:30:11.207 dnssec: debug 3: validating @0x8028f6b00: DNSKEY: 
21-Jun-2010 07:30:11.207 dnssec: debug 3: validating @0x8028f6b00: DNSKEY: 
                                          attempting positive response validation
21-Jun-2010 07:30:11.207 dnssec: debug 3: validating @0x8028f6b00: DNSKEY: 
                                          verify rdataset (keyid=64273): success
21-Jun-2010 07:30:11.207 dnssec: debug 3: validating @0x8028f6b00: DNSKEY: 
                                          signed by trusted key; marking as secure


The above views do not necessarily represent the views of the Asia Pacific Network Information Centre.

About the Author

Geoff Huston B.Sc., M.Sc., is the Chief Scientist at APNIC, the Regional Internet Registry serving the Asia Pacific region. He has been closely involved with the development of the Internet for many years, particularly within Australia, where he was responsible for the initial build of the Internet within the Australian academic and research sector. He is author of a number of Internet-related books, and was a member of the Internet Architecture Board from 1999 until 2005, and served on the Board of Trustees of the Internet Society from 1992 until 2001.