Why DNSSEC May Not be a Good Thing

Recently, DNSSEC has been rolling out into major DNS servers, including those that service the .org zone and now the root zone. This sounds at first glance like a good thing: all responses from DNS servers are validated, and it becomes impossible for man-in-the-middle attacks to take place.

However, there are commercial uses for “man-in-the-middle” operations; OpenDNS is one that comes immediately to mind. Indeed, OpenDNS is opposed to DNSSEC and has implemented DNSCurve instead.

The main problem (for this discussion) is that DNSSEC completely removes the possibility of a man-in-the-middle – that is, it is impossible for a DNS server like OpenDNS to return a different IP address than the actual DNS address of a machine.

The OpenDNS article also suggests that Akimai and the NTP Pool Project will both be affected by this as well. In these cases, the problem is that when a name is presented to the DNS server, it chooses a particular IP address based on parameters of its choosing – so a one-to-one mapping of DNS name to IP address is irrelevant and impossible.

This also suggests that DNS round robin for clusters would be impossible to implement with DNSSEC active as well.

DNSSEC also interferes with split horizon DNS configurations, although there are ways to make it work.

It will be interesting to see what becomes of DNSSEC if commercial interests like OpenDNS and Akimai speak out against it.

Why Site Filtering By DNS Fails

Filtering by DNS seems a good idea when you first consider it. OpenDNS has a very nice setup for doing just this, and is often recommended as a business tool for content filtering.

The concept is simple: use a benign form of DNS “hijacking” in reverse against malicious sites – and other undesirable web sites (such as adult or gaming or sports, et al). To use the DNS server in this way, the client identifies itself (pairing an IP address to a server-based account) to the DNS server, then replies with the appropriate web addresses based on the client’s DNS requests.

For example, once the client authenticates to the DNS server, then the client will make a DNS request. Once the server receives the request, it consults the filtering in place for the account, and either returns the actual IP address, or an IP address of a website showing the actual web site as blocked.

Unfortunately, the problem is not in the implementation at the DNS server; it is in actually getting to the DNS server that is the problem. One very big problem is that any DNS cache will subvert the filtering at the DNS server. When the DNS cache makes its requests, the association with the account is broken, and the actual IP address is cached.

This means that you will not be able to use a DNS cache on your local host for speeding up your Internet access. However, the problem is deeper than that: if your Internet provider uses a DNS cache – which they might and you would never know – then the DNS filtering breaks.

The other problem has to do with IP addresses. If the user can get to a site that has the actual IP addresses in it, then the DNS server is never consulted and filtering again breaks down.

There is also the problem with proxies. A proxy receives a URL itself, and makes the DNS request on its own, bypassing any DNS-based content filtering which may be in place.

And then there is the Google cache. Using Google, if a person selects the cached version of a page (and not the direct link) then the page can be seen rather than blocked.

The only reasonable way to perform content filtering is by using your own local proxy – such as Privoxy or Squid with Squidguard – but even this will not stop the Google cache and perhaps other methods. But at least it will be immune to most problems listed here. Privoxy is good for personal proxies, and Squid is good for enterprise implementation.

Using a local proxy is more resource intensive (both in terms of processing power and administration required) but this may be necessary to keep reasonable order in the workplace.

OpenDNS and Proxies: Putting it All Together on Ubuntu Karmic

I’ve been running Ubuntu as my laptop operating system for quite some time (year or more) and find it to be quite wonderful. However, recently I had some nasty times getting everything to work with OpenDNS.

The easy thing to do is change /etc/resolv.conf to contain the OpenDNS entries. However, this was complicated by my use of polipo (web cache), pdnsd (DNS cache), and resolvconf (a resolv.conf file manager) – not to mention the use of ddclient to update the dynamic IP on the laptop, and the Gnome NetworkManager.

To start at the beginning – the best thing to do is to install resolvconf by itself so that it loads and sets up first:

apt-get install resolvconf

Then you can install the rest:

apt-get install polipo pdnsd ddclient

Installing pdnsd will require you to specify that you want resolvconf to be used. Installing ddclient will require you to specify using dyndns2 protocol and updates.opendns.com as the server – but the ddclient configuration will be rewritten anyway.

Change the /etc/pdnsd.conf file by changing the paranoid option to off:

paranoid = off;

This is required because OpenDNS does some of the things that pdnsd would reject based on this setting; especially blocking sites and possibly other things. Restart pdnsd after making this configuration change.

Configure resolvconf next: resolvconf is configured to reject all nameserver entries except 127.* if it sees that entry. Turn this behavior off by creating /etc/defaults/resolvconf:

TRUNCATE_NAMESERVER_LIST_AFTER_127=no

Then create /etc/resolvconf/run/interface/opendns:

nameserver 208.67.222.222
nameserver 208.67.220.220

Update the resolv.conf settings with:

sudo resolvconf -u

Setting up polipo is not too hard, just a little contrary: it does its own DNS resolution, so that it won’t block waiting for DNS replies. To configure it, you can either use the OpenDNS name servers directly or use pdnsd on the local machine: I recommend the latter, as it puts all of the benefits of the DNS cache to work for the web cache.

Change the /etc/polipo/config file to contain the following entry, and restart polipo:

dnsNameServer = 127.0.0.1

This sets up polipo to start polling the pdnsd caching nameserver.

Then there is the Gnome NetworkManager: this program should be putting its configuration in resolvconf storage in /etc/resolvconf/run/interface/NetworkManager in the same format as the opendns file created earlier. You should make sure that the relevant interfaces don’t try to rewrite the DNS entries based on DHCP information – but I’ve not tested it extensively (resolvconf may overwrite DHCP entries).

If you are using a dynamically assigned IP – as one is on a laptop – you’ll need ddclient. A suitable configuration for OpenDNS is the following:

# /etc/ddclient.conf
ssl=yes

protocol=dyndns2
use=web, web=http://whatismyip.org
server=updates.opendns.com
login=your_login
password=your_password
NetworkName

The network name at the bottom should match the name you gave the network in OpenDNS; replace spaces in the network name with underscores in the configuration file.

Lastly, for a test: go to http://welcome.opendns.com – it will tell you whether you are using OpenDNS or not. Alternately, reload this page: the OpenDNS banner at the right will let you know if you are using OpenDNS. It might be worthwhile to reboot the system once to get everything synchronized.

UPDATE: fixed a bad filename (as pointed out in the comments) – thanks for pointing it out!

Google Enters Free DNS Fray

Now it seems that OpenDNS has some serious competition: Google announced their Google Public DNS service just days ago. The founder of OpenDNS, Dave Ulevitch, responded to Google’s announcement in his blog.

Several things stand out between OpenDNS and Google DNS:

  • Google DNS does not misuse NXDOMAIN responses. That is, when you try to resolve an entry that does not exist, you get a “no domain found” response: OpenDNS sends you to their search page.
  • Google DNS supports IPv6.
  • Google DNS implements a wide array of security tools to mitigate attacks against DNS servers.
  • Google will (probably) not redirect valid DNS entries to its own servers.

There has already been some speed testing that shows that, at least in India, the response from Google DNS is much faster than OpenDNS.

CNET had a nice write-up (in the DeepTech blog by Stephen Shankland) on Google’s DNS offering and what it means.

It also appears that the privacy concerns that have cropped up with OpenDNS may not be a concern with Google’s Public DNS (and ironically so). Over at the Slight Paranoia blog by Christopher Soghoian, he wrote a piece about their privacy policy – and received a nice response directly from Dave Ulevitch (the founder of OpenDNS).

Over at The Scream!, there is a forum posting that describes some of this in detail – including the redirection of google.com to google.navigation.opendns.com. The Wikipedia entry on OpenDNS also addresses some of these issues, none of which appear to exist in Google’s Public DNS.

BARcamp Chicago!

Got back from BARcamp Chicago Sunday night. It was a good time, and had a lot of good workshops. Met some good people, and used the nice high-speed bandwidth (but had to bypass the slow DNS!).

If you want an excellent DNS service, fast and unrestricted, use OpenDNS. This service also offers phishing protection, abbreviations, and spell-correction.

At BARcamp, some folks went to sleep – and some did not (like yours truly…). Several brought sleeping bags and went to sleep.

There were talks on Testing, the Bayes Theorem, Groovy, LISP, the rPath Linux distribution and Conary, and more. There was also the “InstallFest” – Linux installs made easy with help on hand. Even so, my machine was maxed out with CentOS 3 (a Red Hat 2.1AS source-compiled distro), even though I did upgrade it to CentOS 3.8. My machine is probably memorable as it had to be the oldest machine present (a Pentium-150 IBM Thinkpad) – and had no graphical interface – at least, on the machine itself. The graphical interface on the Thinkpad 760XL is rather odd – the full screen is used by “stretching” the actual display to the full size; otherwise, it only takes up about 75% of the LCD display space.

It was interesting to see (at BARcamp) that the Mountain Dew disappeared and was hard to get at the end, while there was plenty (plenty!) of Red Bull left. We know which is favored….

Next up is the Chicago Linux Group (which also hosts the Chicago Lisp Group), as well as the Madison LOPSA chapter meeting.