You don’t have to wait to deploy DNSSEC

Overview of DNSSEC

DNSSEC (Domain Name System Security Extensions) is a suite of specifications which implement record signing to ensure the integrity of certain types of transactions. It uses both asymmetric and symmetric cryptography for RR (Resource Record) or zone transfer transactions, respectively. To ensure the authenticity of information received by a resolver, DNSSEC provides the following (Wikipedia.org):

• Origin authentication of DNS data

• Data integrity

• Authenticated denial of existence

These capabilities are added to the existing DNS framework by using a new set of resource record (RR) types, including (nominet.org.uk):

• DNSKEY contains the public key used to sign the data in a secure zone.

• NSEC shows the interval between names in the zone. These are used in DNSSEC for ‘authenticated denial of existence’ of an address.

• RRSIG contains the signature of other RR types in the zone, including DNSKEY and NSEC. For each set of RRs for which the zone is authoritative, there exists a corresponding RRSIG RR. (An RR set, or RRSet, consists of RRs with the same name, type, and class values. All records in an RRSet are signed with the same signature.)

• DS (Designated Signer) RRs contain hashes of the keys of child zones. They’re used to build the chain of trust central to DNSSEC integrity protection.

Figure 1 shows a DNS host RR with its associated signature. When a resolver using DNSSEC receives this information in response to a name resolution query, it uses information contained in the RRSIG RR (contents of Key Tag and Signer’s Name fields) and the sender’s public key to validate the signature.

Figure 1
(nominet.org.uk)

Securing DNS with DNSSEC begins with establishing a chain of trust. Resolvers use ‘anchor keys’ to verify parent domains, beginning with the trust anchor. The trust anchor is the foundation of any chain of trust.

The public key (of the Trust Anchor) is used to verify digital signatures and the associated data. Furthermore, the public key is used to constrain the types of information for which the Trust Anchor is authoritative.

A relying party uses Trust Anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor’s public key, and by enforcing the constraints expressed in the associated data for the trust anchor. (Wikipedia.org)

In an ideal world, the DNS trust anchor for the Internet consists of the root name servers. However, there are issues.

DNSSEC Challenges

There are two categories of challenges when trying to design and implement global DNSSEC security. The first consists of technical and security issues, including (Wikipedia.org & ISC):

• There is a problem with DNSSEC’s reporting of names not present in a signed zone via the NSEC RR. It allows enumeration of zone contents. However, NSEC3 is expected to resolve this issue.

• An effective method of dealing with trust anchor key rollover has not been defined.

• Earlier versions of DNSSEC had issues. This adversely affected confidence in the ability of DNSSEC to improve DNS integrity without introducing other, potentially worse, problems.

• DNSSEC will increase DNS traffic with more requests and larger responses. Domains with high volume traffic should prepare for increased bandwidth needs.

• DNSSEC is more sensitive to time issues than standard DNS. System clocks must be reasonably accurate.

Although these five problems are important, they are minor when compared to the second set of challenges, challenges related to political posturing and mistrust, including (Wikipedia.org):

• The U.S. wants to control the trust anchor keys for the root name servers. Other countries are concerned this would give the U.S. too much control over the Internet. Centralized control by any one country is probably not acceptable to many nations.

• It’s unclear how ICANN would handle delegation of names to TLDs managed by entities with which it has no formal agreement, such as .ca.

• Some governments are encryption averse. Will they try to ban DNSSEC-backed encryption key distribution?

Some security and Internet professionals are using these challenges as a reason to not implement DNSSEC. The assumption is that it can’t be used without global acceptance. But global acceptance is not necessary to begin making DNS more reliable.

Islands of trust

Even without global implementation, DNSSEC implementation can incrementally improve DNS transaction integrity through the use of islands of trust. See Figure 2.

Figure 2
(nominet.org.uk)

Instead of the trust anchor being a root name server, it is the uk-DNSSEC domain. This could represent something as restricted as a corporate domain with internal child domains. As other levels in the DNS hierarchy transition to DNSSEC, these islands can easily establish a trust relationship with them by exchanging keys, as shown in Figure 3.

Figure 3
(SP800-81, NIST)

Note that in this example, the .com TLD does not have a trust relationship with root. However, this would not prevent all domains under .com from building chains of trust up to the .com trust anchor.

The final word

DNSSEC is not a DNS panacea, and it doesn’t encrypt data. It only signs RRs. However, it promises to establish a level of authenticity in DNS transactions. Overcoming challenges preventing global acceptance might take years. However, several country TLDs already support DNSSEC, making national islands of trust possible. Incremental steps like these will help make DNS, and the Internet, safer. They should not be ignored.

DNSSEC is a complex topic. See the following documents for detailed analysis, design and deployment:

• Secure Domain Name System (DNS) Deployment Guide, NIST SP 800-81
• DNSSEC: The Protocol, Deployment, and a Bit of Development (Cisco)
• The Case Against DNSSEC
• Resource Records for the DNS Security Extensions (IETF, RFC 4034)
• A Illustrated Guide to the Kaminsky DNS Vulnerability
• Verisign and ICANN Square off Over the DNS Root
• DNSSEC Introduction and Resources (ISC)

Source: Tom Olzak, You don’t have to wait to deploy DNSSEC, Retreived from http://blogs.techrepublic.com.com/security/?p=663 on November 19th, 2008