When DNS was designed back in the early 1980s, it wasn’t created with security in mind. At the moment, when a computer makes a DNS request, it simply trusts that the information it receives is from a valid and legitimate source. This blind trust creates vulnerabilities such as cache poisoning and the Kaminsky bug.
The problem is obvious, and the solution is likewise obvious: insert a layer of trust into DNS, and these problems disappear. But how do you add security to a system without drastically changing the way it behaves?
DNSSEC, or DNS Security Extensions, is a proposed solution to the issue of trust. To avoid modifying the way DNS operates, DNSSEC simply adds new records to DNS alongside existing records. These new record types, such as RRSIG and DNSKEY, can be retrieved in the same way as common records such as A, CNAME and MX.
These new records are used to digitally “sign” a domain, using a method known as public key cryptography. A signed nameserver has a public and private key for each zone. When someone makes a request, it sends information signed with its private key; the recipient then unlocks it with the public key. If a third party tries to send bad information, it won’t unlock properly with the public key, so the recipient will know the information is bogus.
Another important concept in DNSSEC is the “chain of trust.” For DNSSEC to work, the recipient needs to know that the public key being used is trustworthy, which creates a chicken-and-egg situation: you need to ask the nameserver for its public key, but the public key itself is used to verify its identity!
To resolve this problem, a “chain of trust” must be established with an “anchor” at the root nameservers. Each “link” in the “chain” is signed against the previous; for example, www.domain.com is an A record, which is signed at the nameservers for domain.com, which are signed by the TLD servers for .com, which are signed by the root nameservers. Without establishing this “anchor” at the root nameservers, you would need to manually verify and add the public key for every domain you visit.
Sounds Great! What’s the Hold-Up?
Naturally, any change that affects a core component of the Internet is not something to be done hastily. There are a number of issues that keep DNSSEC from being rolled out immediately across the web:
- Key Rollover. To maintain its strength, the public and private keys used to sign the root servers must be changed periodically. The logistics of updating these keys and securely propagating the changes throughout the Internet is a difficult (but not insurmountable) challenge.
- Zone Content Privacy. DNS was not meant to be private. However, most people expect zone information to be unseen except by those specifically looking for it; if you don’t know secure.mydomain.com exists, you should not be able to figure it out. Since DNSSEC signs every record in a zone, it is possible to see every record in a zone based on the signature records available. (New proposals seek to resolve this, but have not been formally introduced into DNSSEC.)
- Politics. By definition, the key-signing process must be centralized, and many people have a problem with the United States literally holding the keys to the Internet. Given the U.S. Department of Homeland Security has applied pressure to receive the root keys, this poses a legitimate problem.
- Nothing is Perfect. Less than half a month into the new year, a new DNSSEC flaw was found and subsequently patched. To ensure the new security measure doesn’t contain problems just as bad or worse than the original service, DNSSEC needs to be exhaustively poked and prodded to ensure reliability.
Even with these issues and others slowing down the process, DNSSEC is seeing progress. A handful of ccTLDs, including .se (Sweden), .br (Brazil), .cz (Czech Republic), .pr (Pueto Rico), and .bg (Bulgeria) have already started signing their nameservers, and .org is looking to begin implementing DNSSEC within the year. Dyn Inc. also plans to include tools to make the zone signing process as painless as possible for customers on its DynectÂ® Platform.
Give DNSSEC a try
If you are familiar with BIND and are interested in seeing what a DNSSEC-signed zone is like, we’ve set up a new section for DNSSEC here. It contains a signed zone and a recursive resolver that lets you test the results.
For further reading on the topic of DNSSEC, please see these useful resources: