Hacker News new | past | comments | ask | show | jobs | submit login

why not just use opendns.com? you get all of these `benefits` and more without you having to configure and maintain a DNS server.



Does OpenDNS still hijack addresses that don't resolve for ads?


Yes, they fuck with NXDOMAIN.

I don't understand why anyone puts up with them. I suspect because they have the word "Open" in their name.


One reason I don't use OpenDNS.com or Google DNS is that it means I might not hit the optimal CDN for me. Maybe they have improved things but last time I used it, I often ended up hitting CDN end points that were not optimal. For example, downloading MSDN content was slow. If I switched to my internet service providers DNS servers, I would hit a more optimal CDN end point that was faster. I had a similar experience with Netflix.

Note my example with MSDN took place a while ago so it might be replicable today.


It might be worth trying again, at least in theory, you should get correct CDN endpoints whatever happens. I suppose there might be an exception to this if a CDN has edge nodes within your ISP though. There's a bit more detail at https://developers.google.com/speed/public-dns/faq#cdn


My solution is to use my provider's DNS servers first and Google DNS after those.


Using OpenDNS does not provide all the benefits of running your own DNS server where "benefits" includes fine grained control.

Additionally OpenDNS has some behaviors that network admins aren't crazy about. OpenDNS will return an answer for queries with no authoritative match. For example, if you query `dig noexist.example.com @208.67.222.222` (that's an OpenDNS resolver IP), you'll get answer: 1 and an IP address. This is considered a "feature" by OpenDNS, but from a purist's perspective, it is a breakage.

We do not run our own DNS server for client name-resolution, because we don't have any need for the control it provides. I acknowledge that some people do, however.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: