January 16, 2014 archive

We were very pleased to see this recent post over at the CircleID site, “Domain Name System (DNS) Security Should Be One of Your Priorities“, by Rick Rumbarger. He makes a number of great points, particularly about the fact that so many people take DNS for granted and don’t give it the attention they should.

Naturally, given our focus on getting DNSSEC deployed, we were delighted to see his paragraph:

Activate DNSSEC On Your Domain Names – DNSSEC counters cache poisoning attacks by verifying the authenticity of responses received from name servers. It effectively prevents responses from being tampered with, because in practice, signatures are almost impossible to forge without access to the private keys. If your DNS provider is not DNSSEC capable… make a switch.

He’s right! DNSSEC is critical for protecting the integrity of the information you get out of DNS queries.   In his paragraph, he talks about the signing of domain names with DNSSEC, but it is important to remember that this is only half the equation with DNSSEC. The other piece you need to do is to enable validation of DNSSEC on your local DNS resolver.

The local validation of DNSSEC information protects the inquiries your computer makes for DNS info, and the signing protects the integrity of your own domain name.

The one point I do take issue with in Rick Rumbarger’s article is his suggestion to outsource ALL your DNS services on both the authoritative side (distributing your domain records) and the recursive resolver side (making inquiries to DNS).  On the authoritative side, I agree that outsourcing DNS services can make a whole lot more sense than running your own DNS servers.  Most of the DNS hosting companies out there have put a great amount of effort into performance, security, DDoS protection and more – and since they are focused on that can provide better protection and performance than many of us can do ourselves (unless, of course, we operate our own data centers).

However, on the recursive resolver side, I am much more of a fan of having the DNS resolution occur as close to the end user as possible. This is particularly true when you enable DNSSEC validation.  Your DNS query is going from the stub resolver on your local computer to the whatever recursive resolvers  you have configured in your computer.  These are the ”DNS servers” in most operating system network control panels and are often supplied via DHCP to computers on a local network.

The connection between your stub resolver and the recursive resolver you use is typically unencrypted and represents an area where an attacker could inject bogus DNS information.  Ideally the connection occurs over a “trusted” network, such as your local area network.  If the recursive resolver is on the edge of your local network and is performing DNSSEC validation from that point on, then the attacker would have to somehow get on your local network in order to attack your DNS queries.

If you can’t have a recursive resolver at the edge of your local network, the next best option to me is to use the recursive resolvers at your ISP . You are then only widening the attack surface to be between your local network and that of your ISPs network.

If you can’t do DNSSEC validation at either your local network edge or your ISP, you then do need to go out and use an external recursive resolver that does DNSSEC validation such as Google’s Public DNS.  However… the attack surface against your DNS queries has now been expanded to include the entire part of the public Internet that is between your computer and Google’s Public DNS servers (to use the example of Google).  An attacker now has a better chance of getting in the middle and injecting false DNS information that goes back to your stub resolver running on your machine.

So for those reasons, I prefer to run the recursive DNS resolver as close to the end user as possible. In the ideal world, the DNSSEC validation might even be performed on the local machine (which can be done today using something like DNSSEC-Trigger) or in the application the user is using.

Outside of that point, I agree with the points Rick Rumbarger raises – and it’s great to see attention being given to this issue of DNS security!

P.S. And to perfectly illustrate one of Rumbarger’s other points about having strong access control for your DNS records there is this post today about how easy it was to get a DNS hosting provider to change DNS records with a simple email message.  This is something that DNSSEC will NOT protect against because the DNS hosting provider is  changing the actual zone file that would then be encrypted with DNSSEC.  It shows again how “DNS security” is really composed of many different layers!