ICANN haz DNSSEC?

BY Ben Ball

First, the client queries for a particular IP address with a cryptographic key. The client’s DNS server then retrieves the answer and validates it using another cryptographic key. Once the answer is validated, two keys link up at the original server which then returns the answer to the client. Only then will the query fully resolve.

 In general, there are two categories of keys used in DNSSEC: the Zone Signing Key (ZSK) is used to protect all zone data, and Key Signing Key (KSK) is used to protect other keys.

What is DNSSEC?

DNSSEC (Domain Name System Security Extensions) is a set of security extensions introduced to address security risks within DNS. DNSSEC solves the gap in DNS security by authenticating the host and data using public key cryptography. By verifying zone data and verifying the key used to sign the zone data, DNSSEC ensures the host is authentic and that the data sent has not been tampered with. DNSSEC all but eliminates cache poisoning and similar attacks by proving ownership of the zone data.

DNSSEC relies on public key cryptography to secure the authenticity and integrity of DNS messages. The validating resolver acts as a decoder. Each zone has a public key and a private key. The public key, as the name suggests, is available to everyone and provides the means to decrypt messages signed by the corresponding private key (this is why they are known as a “key pair”). Although we won’t get into the details here, let’s look at how those components work collectively to create the “Chain of Trust”.

The resolver already has the necessary key for the validating responses from the root server. This key, called a root Key Signing Key (KSK), and known as the “Trust Anchor”, is built-in to DNSSEC-aware resolvers. Once the response from the root is validated, each server provides the public keys for the server below it in the chain. In other words, it obtains the public key to validate that the data is from its respective zone. The public key is then authenticated by a private key. A thing of note here is the private key comes from the parent zone. Each parent zone has a private key that signs the respective child zone public key.

Each cryptographic key signs a subsequent cryptographic key, hence the term “Chain of Trust.”

When DNSSEC is enabled, the normal resolver becomes a validating resolver. It is programmed to detect DNSSEC queries, its responses, and has the ability to process them. Servers communicate the same DNS information with the addition of cryptographic data that can be validated with a validating resolver. It acts as a digital signature and contains information that authenticates the subsequent digital signature the resolver receives in the recursive query. Because each server works together to validate the next, it creates the aforementioned "Chain of Trust".

If there’s an attempted man in the middle attack while DNSSEC is enabled, the validating resolver rejects the response from a rogue server because it does not have the cryptographic data that validates its origins. The bad site does not get cached in the resolver and the client is never connected to the rogue site.

Why is DNSSEC important?

In January, the Department of Homeland Security released a public alert on DNS hijacking. Ongoing evidence suggests that this trend continues. This week, the Internet Corporation for Assigned Names and Numbers (ICANN) joined the chorus of companies calling for broader use of DNSSEC.

The current wave of DNS hijacking attacks involve unauthorized changes to the delegation structure of domain names. DNS hijackers replace the addresses of intended servers with addresses of machines that they control. DNSSEC protects against this particular type of attack by digitally signing data to assure validity.

DNS was developed in a time when the Internet was much smaller and more friendly than it is today. It is based on an implicit trust between the client and the DNS server: the client trusts that the DNS server is authentic and that the data returned is valid. As the Internet grew, the DNS model left itself prone to attacks by malicious users who would hijack the DNS server or intercept and spoof the data.

As companies around the globe now recognize, DNSSEC is a basic security move which all network admins should take. It’s been a part of the NIST 800-53 compliance standard for years. (It’s important to note here that DNSSEC is not the same as DNS security. DNSSEC protects single queries, while DNS security uses query data to protect the larger enterprise.)

How does DNSSEC work?

DNSSEC is a pretty simple concept, actually. At a basic level, DNSSEC validates responses to DNS queries before they are returned to the client. Let’s look at each of the steps involved:

  1. A client requests an A record from www.isc.org from its DNS server.
  2. The isc.org DNS Server replies back with A+ RRSIG.
  3. The DNSSEC-enabled BlueCat DNS Server then asks isc.org server for the DNSSEC Key RR (ZSK).
  4. The isc.org DNS server replies back with the key pair and RRSIG record.
  5. The DNS Server then asks the .org DNS server for DS record to verify the response it received in step three.
  6. The .org server replies back and verifies the KSK for isc.org with the DS record received from .org.
  7. The resolver then asks ORG for its DNSKEY (ZSK) to verify the response in step five.
  8. ORG server replies with Keys and RRSIG record.
  9. The BlueCat DNS Server then goes to the ROOT server to validate ORG’s response.
  10. The ROOT Server replies back with RRSIG which should match the reply in step seven.
  11. The DNS server asks ROOT to verify the answer in step nine.
  12. Lastly, the ROOT server verifies its own response by supplying the key.

As you can see, validation is performed by each level of the domain system. Once all of the above steps have been verified and all the answers are considered authentic, the answer will be sent to the client. If the chain of trust breaks at any point and a record cannot be verified, the DNS server will respond back with a SERVFAIL instead.

DNSSEC does not encrypt DNS data, and it does not require SSL certificates or shared secrets.

How do I implement DNSSEC?

Is DNSSEC easy to implement? It depends entirely on your DNS architecture.

Without a unified enterprise-grade DNS system in place, implementing DNSSEC is a significant logistical challenge. 

Implementing DNSSEC in BIND requires a series of onerous command-line changes to configure each server. Generating the DNSSEC keys, attaching them to the relevant machines, and testing the infrastructure takes a lot of time. Then you must do this for every parent and child server in the network. That's a significant drain on IT resources.

In Windows, implementing DNSSEC is similarly work-intensive. First, you sign a zone and verify that the signing scheme is operating correctly. Then you use “trust anchors” to distribute that signing scheme to the child zones.

Unfortunately, those “trust anchors” do not automatically adjust themselves when the parent zone is re-signed. This requires network administrators to constantly re-distribute “trust anchors” to the child zones when the parent signatures change.

In contrast, BlueCat’s enterprise approach to DNS makes implementing DNSSEC ridiculously simple. In BlueCat’s unified DNS Integrity system, you check a box, and the DNSSEC scheme takes effect throughout the entire zone. This means you can avoid command lines, manually distributing trust anchors, and wondering whether it’s actually working. It happens for the parent and child zones in one click.

With a few simple steps, you can configure Address Manager (BAM) and DNS/DHCP Server (BDDS) with DNSSEC. Before deploying the BDDS, you must complete two tasks using the BAM user interface: 

  1. Create a DNSSEC signing policy.
  2. Assign the DNSSEC signing policy to a zone or multiple zones.

In Address Manager, DNSSEC signing policies simplify administration by allowing you to configure DNSSEC settings in one place, and then apply the policy to forward and reverse zones. 

A DNSSEC signing policy contains all of the parameters needed to define the KSK and ZSK for a zone, including the settings for automatic key rollover. Administrators can create and manage DNSSEC signing policies from the DNSSEC Policy Management link on the Administration tab.

You can create multiple signing policies to create KSKs and ZSKs to meet the unique requirements for each zone, but a zone can only be linked to a single signing policy at any given time.

Ben Ball

Ben Ball is the Director of Strategy and Content Marketing at BlueCat. Ben served for ten years as a Federal employee, with three tours as a Foreign Service Officer (Saudi Arabia, Turkey, Jordan), and five years at the Department of Homeland Security, where he focused on immigration issues. A graduate of the Fletcher School of Law and Diplomacy and Pitzer College, Ben lives in the San Francisco Bay Area.

View more articles by Ben Ball