Tech Insight: The Basics Of Implementing DNSSEC

Domain Name System (DNS) is one of the basic elements that makes the Internet work. By mapping thousands of arcane IP addresses to the URLs and domains we all know so well, DNS has made our lives easier and allowed Internet technology to skyrocket.

Yet along with this ease of use, DNS also introduced new security risks to the Internet. In the early days, we saw unauthenticated zone transfers that allowed attackers to take control of and point domains to their own servers. DNS security was beefed up in response.

More recently, we've seen the emergence of man-in-the-middle (MITM) attacks, where an attacker intercepts a DNS response, modifies it, and passes the modified response to the client. The modified response redirects the requester to the host of the attacker's choice.

We've also seen the growth of cache poisoning, which tells a DNS server that a domain name points to a different IP than it really should. When successful, the attack will force all users of that DNS server to connect to the impostor host, rather than the real one. Cache poisoning allows attackers to intercepttraffic, modify requests, or hijack businesses.

What Is DNSSEC?
DNS Security Extension (DNSSEC) aims to curb these emerging DNS-based attacks. By extending the capabilities of DNS servers and resolvers to look for new record types -- and understanding what and when to trust -- organizations can eliminate attacks that exploit lack of authenticated responses and provide authenticated denial-of-existence.

To understand DNSSEC, you need a basic grip of how DNS works. DNS is a mapping of a friendly name to an IP address, such as darkreading.com maps to 66.77.24.10. It was created to allow users to easily connect to IP systems and their services. Because there are different types of services and redundancy required for some of these services, there are different record types within DNS.

Standard DNS has several records types. If you manage your own DNS for a personal website, then you will be familiar with these: A, CNAME, MX, NS, PTR, and, in recent years, SPF. Each record does roughly the same thing, mapping one value to another (or to several others) for redundancy or load balancing.

DNSSEC extends the supported record types, adding new records to store information that help ensure authentication and data integrity. Like SPF, DNSSEC record types store data rather than providing a mapping, such as A records do.

DNSSEC adds four new resource record types: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure (NSEC). These new RRs are described in detail in RFC 4034.

DNSSEC also adds two new DNS header flags: Checking Disabled (CD) and Authenticated Data (AD). To support the larger DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also requires support of EDNS0 (RFC 2671).

Finally, DNSSEC requires support for the DNSSEC OK (DO) EDNS header bit (RFC 3225), so that a security-aware resolver can indicate in its queries it wishes to receive DNSSEC RRs in response messages.

How Does DNSSEC Work?
DNSSEC is a trust system layered on top of the current DNS implementations. To ensure authentication and integrity of DNS requests, the system requesting information can validate the answer it receives by checking the digital signature provided with the name resolution answer.

When DNSSEC is in place, each record is digitally signed with one ore more private keys using an asymmetric cryptographic algorithm. Public keys are published within the DNS system to allow decryption of the request and validation of the answer provided. This is like signing emails with public-private key cryptography, so that the reader can validate you actually sent the message.

To accomplish signing and passing of the generated certificates for validation, there must be a way to pass the information between DNS servers and end clients. The new DNS record types were created provide this functionality. Public keys are stored as DNSKEY RR records. Signatures generated after signing each record with private keys are stored as RRSIG RR.

To ensure a response can really be trusted, DNSSEC uses a chain of trust. Each parent holds a record validating its children. If a resolver requests sub.example.com, then the authoritative name server for sub.example.com provides the resolver with the records requested, including the DNSSEC records required for validation.

To ensure those records are valid, the resolver looks up the information provided with the authoritative name server for example.com. The resolver then has the option to continue up the chain to ensure each server is providing proper information. It then queries the root name servers for .com.

If the information provided in each of these steps proves valid, then the resolver can assume the chain is intact and trust the original answer for sub.example.com. This might seem like a lot of steps to ensure the original response was correct, but it all happens very quickly. And given the importance of DNS to the basic functions of the Internet, DNSSEC is a big step in protecting our critical infrastructure.