By Dirck Copeland – Technical Consultant

The DNS (Domain Name System) is one of the most critical protocols in use on the Internet. Virtually every end-user transaction involves a DNS query. Every email, text message, and web page viewed requires interaction with a DNS server. With such a critical service, it’s no surprise that it has increasingly become the target of attack since its inception in 1983. There are multiple ways the DNS can be attacked. The current implementations of DNS are inherently insecure and prone to attack using various methods including cache poisoning, man-in-the-middle attacks, DDoS (Distributed Denial of Service) Amplification attacks, or simply just hijacking¹ the registrar and changing the authoritative DNS servers to the choice of the attacker, among others. One of the more common attack methods, cache poisoning, occurs when the attacker is able to insert their own unauthorized data into an unsuspecting DNS servers cache. With the increase in these attacks, it became apparent that there would need to be extensions to the original DNS protocol specification which resulted in the Internet Engineering Task Force (IEFT) publishing RFC 2535 in 1999 which has since been replaced by RFC 4033, RFC 4034, and RFC 4035 which was released on March 2005.

Although poisoning cache in a DNS server has long been a form of attack, in the spring of 2008 it was discovered² by security researcher Dan Kaminsky just how easy cache poisoning can be done. This discovery caught the attention of virtually every networking and technology company and leaders from several high profile agencies and companies met to find the best ways to address this. Obviously providers of major DNS products rushed to patch their software, which is to the extent it would help the current vulnerability. An emphasis was placed on expediting the deployment of DNSSEC. Milestones and goals were placed on government agencies and Internet operators to get DNSSEC deployed into the critical infrastructure. The Office and Management and Budget (OMB) with the federal government issued a memo³ mandating that all .gov second-level domains will be DNSSEC operational by December 2009.

The DNSSEC protocol was designed to allow DNSSEC aware DNS servers to coexist with the existing infrastructure without interruption. Deploying DNSSEC incrementally across the Internet requires a DNSSEC aware DNS server to operate transparently with DNS servers that are said to be DNSSEC oblivious or not enabled to participate in the DNSSEC protocol. A recursive DNS server which is oblivious to the protocol will still interoperate with a DNSSEC aware authoritative or recursive server, they will just not be able to enjoy the benefits provided by DNSSEC.

The benefits are realized by providing authenticity of the returned DNS query, verify the integrity of the data by ensuring that the data received at the querying resolver was, in fact, the data sent from the queried name server, lastly, if the data queried for does not exist, DNSSEC provides proof of non-existence.

With the introduction of DNSSEC, new resource records were added to the DNS to accommodate the new features. Some of the more visible resource records are the resource record signature (RRSIG), next secure (NSEC), delegation signer (DS), and DNSKEY. The use of Public Key Cryptography (PKI) is integrated into the process of creating the zone files (they contain the resource records DNS uses to answer questions about a given domain). The signing of resource records results in the RRSIG, one signature for each resource record set (RRSET) in the zone.

The NSEC record is used to respond to a DNS query that is a non-existent domain name (NXDOMAIN). At the time a DNSSEC zone is signed, the resource records are sorted and once operational, a query for an invalid fully qualified domain name (FQDN) is answered with the next record in the sorted list. This gives an authenticated answer providing proof of non-existence.

PKI is crucial in DNSSEC because the public/private key combination is used to validate the data transfer (via DNS queries) between each level in the hierarchy of the DNS system. The public/private key combination actually consists of two key pairs. The dnssec-keygen utility is used to generate the cryptographic key pairs. A Key Signing Key (KSK) pair and a Zone Signing Key (ZSK) pair. The KSK is used to sign the root of the zone and create a chain of trust to the parent zone in the hierarchy, while the ZSK is used to sign the local authoritative zone files. The private key of the ZSK is used to sign the zone and during the zone signing process. The public key of the ZSK is added to the zone as a DNSKEY resource record (RR). The KSK public key is given to the parent domain operator (usually out of band or through secure web upload) so they can create a Delegation Signer (DS) RR.

The addition of the DS RR in the parent zone creates a trust anchor to complete the DNSSEC chain of trust. With a chain of trust complete in the hierarchy, this allows for the creation of islands of trust.

Islands of trust allow for incremental deployment across the Internet and is the initial approach operators used before the root was signed on July 15, 2010. The .org top-level domain (TLD) was signed in June 2009 and the .gov signed January 2009. Subsequent TLD’s have been signed since then.

DNSSEC is a huge undertaking by the Internet as a whole and even though some levels in the hierarchy have it deployed, others are lagging. As of March 4th, there are 277 TLD’s⁴ with trust anchors published as DS records in the root zone.

Troubleshooting⁵ DNS with DNSSEC in the mix adds another layer of complexity. The nslookup command is no help. Tools like dig, dnscap, and DNSViz⁶ must be used to return the necessary information. The DNSKEY needs to be matched up in the query by using a key-tag that uniquely identifies the key pair in the system. The DNSViz web site provides an excellent way to visualize the DNSSEC information. Comparing the output of dig with the information provided by DNSViz provides a useful way to track down most DNSSEC related issues.



Some reports⁷ in the media contain information about how DNSSEC employs the use of encryption. DNSSEC uses PKI (cryptography) to validate and authenticate the integrity of the data. The traffic is not encrypted, the RRSIG’s and DS records are sent in plain text just as all the other DNS traffic is.

DNSSEC adoption has been slow but is gaining pace. As technologies such as DNS-based Authentication of Named Entities (DANE)⁸ evolve and can be used in conjunction with DNSSEC, they will provide a more secure user experience on the Internet.


Resources:

1Three Ways Hijacks Can Happen

2 An Illustrated Guide to the Kaminsky DNS Vulnerability

[3] Federal OMB Mandate

4Signed Zones Stats

5DNSSEC Troubleshooting

6 DNSViz

7 Washington Post Article about New York Times Getting Hacked by  DNS Hijacking

[8] DANE