Boost your Internet security with DNSSec

DNS has been around so long, opportunities to use it as an attack vector are rife. Here's how to lock it down painlessly

DNS without DNSSec (DNS Security Extensions) is not secure. It's that simple.

As an example, a recent interview with a successful black-hat hacker included the following quote: "They patch SQL but choose a DNS that is vulnerable to DNS cache poisoning. You can break in and be gone within an hour." DNSSec prevents not just DNS cache poisoning, but a host of other DNS hacking attacks.

[ Get expert networking how-to advice from InfoWorld's Networking Deep Dive PDF special report and Technology: Networking newsletter. | Learn how to secure your systems with InfoWorld's Security Central newsletter. ]

First, some background: The DNS (Domain Name Space) protocol was invented in 1985 without any thought about security. It was enough that the original inventers developed a protocol so effective that only a slightly modified version is still in use 30-plus years on. It isn't hyperbole to say that DNS underpins virtually every single Internet transaction. But without DNSSec, you cannot rely on most of those transactions.

DNS's security problems have been known for a long time. Specifically, in 1995, Steve Bellovin wrote a paper detailing multiple DNS vulnerabilities. Noted secure code writer and professor, Dr. Daniel J. Bernstein, started writing about various DNS vulnerabilities in 2001 and went on to create one of the most secure DNS servers available.

In August 2004, RFC 3833 discussed some of these vulnerabilities and became the first DNSSec protocol recommendation document. The current DNSSec specifications are covered in RFCs 4033 to 4035. DNSSec works by requiring that the DNS answers (and other components) from authoritative servers be digitally signed, which the relying DNS resolvers (DNS clients or other servers) can then use to confirm validity.

Standard DNS queries
In most DNS scenarios, the primary DNS server is asked to resolve a DNS name -- usually to an IP address, but it can end up with another name as well. The primary DNS server either tries to answer the request itself or forwards the request to one or more DNS servers that do the work on its behalf. In most cases, the DNS server that kicks off the resolving work will commence at the very top of the DNS hierarchy (called root) and work its way back down the DNS tree.

For example, if you're trying to resolve a name of sample.example.com, the root resolver would be a DNS server that points the requestor to the appropriate top-level domain server handling the .com domain. The root DNS server would then tell the asking DNS server what "lower" child DNS servers are authoritative for the example.com domain. The resolving DNS server would then connect directly to the example.com DNS servers and ask them to resolve the sample name. The DNS server collects the result and forwards it to the requesting client.

How to implement DNSSec
For DNSSec to work, the clients and all involved DNS servers (from root servers on down) must be configured to use and enforce DNSSec. For a long time, this could not be accomplished because none of the root DNS servers were DNSSec capable. Finally in July 2010, the DNS root servers/trusts were made "trust anchors" and began to formally support DNSSec.

Now all that's left is for the other DNS servers in the world to support it. This is no small task, but it's one you should get involved in and ask for if DNS falls under your management scope. This means your clients should at least be DNSSec-aware -- that is, the client will request DNSSec answers, but won't reject them if they aren't DNSSec signed when they come back. This is an important distinction because most DNS servers aren't currently DNSSec capable; if you require DNSSec answers, you'll mostly get failures.

But get your clients in order and make them DNSSec capable. Next, ensure all your primary DNS servers (and the DNS servers they rely upon) are DNSSec capable. That way, clients can ask the servers to respond with DNSSec answers, if possible. The last step is to apply pressure to the authoritative DNS servers for each zone from which you request records. It used to be that almost no DNS servers on the public-facing Internet were DNSSec capable, but this is changing. Many of the world's most popular sites have DNSSec-enabled servers.

1 2 Page
Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies