OpenDNS and The Oddity
So a lot of people here seem to enjoy OpenDNS, enough that I decided to give it a try. At first things seemed great, but then The Oddity started to show up.
The Oddity consists of loss of name resolution for local resources while connected to a VPN. It just doesn't work on the local network, or the remote network. Any request is responded to with 208.69.32.132 (hit-nxdomain.opendns.org), which I think is the OpenDNS search page where it takes you after putting an incorrect entry into the browser. While not connected to a VPN, the response just times out. I am also able to resolve external names (google and whatnot) while connected, just not the stuff that I need to get to.
This behavior went away as soon as I switched a different DNS provider (4.2.2.2, 4.2.2.1). It also comes right back if I switch to OpenDNS again.
Router is running DD-WRTv23 SP2 if that makes any difference.
I've seen that complaint before, but I don't know of a resolution.
There's certainly nothing wrong with using the Level 3 DNS servers (4.2.2.1 through 4.2.2.6) instead. I recently switched to OpenDNS mainly to familiarize myself with their filtering capabilities (so that I could known how to properly apply them to networks like my parents' or my in-laws'), but I used the Level 3 DNS servers for a long time (starting back when they were owned by GTE). They're great.
Gaming / PC Tech Blog: www.blastprocessing.net
Xbox Live: Legion SB / PSN: Legion_SB / Steam: legion028 / Twitter: legion
tits || gtfo
I wish I were as network savvy as you so I could understand what your problem is.
I have been using OpenDNS for a year now and haven't run into any problem. Maybe because I haven't been trying to do more advanced things with it.
Thanks for standin' still Wanker!
-XBox Gamertag: Tempest Blaze (Without the Y)
What OpenDNS is doing is wrong. They're returning a result for domains they know don't exist. This is horrible behavior; it's used to steal hits from typos, and it's not for your benefit. (Verisign got in big trouble for doing exactly this.) They break many pieces of software doing this, including yours, and it's a very strong reason not to use their 'service'.
Most likely, your VPN software is depending on getting the correct 'NXDOMAIN' response from the first DNS provider. That returns to the software stack with an error, which the VPN software can intercept and work with, perhaps simply by resubmitting to another DNS that's internal to your network. But when OpenDNS falsely claims to know about these internal domains, that screws up your software. It goes to their servers instead of yours. This is extraordinarily bad behavior on their part; it's essentially lying to you to drive traffic to their servers.
If you have a wireless access point that runs one of the open firmwares, you can just use that as a DNS provider. (make sure it's a recent version, and test to make sure it's proparly randomized; there's another thread on how to do that.) It'll work better than anything out of your network would, and by not sharing the server with others, you're much less likely to have a cache poisoning attack that's successful.
Fixed. Saying that it's flat-out wrong is very narrow-sighted (I would definitely agree if we were talking about an ISP provided DNS server, but not a free, optional, unattached 3rd party service). Yes, the lack of an NXDOMAIN response can interfere with certain things (some spam filters use it to see if a claimed source domain exists). But for some, having failed DNS requests go to a friendly "this domain doesn't exist" or "this domain isn't responding" landing page is welcome behavior.
You use OpenDNS if the added features are something you want. If you simply want plain DNS, that's what the Level 3 servers (or running your own) are for. If I was, say, administering some public-use computers at a library, I wouldn't give two sh*ts about the fact that failed DNS requests don't get an NXDOMAIN response. I'd be happy with the easily used content filtering.
Oh, and pol, I noticed something in the OpenDNS page help section: VPNs and OpenDNS - use Typo Exceptions
Gaming / PC Tech Blog: www.blastprocessing.net
Xbox Live: Legion SB / PSN: Legion_SB / Steam: legion028 / Twitter: legion
tits || gtfo
Yeah I'm fine with Level3, I just though the behavior was quite odd, and figured one of you guys might have run into this.
My main curiosity was with the different behavior while connected to a VPN. All this configuration was done at the router, and I am not using the remote gateway. If I am not connected to the VPN, the requests time out. If while connected to a VPN I use nslookup to attach directly to the OpenDNS servers, it times out. It's only when the requests are sent to my local appliance that they return this value. Again I would assume that something is odd with the router, yet when I use a different set of DNS servers it disappears. The router runs DD-WRT, and is set to defaults, which means that I have DNSMasq enabled and Local DNS disabled....the difference is lost on me, and it doesn't seem to be an "either or" setup. The VPN software is just the built in PPTP stuff MS uses.
Time to go see if I can recreate it with different equipment I suppose
Legion: I'll check that out as soon as my account gets created...I sure do hate registerin for stuff
Warrior Asherr
Hunter Ghorin
That behavior is as intended by OpenDNS, it is how they generate revenue (from what I understand, I don't use it). It is what allows them to keep the service at the price level it is at.
"Also, I have four legs and am covered in wool. Baa!" *Legion* reveals his inner furry.
Any user can also opt-out of the mistype redirection too so there's really nothing wrong about it. Most ISPs are doing it and I do have a problem with that because they're using it to earn money off a service people already pay for. There's no requirement for anyone to use OpenDNS.
This thread is rather interesting to me as I've been having a similar problem and I do run Hamachi all the time. I've used OpenDNS for a long time but lately I've been having problems with my Internet connection seeming to stop every week or so. Reconnecting doesn't solve the issue, even though the router does re-establish no problem and my local network was unaffected. I'm using a special Multilink PPP version of the Tomato WRT54G firmware (my ISP TekSavvy uses the MLPPP protocol to circumvent Bell Canada's illegal throttling measures) and I thought maybe it was a bug with it but no one in the TekSavvy forums reported problems. I also wondered why my company's VoIP line continued to work. Then I remembered that my VoIP box is configured to connect to a server on an IP address only. I switched my DNS back to TekSavvy's and we'll see what's happening. If this is a glitch with OpenDNS, I hope it's something they can resolve.
"We're taught from a young age how to dodge rock hard objects moving at incredible rates of speed while simultaneously beating folks half to death with sticks. We do this for fun." -kung fu grip
http://blog.digital-lifeline.ca
Re-fixed. What they are doing is a violation of the specification, and will break any and all VPNs that rely on secondary DNS servers to provide name resolution for internal networks (along with a host of other services that rely on proper DNS failure). Basing your business model on breaking your customer's equipment is not a good way to go.
That said, they have a one off solution that might work.
Remember: this conversation is just between you and me ... and the NSA.
MaverickDago wrote:
It really is just wrong. It breaks things. The standard says that you return NXDOMAIN, not a false result.
Verisign got in big, big trouble when they tried to do it, and rightly so.
I don't see what benefit you get from this, but if you want it, it should be a service you opt in to, not out of. Violating a standard after the customer gives you explicit permission is okay, but defaulting to doing it wrong just screws things up in mysterious ways. See: first post in this thread.
It'd be much better to do that at the application level; I imagine there's probably a Firefox extension or two that would do the same thing without screwing up your network stack.
As far as 'that's how they pay for the service!' -- like I said, it's not for your benefit, it's for theirs.
Care to point out where? The IAB's commentary on Verisign started right out by essentially saying that there is no such standard defining this behavior, but rather a particular behavior was widely "assumed".
You can argue it as a de facto standard, but if you're going to say that "the standard says" something, then I'd like to see where. If it does exist, hey, thumbs up for you, as I haven't been able to find it myself.
Gaming / PC Tech Blog: www.blastprocessing.net
Xbox Live: Legion SB / PSN: Legion_SB / Steam: legion028 / Twitter: legion
tits || gtfo
But again, OpenDNS is completely optional. There is no ISP that I know of that forces you to use it. The criticisms of it are valid for some I'm sure but those people can stick to their ISP's DNS. When I started having this issue (which I have this thread to thank for alerting me to), I switched back to my ISP's DNS and things are fine now. I'd like OpenDNS to fix it but if they don't, I go away. And yes, the financial benefit is their's and in return, we get the benefit of their service being free. If I was paying to subscribe and still being subjected to this (which is happening for customers of ISPs such as Rogers here in Canada), I'd definitely be ticked off. But that's not the case here. They have to pay the bills somewhere and I just don't get the logic of criticizing the way they do so when it keeps it free and no one's forcing you to use it.
"We're taught from a young age how to dodge rock hard objects moving at incredible rates of speed while simultaneously beating folks half to death with sticks. We do this for fun." -kung fu grip
http://blog.digital-lifeline.ca
I looked a little, and no, it doesn't explicitly say that, any more than it says a DNS server shouldn't try to crash clients. Returning valid results is just fundamentally assumed by the purpose it serves.
A DNS server is supposed to tell the truth. That's what it's FOR. Deliberately supplying false information is wrong. If xyz.com doesn't exist, you say so, instead of lying and telling the resolver that it's a valid name.
You don't always get correct results from a DNS server, mostly because of caching issues, but it's a fundamental given of the standard that it's supposed to do its best to tell you what it knows. Knowingly giving an incorrect result violates the entire purpose of consulting a DNS server in the first place. Clients are looking for the truth, not a cooked up result to benefit whoever's running the server.
A lot of other software depends on the DNS system telling the truth. Changing that behavior, being deliberately deceptive, breaks that software.
Servers that lie are not good servers.
Ridiculous hyperbole doesn't make for useful conversation.
Gaming / PC Tech Blog: www.blastprocessing.net
Xbox Live: Legion SB / PSN: Legion_SB / Steam: legion028 / Twitter: legion
tits || gtfo
It's not hyperbole. It's a basic assumption about what a server does. You don't expect them to misform data to crash clients, and you don't expect them to send incorrect results for the benefit of the server operators.
There are some things that are so basic that they're not included in specs.
No problem. How about RFC2132, DHCP, along with RFC2937 DHCP name service search option. It's not immediately obvious why, of course. Consider this scenario: a local administrator wants his clients to search DNS first, then mDNS, then hosts files. He implements that, and it doesn't work - his clients are never able to resolve local mDNS services or hosts in the local hosts files. Why is that? Because everything is built on the expectation that DNS will fail correctly. If DNS resolution never fails, things never fall through to the secondary name-resolution mechanism. The parts of DHCP that refer to name server options and search orders are made to be non-functional by wildcard typosquatting. Wildcarding entire TLDs basically prevents a significant portion of the RFC from even being relevant.
This kind of subtle breakage is all over the place. RFC 2308 is eviscerated, since there will never be any negative caching - all queries succeed. Mail servers that are supposed to spool mail when a domain is temporarilty unresolvable don't, returning error messages instead, fail silently, or fail noisily (by sending mail to a "server" that doesn't represent the domain in question, such as what happened with VeriSign and their SiteFinder fiasco). We already know about the VPN problems.
The assumptions are built into every RFC that depends on DNS.
Remember: this conversation is just between you and me ... and the NSA.
MaverickDago wrote:
I think this part might be wrong. I don't know this for sure, but I very much doubt that OpenDNS would give incorrect results for domains that exist in the public search space. They're typosquatting, not hijacking actual domains. I suspect that returning spurious results for domains that actually existed could land them in serious legal trouble in very short order.
I think mail mostly wouldn't be affected by using OpenDNS, with the exception of one corner case. If a mail forwarder were using DNS to forward between the public Internet and a private search space, and was set to query the outside first, that could break. But setting up a gateway in that fashion would be odd, and prone to breakage anyway. Normally, you'd query internal servers first, before hitting external ones. And why on earth would you be using OpenDNS in that kind of situation, anyway? You'd be running your own server. (Hell, I probably wouldn't even use DNS on a transition machine like that: I'd probably use hardcoded IP addresses to get things into my internal network instead. Less to go wrong.)
But, yeah, there are some assumptions that are so fundamental that you just don't bother to explicitly write them down. I don't see any true difference between returning wrong results for ibm.com (ie, hijacking IBM's namespace) and returning wrong results for aiomgnashdas.com. Both are misrepresenting the truth for the benefit of the server operators. The second form is less severe, and it would be much harder for them to get sued for doing it, but it's the same thing at different intensity scales.
It's worth pointing out that when Verisign tried to do this, all DNS servers that I know about were updated specifically to discard those spurious results. At least in BIND 9, you can re-enable Sitefinder (should Verisign restart it) by removing a configuration option, but by default they ignore typosquatting. So it's pretty apparent that the Internet community as a whole thinks this is misbehavior.