BY Ben Ball

In the wake of the Department of Homeland Security’s extraordinary public alert on DNS hijacking and ongoing evidence that the trend continues, the Internet Corporation for Assigned Names and Numbers (ICANN) this week joined the chorus of organizations calling for broader implementation of DNSSEC.

The current wave of DNS hijacking attacks involve unauthorized changes to the delegation structure of domain names, replacing the addresses of intended servers with addresses of machines controlled by the attackers.  DNSSEC protects against this particular type of attack by digitally signing data to assure validity.

What is DNSSEC?

DNSSEC (Domain Name System Security Extensions) is a pretty simple concept, actually. At a basic level, DNSSEC validates responses to DNS queries before they are returned to the client.

Operationally, this means that the client sends a query asking for a particular IP address with a cryptographic key, and the client’s DNS server retrieves the answer and validates it using another cryptographic key. Once the answer is validated it is returned to the client, but not before the two keys link up at the original server.  Only then will the query fully resolve.

As organizations around the globe now recognize, DNSSEC is a basic security move which all network administrators 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 individual queries, while DNS security uses query data to protect the larger enterprise.)

How to implement DNSSEC?

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

Without a unified enterprise 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 have to do it 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” won’t automatically adjust themselves when the parent zone is re-signed, requiring 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 implementation of DNSSEC ridiculously simple.  In BlueCat’s unified DNS Integrity system, you check a box, and the DNSSEC scheme is automatically implemented throughout the entire zone.  No command lines, no manual distribution of trust anchors, no wondering whether it’s actually working – it just happens for the parent and child zones in one click.

Ben Ball

Ben Ball is a Government Market Manager at BlueCat, handling business development and marketing outreach in the Federal, State, and local government markets. 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