DNS As Security Enforcement
June 21 2010 by 
Cricket Liu (Infoblox)
The Domain Name System was originally used as the Internet’s naming service—that much isn’t contentious. Over the years, though, clever people have found all sorts of new applications for DNS. DNS’s ubiquity, distributed management and (relatively) easy extensibility made it an obvious target for new uses, including blacklists of various types, storage of email authentication and authorization data, and more. Much more.
One of these novel applications of DNS is its use to enhance client security. David Ulevitch and his gang at OpenDNS are pioneers in this area: Their service can restrict access to content by domain name, so that if one of your employees or students tries to visit http://www.hotmamas.com/, they’re directed to a page that says, in effect, tsk, tsk, no you don’t. (Note to Infoblox IT: I loaded that URL solely to make sure I wasn’t leading users somewhere unsavory—please don’t have me fired.) Or if malware on your computer tries to surreptitiously resolve the domain name of its command-and-control channel to an IP address to ask SMERSH headquarters for orders, OpenDNS can prevent it and alert you or the administrator of your network that your computer has been infected. Very handy.
Some DNS purists, however, argue that this is a perversion of DNS’s mission. DNS, they argue, is a naming system, and the wrong place to implement policy. Leave it to firewalls and proxies and such to make those decisions. Besides, they’d say, using DNS to enforce security policies doesn’t provide the necessary granularity of control. You can only say yea or nay to an entire domain name, no matter how many web pages are offered by the server with that domain name.
Honestly, I can see their point: In an ideal world, some piece of security infrastructure would be responsible for implementing security policy (duh) and the naming service would be left to return information without regard to policy. But the pragmatist in me knows how many organizations can’t afford that expensive security infrastructure and wouldn’t have the manpower or expertise to administer it even if they could. It’s no good to simply leave those folks to the wolves while those of us who work for organizations that can afford commercial security products sleep soundly inside our gated Internet subdivision. DNS, it turns out, can be a cheap, effective place to enforce security policy and, like it or not, folks are going to use it to do that.
I’m interested in hearing your opinion, too. Do you think we ought to leave DNS alone, or is it okay to adapt it to add capabilities that the founding fathers might never have envisioned?
Posted in DNS Security | 
9 comments
Jun 21, 2010 at 11:10 PM
Hi Cricket,
Thanks for your thought-provoking article, as always.
"Enhancing client security" seems to be the main advantage, indeed.
However, it turns out that some of these new alternative DNS services block parked websites, because they're full of ads. But instead, they're redirecting users to their own landing pages with PPC ads, sometimes sharing revenue with ISPs.
Mike Berkens recently wrote about what Neustar is doing with DNSadvantage.
The full discussion thread, including more information from Neustar, is also a good read.
http://www.thedomains.com/2010/06/16/neustars-alternative-dns-service-is-blocking-parked-pages/
---
Btw. Will Norton DNS service offer PPC ads in the future? What about large access providers and ISPs? Interesting.
Jun 23, 2010 at 4:02 AM
There are some real-world benefits here though, e.g. I really like what Netgear are doing with their "Live Parental Controls" feature and OpenDNS integration.
At the end of the day, I would rather protect my kids from dodgy Internet content than preach from my soap-box about perversion of the DNS, and if OpenDNS can help with that then so be it! :-)
Paul
Jun 23, 2010 at 5:41 AM
During the recent ICANN Meeting in Brussels, the implications for intercepting and redirecting traffic were also discussed (in the context of DNSSEC).
Panel members were Diffie, Crocker, Mockapetris, and Kaminsky.
Skip to minute 55 in the following audio recording and hear about another a scenario where several 'ad-injectors' at different layers in the stack are competing for delivering ads to the end user. "Who exactly gets to filter what I see?".
http://audio.icann.org/meetings/brussels2010/dns-vulnerabilities-discussion-21jun10-en.mp3
Jun 23, 2010 at 11:42 AM
No one ever intends their code to be used in the exact ways it gets used.. They never intend it to be used as for long as it gets used. I guess what I'm getting at is that just about anything can be used as a security tool, including DNS. If it turns out that it makes sense to use an existing tool for a "new" funtion then it will catch on; like it or not.
Jul 5, 2010 at 1:06 AM
Cricket,
Blocking based on name or origin isn't scalable. Offenders will move around and the list will be longer and longer. An example in this is Spamcop. This list is very long and will only grow.
If you want to stop this traffic, then filter on content and do this where it should be done. This isn't an DNS server.
This is the same as in the adult phone entertainment industry. We blocked the special numbers, and now the proxy from normal numbers. And DNS a "phonebook" for computers.
Jul 6, 2010 at 12:27 PM
Blocking by domain name on the grid would be a big convenience, and my group gets requests for this regularly. I view this as an enhancement to appliances' DNS capabilities (like API scripting.)
Would it be possible to keep "blocked domains" segregated from [my] domain's configuration in BIND.
Jul 6, 2010 at 6:09 PM
Relying on DNS to block undesired sites is inherently risky. You can often change your resolv to any public resolver, and even if that's blocked, there's plenty of ways to do DNS lookups via the web. If a corporate DNS proxy blocks "www.facebook.com";, you may be able to access http://69.63.189.11/ and log in just the same. (I haven't tried this as I don't do Facebook, but you could easily pick any other example of a large site that's not vhosted.)
In fact, no URL-based filtering is reliable. However, if all you're trying to do is send a signal that certain actions are not welcome, then it works just fine - anyone who goes to the effort of manually resolving the name and then using the IP will _know_ that they are circumventing security.
Jul 14, 2010 at 6:57 AM
I see a lot of value in "DNS firewalls", but only when used in conjunction with other solutions. I have firewalls, IPS sensors, web proxy/gateways, netflow reporting, etc. The IPS sensors are loaded (and actively block) connections to known malicious IP addresses (using the emerging-threats.net blacklists) The web gateways classify and block based on URL, as well as doing malware scans. I run a DNS blacklist in listen-only mode, and there have been several occasions where the DNSBL caught something that none of the other systems did. For example, I *JUST* pulled this off a sensor: a system connected to vaseajretikru.com, at IP address 195.206.246.251 (which is in the Republic of Moldova. riiiight..) Google for either dns name or IP address and the first hits clearly indicate that its bad, but again only the DNSBL picked it up. Even if the IP address changes (i.e. FastFlux), the DNSBL will still pick it up.
What I would really like to do is have all suspicious/malicious domains return an IP for a honeynet on my internal network. That was I can see what the actual URL was. 9 times out of 10 that's enough to 'convict' a system for being infected.
A few folks created an .ISO using BIND and some scripts to pull down DNS blacklists. What I would like to do is use their script in conjunction with the Infoblox API, and push the blacklists up that way. I will WCCP all internal user's DNS requests that didn't go through our corporate DNS infrastructure, preventing any rogue DNS queries.
http://isc.sans.edu/diary.html?storyid=9037
Dec 10, 2010 at 9:24 AM
Anyone use internal DNS root anymore? No internal client can lookup any name that you don't explicitly configure. So unless their malware is proxy aware it won't be able to phone home.
I will leave blacklisting public websites to the proxy guys.