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.

Implementing DNSSEC
As DNSSEC deployments grow, organizations will scramble to understand how to enable it, whether their current solutions support it, and what to do when DNS queries don't provide signed records. If your organization is running Bind or Microsoft's DNS server, then DNSSEC support is there. Each has its own configuration options and tips, so check the documentation and deployment guides before jumping in. You don't want to break your DNS lookup or publishing while trying to make it more secure.

Outsourced services should be reviewed closely. If you have given control of a zone to an outsourced provider, then you need to know when and how they will implement DNS. You can enable DNSSEC for the zones you host separately, but the parent must have DNSSEC enabled before subdomains will validate.

Don't forget about domains not owned by your organization but provide critical Web components, such as services like Akamai (which supports DNSSEC as of Aug.) or outsourced payment gateway services where users enter their credit card information.

There is little chancenon-signed records will be rejected in the near future, so if your organization does not sign your public records, the resolvers requesting the record will simply return the normal DNS response. The same goes for your internal systems. If a system requests a record and the domain is not DNSSEC-enabled, the normal DNS process will prevail.

Local clients that are DNSSEC-enabled will request DNSSEC records. If properly validated records are not returned, they should not provide the response to the application requesting the lookup. Some clients, such as Windows 7, do not perform validation, but rely on the results provided by their local DNS server. They assume the connection between the local DNS server and the end client is secure.

In these environments, without proper protections, an MITM attack is still possible at the local level. Microsoft recommends enabling IPSEC between clients and local DNS servers to secure the connection.

What Does DNSSEC NOT Do?
While DNSSEC provides validation that DNS queries are accurate, it doesn't solve all DNS-related problems -- and can introduce some new ones.

DNSSEC doesn't solve all problems of data transport security. DNSSEC does not provide confidentiality of data, protect against DDoS attacks, verify user identities, or stop IP spoofing. These issues are not unique to DNS, and must be addressed through other methods at the network or application layers.

Implementing DNSSEC can also introduce some new problems. The first is getting it working. Be sure that your firewall, IPS, or other packet filtering allows EDNS to function properly. With DNSSEC enabled, DNS responses larger than 512 bytes are required. This is problematic because some network equipment and filtering devices block UDP packets larger than 512 bytes by default. Work with your vendors to update or reconfigure your systems beforerolling out DNSSEC capabilities.

On the other end of the spectrum, EDNS allows responses more than 4096 bytes -- which could exceed the maximum default MTU size allowed by your systems. This could cause responses to be split into multiple fragments. Some security devices block fragments, thus preventing your new, shiny DNSSEC installation from functioning properly.

Learn from the mistakes of others. The .gov and .org top-layer domains both made implementation mistakes resulting in higher-than-average response times and higher bandwidth usage.

The .gov TLD used a 2048-bit key -- rather than the recommended 1024-bit key -- for signing, which caused each signature to be large. The .org TLD mistakenly set the time to live (TTL) for all .org records to zero, which told all downstream DNS servers not to cache the record and always request a new lookup each time the domain was requested. This caused a large spike in .org queries -- and in the bandwidth used to serve these requests.

How strong should your signing keys be? To answer this question, take into account other weaknesses in the process, the relative value of the DNS resource, and the overhead required for strong keys. The IETF's Section 3.4.2 of DNS Operational Practices, Version 2 discusses this topic.

Encryption keys used for signing will need to be rotated on occasion, and your decision on how to organization handles this will be important. Develop a method for rotating keys and test this process prior to signing production records.

Making The DNSSEC Decision
DNSSEC is not fully supported across the Internet -- and it is not even close to fully deployed by most organizations. Many organizations won't embark on DNSSEC until the core infrastructure is in place, tested, and stable.

While it may be slow to roll out, DNSSEC is still very much alive. With the support of governments and vendors, it is only a matter of time until DNSSEC is widely deployed and a de facto standard.

DNSSEC prevents some major DNS vulnerabilities, but it is not the end-all transport security solution that some first believed it to be. Transport layer protections, DDoS mitigation, and identity verification are among those risks that will still remain and are best tackled outside of DNS.

While DNSSEC support grows and the backbone strengthens, do your homework and understand where your organization stands. What technologies need upgrading, modification, or replacement? Work with vendors and third parties to ensure all products and service offerings are ready, so your organization can begin signing and validating records right away. DNSSEC is a good step forward, and one your organization should be ready to implement.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.