trusting DNS

Dan Kaminsky has (quite rightly) been hitting the press a lot in the weeks since 8 July when he announced the work done to fix a flaw he had discovered in DNS. The vulnerability itself was new, but its impact (cache poisoning) was not. Indeed, we’ve known about the dangers of poisoned DNS caches for some years now. Kaminsky originally took a lot of flak about his announcement, its timing (to coincide with Microsoft’s “patch tuesday”), his reluctance to discuss details (“trust me, it’s dangerous. I’ll tell you all about it later”) and his apparent willingness to “talk up” the issue with the non-specialist press. But all that aside, he deserves immense credit for highlighting the flaw and herding all the cats necessary to get vendors on board to create patches. He has also since been as good as his word and described the problem in detail.

However, I have a big problem with one of his blog entries: “Here comes the cavalry” where he says “Note, if you must forward, it’s most secure to do so to a name server that’s still on your network but happens to be patched — but in a pinch, you’re much better off forwarding to OpenDNS or another free and patched name service provider than going direct (and insecure).”

In my view, this is hugely ironic. Cache poisoning means that you cannot trust the answer your DNS server provides. I do not trust the answer OpenDNS provides. OpenDNS violates principles which in my view are essential to an open, transparent and trustworthy network. They hijack queries and give incorrect answers. For example, they do not reply with NXDOMAIN to a query for a non-existent host or domain. They also hijack queries aimed specifically at Google. See the dig queries below for examples.

I first came across OpenDNS when I installed packetprotector on an Asus wireless router I was playing with. OpenDNS servers were hardwired as the default DNS hosts in that package. I run my own dns internally using DNSmasq and the hosts file on that system contains the private addresses of my internal servers on my network. Imagine my surprise then, when during testing, I pinged one of my internal hosts from the Asus only to get a response back from a server with the address “208.69.34.132”. This should not happen. It is a bad thing (TM), regardless of how OpenDNS may attempt to portray this as “helping” the community.

In a discussion about Google’s toolbar, David Ulevitch of OpenDNS said, “The solution to this problem was to route Google requests through a machine we run to check if the request is a typo or one of your shortcuts. If it is a typo or shortcut then we do what we always do, just fix the typo or launch your shortcut and send you off on your way. If it’s not one of those two things, we pass it on to Google for them to give you search results. This solution provides the best of both worlds: OpenDNS users get back the features that they love and Google continues to operate without problems.”

Wrong. I do not want some third party fiddling with my DNS requests on the spurious grounds that I may have mistyped some hostname.

Make up your own mind. There is extensive discussion about OpenDNS on-line. See in particular the commentary at the scream and on wikipedia. Personally, I prefer to use my ISP’s DNS servers. I have a contractual relationship with them and I can therefore expect them to provide me with a service which works, and is trustworthy (for some definition of “trust”). Oh, and they patched their DNS servers very, very, quickly.

Now some sample dig results:

First using my default (DNSmasq forwarding to my ISP)

mick@slug:~$ dig www.google.com

; <<>> DiG 9.4.2-P1 <<>> www.google.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47551 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 7, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 604798 IN CNAME www.l.google.com. www.l.google.com. 299 IN A 216.239.59.104 www.l.google.com. 299 IN A 216.239.59.147 www.l.google.com. 299 IN A 216.239.59.99 www.l.google.com. 299 IN A 216.239.59.103 ;; AUTHORITY SECTION: l.google.com. 86397 IN NS e.l.google.com. l.google.com. 86397 IN NS a.l.google.com. l.google.com. 86397 IN NS c.l.google.com. l.google.com. 86397 IN NS d.l.google.com. l.google.com. 86397 IN NS b.l.google.com. l.google.com. 86397 IN NS g.l.google.com. l.google.com. 86397 IN NS f.l.google.com. ;; Query time: 30 msec ;; SERVER: 192.168.10.10#53(192.168.10.10) ;; WHEN: Sat Jul 26 18:03:08 2008 ;; MSG SIZE rcvd: 228 Now use openDNS mick@slug:~$ dig www.google.com @208.67.222.222 ; <<>> DiG 9.4.2-P1 <<>> www.google.com @208.67.222.222
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40840 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 30 IN CNAME google.navigation.opendns.com. google.navigation.opendns.com. 30 IN A 208.69.34.230 google.navigation.opendns.com. 30 IN A 208.69.34.231 ;; Query time: 19 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Sat Jul 26 18:04:54 2008 ;; MSG SIZE rcvd: 104 Are you happy with that? I'm damned if I am.

Permanent link to this article: https://baldric.net/2008/08/10/trusting-dns/

2 comments

    • xcore on 2008/12/14 at 6:24 am

    Just add into your /etc/hosts
    209.85.171.100 google.com
    74.125.45.100 google.com
    72.14.205.100 google.com

    and reboot.

    • Mick on 2008/12/14 at 1:52 pm

    Yes but that only addresses the (single) issue of reaching google.com. It misses the wider point of this post which is that I do not want some third party messing with the way DNS is supposed to work. Hardwiring the google.com IP addresses into my local hosts file won’t stop OpenDNS from hijacking other requests – nor will it even fix the google.com issue if google change their IP addresses.

Comments have been disabled.