Choosing a DNNSEC Solution

Beware Dark Zones Ahead


Without DNSSEC, we live in a world of hope. We hope that our web users get to our web site and not that of a hijacker. We hope that email sent to us actually gets to us, and it is not relayed to a malicious third party. We hope when using IM, FTP, VoIP, ***s, and most other services that we are going to the right place, getting data from the right place, and sending data to the right place. DNSSEC-if correctly configured-replaces hope with certainty and provides a feature the Internet has long lacked.

As the progress-worldwide-of DNSSEC accelerates, domain owners are starting to look hard at its implications. First, they want to understand what all the fuss is about-just what is DNSSEC and what does it do for me? Second, domain owners want to understand the options--and consequences--of DNSSEC implementation.

In some cases, the need for DNSSEC is driven by compliance (especially domains, which must be DNSSEC ready by the end of 2009). The need for DNSSEC can also be driven by a desire to increase domain security (particularly when using SSL certificates), by questions from auditors or security experts, or even from that essential human characteristic-insatiable curiosity.

This paper does not make product recommendations but rather focuses on a set of criteria by which domain owners and operators can evaluate the already impressive range of DNSSEC solutions.

The slightly whimsical title of this paper also contains a health warning: DNSSEC is not a trivial technology. One of the consequences of a poor implementation choice is that a domain may become unreachable-in the DNS jargon, the zone may go dark.

This paper mentions the word cryptography. For those already suffering palpitations at the mere sight of this word, have no fear. This paper is an entirely math-free zone. Knowledgeable or impatient readers may want to skip the (mercifully) brief overviews and background material and cut to the chase in section 5.

DNSSEC Overview

The term DNSSEC is, like many others in the technical world, context sensitive. Strictly speaking, DNSSEC is a generic term that describes DNS security and currently covers three functions:

DNSSEC has been available in its current form since approximately 2003. It was formally standardized by the IETF in 2005, with one incremental capability (NSEC3) introduced in early 2008. In this author's opinion, the technology is both stable and mature. There remain operational issues with details that are still being ironed out, but these currently do not have any implications for the underlying technology. Indeed, Sweden-the first operational DNSSEC country in the world-went live with the technology as early as 2005, and it has since been joined by a number of other countries. Most of the major DNS operators and registries have now committed to implementation timescales, the latest of which is scheduled for 2011. The U.S. government is noticeably pro-active in DNSSEC, with initial plans requiring all federal agencies' external zones to be signed by the end of 2009.

What is all the DNSSEC Fuss About?

When a PC user or a peer server connected to the Internet wants to access a service or a resource such as a web site, send an email, or create a VoIP call, it starts with the name of the resource or service that it needs to contact, for example, But networks need IP addresses to function, not names. So the first operation of almost every Internet access is a DNS lookup (a query, in the DNS jargon) to obtain the IP address that corresponds to the name. The lookup process can be quite involved and complex. Hopefully, the result is the correct IP address from the domain's authoritative DNS server or an intermediate caching DNS server. A simplified version of this process is illustrated below.

DNS lookup process - simplified

Figure 1 - Simplified DNS Query and Response Process

There is always Bad News

Every line or system in Figure 1 can be subverted. And without DNSSEC, we have no way of knowing it was subverted. Actually, that last statement is incorrect. When cash is whipped out of our bank account then, for sure, we know something probably went pretty seriously wrong.

But HTTPS solves the problem? SSL certificates solve the problem?

Wrong. Recall that the DNS lookup is the first transaction. If it is corrupted, hijacked, or polluted in some way, then we never get to the real site. All the HTTPS and SSL certificates in the world are simply useless if we don't go to the right place. DNS results really are that important.

DNSSEC is the Good News

DNSSEC (zone integrity) allows us to be certain we reach the right place-we get the right IP address. It does this by providing three key services:

How Does This Magic Work?

DNSSEC works using a cryptographic process coupled with (like SSL certificates) a trust process. If your eyes glaze over at even the sight of the word cryptography, fear not. As previously promised, this is a math-free zone.

The Signing Process

A DNSSEC-secured zone is digitally signed using one or more private key(s) of an asymmetric cryptographic algorithm. Asymmetric encryption systems, such as RSA, elliptic curves, and others, have both public keys and private keys. The public key (as its name suggests) can be made freely available. It can only be used to decrypt information signed by the private key, thus authenticating the source of the data.

A number of new DNS resource records (RRs) are created during the signing process. The public key(s) used to sign the domain are stored in the form of DNSKEY RRs. Each group of DNS records, including the DNSKEY RRs, is signed using one or more of the private keys, and the results are placed in an RRSIG RR. Finally, an NSEC (or NSEC3) RR is added between most RRsets, which are used to provide Proof of Non-Existence (PNE).

The Trust Process

The trust part of the process enables the receiver of the DNS records to track back the public keys until it reaches what is called a trust anchor. As its name suggests, a trust anchor is simply the public key of a domain in the DNS hierarchy which was obtained from a source and using a method (not defined in the DNSSEC standards) that the operator of the DNS trusts. For example, in the case of Sweden, the trust anchor to cover the entire Swedish domain (.se) can be obtained directly from an HTTPS page at IANA (part of ICANN, the DNS governing body).

The tracking-back process may involve navigating a chain of trust, in which the parent zone (the next one up in the name hierarchy) contains yet another new DNSSEC RR called the DS (Delegated Signer) RR. The DS RR corresponds to, and validates, a particular public DNS key. It is typically supplied by the domain owner, though it can be computed by the parent. When used in this type of chain, the parent zone must also be signed. The receiving DNS that is verifying the authenticity of the zone data will have the trust anchor corresponding to the zone name at some point in this chain.

Figure 2 illustrates the DNSSEC process and chain of trust.

DNS Chain of Trust

Figure 2 - Chain of Trust

While the specific example of the .org domain is shown in this Figure for illustration purposes (and because it was one of the first gTLDs to have committed to an aggressive implementation schedule), it could equally apply to any other domain, such as .gov, .se, or .br.

DNSSEC Complexity

The previous section presented a very simplistic overview of DNSSEC. To give a feel for the underlying complexity of the technology, which is essential when evaluating possible solutions, this section lists and briefly describes some of the procedural issues that are required to make DNSSEC viable.

Figure 3 illustrates a hidden master configuration and shows how it may fit into an enterprise environment.

DNS Hidden Master

Figure 3 - Hidden Master Configuration

Choosing a DNSSEC Solution

There are, already, an impressive number of possible solutions for the implementation of DNSSEC provided by both Open Source and commercial organizations. This paper categorizes possible DNSSEC solutions into only two categories, each of which has a high or low rating. The solution attributes in each of the four quadrants of the resulting matrix are briefly described, together with identifying characteristics to help the reader navigate the confusing minefield while still retaining (hopefully) at least one limb.

Applicable Standards

Suppliers of all shades-commercial and Open Source-can use the terms "DNSSEC compliant", "DNSSEC Ready" and "'DNSSEC enabled" rather loosely. The following is a brief checklist of RFCs and other standards that may apply to DNSSEC zone signing solutions, which should be verified as supported based on implementation requirements:

Other compliance standards are outside the scope of this paper, but they should reference one or more of the above RFC standards when defining required functionality.

Choice Matrix

User requirements can vary enormously, and DNSSEC system capabilities vary enormously. Picking a path through this minefield is a question of balancing many competing demands. It is all too easy to get sidetracked into a 'Whizzo feature X' versus 'Whizzo feature Y' war.

This paper is not about specific product recommendations but rather evaluation criteria. The following choice matrix is designed to get to the essence of DNSSEC implementation-everything else is simply fluff-perhaps useful fluff! But still fluff.

DNS DNSSEC Choice Matrix

Figure 4 - The DNSSEC Choice Matrix

The following sections discuss system attributes under each of the quadrants. While on its face it may appear obvious that the ideal solution would lie in the quadrant High Automation, High Key Management, that may not always be practical. In which case, the matrix also indicates missing capabilities that may need alternative provisioning.

Secure Key Management

As noted previously, DNSSEC is about building and maintaining trust relationships. Ultimately, that boils down to security of the private keys. Remote key transactions always use public keys. All the superb cryptographic technology in the world is useless if private keys are simply left lying around or needlessly exposed. This is not a simple problem to solve, especially if Dynamic DNS (DDNS) is being used.

Low Secure Key Management Attributes

Solutions that have any one of the following attributes are classified as Low Secure Key Management:

Note: DNS systems which simply serve signed zones and do not sign the zones should never need to handle private keys and therefore do not require any special treatment.

High Secure Key Management Attributes

High secure key management is generally only possible using hardware assistance- especially if DDNS is being used and private keys are required to be permanently on-line. Where this is neither feasible nor cost-effective, other mitigating strategies are discussed.

Manual Key Handing Mitigation Strategies

If the only option is to use a non-hardware assisted key management system, then there are couple of strategies that can allow such DNSSEC automation solutions to get to a high'ish (but never a high) secure key management level.

That part of a DNSSEC automation solution suite that handles key generation and signing should be synchronized to use the same user/group permissions. Software that generates keys automatically assigns the required minimum permissions. Software that uses private keys always checks that a key has the right (minimum) permissions, automatically sets them if this is not the case, and issues an alert to inform the organization that they have a weak spot in their key handling processes.

Finally, once the key has been used, the software issues an alert to indicate the keys are no longer required and performs a periodic check to make sure it (they) have been removed. Without these minimum safeguards, you may as well start leaving your front door open at home as well.

The important point to consider here is file system accessibility, not the solution packaging. For example, DNS appliances bring multiple benefits by isolating functionality and providing tailored solutions. However, such appliances are normally implemented using Linux or one of the BSD variants, many with unique hardening solutions, and thus have conventional file systems. If the good guys can get into the appliance, then the bad guys can get in as well. If the good guys cannot get into the appliance, the chances are high-but not impossible-that the bad guys will not be able to get in.

The difference between hardware assisted key management and manual key handling apply equally to DNS appliance and non-appliance solutions.

Note: A number of vendors offer thumbprint or other authentication methods to secure access to USB devices. In some case, such devices are even certified to the lower FIPS 140-2 Level 1 or 2 standard. In most cases however, once the authentication process has occurred, the USB file system is freely exposed to the OS. These devices have the characteristics of manual key handing, not hardware assisted key handling.

DNSSEC Automation

DNSSEC involves a number of regular processes and some pretty tight scheduling issues, both of which suggest that the more automation, the less likelihood of something going wrong. And that is the normal case. If things go wrong-such as key compromise-those things need to happen in a hurry. We have all been through enough fire drills to want to avoid them if possible.

Low DNSSEC Automation

Solutions characterized as having low automation have the following characteristics:

High DNSSEC Automation

Solutions characterized as having high automation have the following characteristics:


This paper is not about explicit product recommendations but rather objective evaluation criteria. However, for what they are worth, here are some more subjective considerations and observations.

Many DNS appliance, provisioning system, and even OS suppliers are adding DNSSEC to their product lines. While the DNSSEC technology is mature, the operational practices are still evolving. What to send to who, in what format, when, etc., are all still open questions. Vendors need to keep track of what is still a moving target and be committed to keep abreast of developments. DNSSEC cannot be an afterthought or buzzword to flush out a product line. The consequence of failure could be a dark zone-you need a committed DNSSEC vendor.

If you are forced to make a trade-off within the choice matrix, in this author's opinion, good secure key management trumps good automation every time. You can always learn more about DNSSEC or carry out some manual process, but you might not even know about stolen or compromised keys-until it is too late. Better the known than the threat of the unknown.

Questions to Ask Your DNSSEC Vendor

Hopefully, the criteria offered in section 5 have already provided lots of vendor questions and areas for detailed follow-up; however, here are a few explicit questions you might want to ask your potential DNSSEC vendors in order to determine which type of solution they offer:


DNSSEC is a mature technology that can be implemented now with little if any risk. Substantial benefits can be derived from the technology immediately, especially where verified access is required for either intra- or inter- organizational communications-be they government, supplier networks, or any other community of interest or affinity grouping. With the pace of DNSSEC implementation accelerating, as it currently appears to be doing, the benefits will only increase. You may also, as an additional benefit, keep auditors, unhappy users, and regulatory authorities off your back.

Finally, the integrity of the domain within a DNSSEC environment is determined by the care with which an organization handles its private keys. While pre-DNSSEC secure DNS solutions (for zone updates and zone transfers) have always demanded some form of secure key management, these were usually not extreme and the consequences of failure were at worst limited to a small and finite number of users.

DNSSEC places a premium requirement on secure key management. The importance of this point cannot be over-emphasized. The actual process of signing and maintaining DNSSEC signed zones, while complicated and containing some nasty timing criteria, is ultimately procedural. The key (pun intended) requirement of any DNSSEC software automation solution is how it manages private keys. There is almost no alternative, especially if Dynamic DNS (DDNS) is being used, other than to use key management hardware-a tamper-proof or tamper-evident cryptographic module-as part of a total solution. Less than this exposes the user to significant down-side risks, which at best negate all of the substantial advantages DNSSEC offers, and at worst could result in an unreachable-a dark-zone.

Pro DNS and BIND by Ron Aitchison


tech info
guides home
dns articles
1 objectives
big picture
2 concepts
3 reverse map
4 dns types
5 install bind
6 samples
7 named.conf
8 dns records
9 howtos
10 tools
11 trouble
12 bind api's
13 dns security
bits & bytes
15 messages
notes & tips
registration FAQ
dns resources
dns rfc's
change log