Boost your Internet security with DNSSec

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.

You can use many different tools to find out if DNSSec is enabled in the zones that are pertinent to you. One of my online GUI favorites is SecSpider, which tracks DNSSec-enabled zones; it shows that more than 287,000 DNS zones are now signed. Via its search feature, you’ll find that InfoWorld.com and many other zones aren’t signed, but Comcast.com is.

You can’t control other people’s DNS servers, but at least make sure your own clients and DNS servers are DNSSec enabled. You can be prepared to support and use DNSSec as it becomes more widely available. DNSSec, once enabled, is almost invisible. You get all the possible benefits and no disadvantages.

Microsoft Windows operating systems have been supporting DNSSec since Windows Vista/Windows Server 2008, though there is no built-in backward support for XP or 2003. Mainly, you want Windows 8 and Windows Server 2012 to get widely usable and easily configurable DNSSec. The previous versions supported older protocols and weren’t compatible with most of the Internet; additionally, the server component was much harder to configure. Setting up DNSSec in Windows 2012 is a dream.

BIND DNS has been DNS capable since at least version 9. Most open source operating systems have supported DNSSec for many years, but check each distro for details; older versions won’t always work with newer versions. I know that DNSSec has been available on the Mac OS X platform for a few years, but I haven’t tried to enable it on the iPad or iPhone; I suspect DNSSec can be enabled on these platforms as well. Android devices support DNSSec, but many mobile platform users interested in DNSSec employ apps or browsers that specifically look for and validate DNSSec on the website in question. See the following video as an example.

DNSSec pushback Not everyone loves DNSSec. It has been around for almost 10 years and still is not widely deployed. It used to be hard to configure, and the top-level domains weren’t signed. Now it’s easier to configure, and the root- and top-level domain servers participate. There is no excuse for not deploying DNSSec.

Dr. Daniel J. Bernstein got tired of waiting for DNSSec to take over the world and created his own competing standard known as DNSCurve. It functions a lot like DNSSec, but it uses ECC (Elliptical Curve Cryptography), which is considered more secure for smaller key sizes.

There are two other common critiques about DNSSec besides its lack of general availability. One: it doesn’t encrypt the answers. DNSSec is about integrity and making sure the client resolver is not spoofed or tricked. It doesn’t protect the network channel against sniffing. If you want that, you’ll need to overlay DNSSec with another network protection channel protocol such as IPsec.

Lastly, there’s talk about how DNSSec can make DNS reflection attacks worse. Because DNSSec-enabled servers always respond with signed records, the digital signature itself is usually much bigger than the answer. In short, a DNSSec-enabled server can amplify a spoofed DNS packet many times larger than a non-DNSSec-enabled packet. I have three answers for that:

1. You shouldn’t have an open recursive DNS relay. They are all bad, whether DNSSec is enabled or not. I have to believe that the incidences of open recursive DNS DNSSec-enabled servers is far less than non-DNSSec-aware DNS servers.
2. It’s possible to make larger DNS packets matching the size of DNSSec-enabled packets without using DNSSec. DNSSec makes it easier, but the hackers can do it regardless.
3. There are defenses against DNSSec-amplified attacks. Microsoft has its discussion and solution, and the same protections can be implemented with non-Microsoft DNSSec servers and clients.

DNSSec usage is growing. There’s a learning curve when you first get into it, as well as a moderate amount of configuration to both servers and clients. But repeat after me: You cannot rely on DNS without DNSSec. Get ahead of the curve and get your clients and servers ready. Disappoint a black-hat hacker today.

This story, “Boost your Internet security with DNSSec,” was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes’ Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.