This is a follow-up post about OpenDNS that I wrote about previously. Founder David Ulevitch responded to my concerns, to which I have responded over email and I’d just like to share it here along with some afterthoughts.
These points may not make much sense without reading the previous post so if you might want to first read David’s comments.
- I have configured some of my boxes to use OpenDNS, and it has been going well. I have not measured the performance but I trust that OpenDNS will do everything in their capacity to keep the service responsive. After all, that is their most basic value proposition!
- I still maintain that negative caching is essential, even though David attested that it “doesn’t impact [their] nameserver as much as it would impact [their] webserver.” Just to recap, if you turned off the typo-correction feature and query for a non-existent domain, it will return you an NXDOMAIN response with no record. Most recursive DNS servers in this scenario would return you the SOA record for the parent domain. The SOA minimum field value is then used by the resolver for negative caching so that the next time the same domain is asked within a short period of time it doesn’t need to ask the upstream server again. Not only does it reduce the load on OpenDNS, it also saves time on the client the second time the same name needs to be resolved (assuming the resolver understands negative caching.) Why OpenDNS is not doing it is beyond me.
- David disagrees with my view that shifting DNS resolution responsibility from the ISPs to OpenDNS is a big problem. His point is that the reliability and feature set of OpenDNS will make the service attractive to companies that wishes to outsource recursive DNS to a third party. That’s fine, but I’m talking about home users who use OpenDNS servers and call up their ISP whenever something is not right. If something were to go wrong between the ISP and OpenDNS’s servers, they will be the only customers experiencing DNS black-out and the ISP call centre will have to take the calls. For example, I’m in Australia and I’m using OpenDNS as my upstream DNS server. If the southern cross cable has a fault (as it happens fairly frequently), I may get very limited connection to the US. In order to verify that only International traffic is affected, I would visit some Australian sites and see that everything is fine. However, because my queries have to go across the Pacific, it would probably not make it through at times like this. This is just an example but links can go down between any two points on the network and most of the time it is out of OpenDNS’ control.
- I like what OpenDNS is doing and am all for having more control over my Internet access. For the record, I do think that DNSBL’s are necessary but don’t believe it should be a binary switch no matter how many blacklists assert the same information. Some other mechanism is required to make the decision to flip the switch (like SpamAssassin’s hosts of heuristics.)
- I also pointed out a potential problem area for OpenDNS because ads are served on non-existent domains. For example, the domain “verizon-wireless.com” is not registered as of this writing (and Verizon uses the dashless version verizonwireless.com). Typing that in your browser while using OpenDNS brings you to the OpenDNS’s search page, which has dashless version as the first hit – very good. But the user could also click on other links on that page. Furthermore, I don’t understand why a hidden-frame is used in the search page (if you clicked on any link in the search page, the non-existent domain is still on the URL bar.) I’m not saying there’s anything unethical about that; recognize that some companies are sticky about it, Verizon being one such example (as I’ve witnessed in their dispute with eNom at ICANN Marrakesh.)
On the bright side, I wonder if on-the-fly IDN homograph detection is possible using OpenDNS. It wouldn’t be politically right but nevertheless an interesting use-case.
The usual disclaimer about these ramblings being my personal opinion and not of my employer applies.