OpenDNS Forums
The official support and discussion site of OpenDNS
Support
K-12 Forums
Categories
- Administrative
- Adult site blocking
- DNS-O-Matic / dynamic IPs
- Domain blocking
- Domain Name System (DNS) troubles
- Mobile instructions
- OpenDNS services
- Proxies, accelerators, and more
- Router instructions
- Satellite
- Shortcuts
- Wishlists and feature requests
-
Feeds
Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.
This discussion has been inactive for longer than 30 days, and is thus closed.
-
Hi,
Looking at the 'Systems Affected' section of http://www.kb.cert.org/vuls/id/800113 shows that OpenDNS has a status of 'Not Vulnerable'. Furthermore, this blog by Allison Rhodes http://blog.opendns.com/2008/07/31/welcome-new-opendns-users/ states "Since OpenDNS’s servers are not vulnerable - never were vulnerable, actually..."
Can anyone explain how this is, please?
Is it simply that OpenDNS have always used port randomisation to increase the time required to successfully attack the resolver to a point where it takes long enough for it to be considered 'Not Vulnerable'? In which case are the OpenDNS servers vulnerable to committed attacks of the intensity and duration outlined here by Bert Hubert http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01194.html and alluded to by Dr Paul Mockapetris: "An attack might be possible in five hours with the patch. That's much better than the minutes an attack might have taken before but systems are still not really protected. It's bought time without solving the underlying problem," [ Source http://www.theregister.co.uk/2008/11/12/mockapetris_interview/ ]
Or is it that other methods are used to remove the threat completely? If so, can anyone outline what those methods are or, alternatively, point me to a resource which does?
Finally, have anyone seen http://www.ietf.org/internet-drafts/draft-barwood-dnsext-fr-resolver-mitigations-08.txt which describes a software tool for 'mitigating against spoofing attacks on DNS'? If so, can anyone comment on the necessity or value of such a tool both in general terms and in relation to a client being served DNS resolution via OpenDNS?
TIA,
Ian.. -
- CommentAuthorinfinity306
- CommentTimeApr 27th 2009 edited
Did you click on opendns on the Cert KB article's list? it is explained there...Well at least as best as you are probaly going to get without Opendns potentially giving hackers too much info..
"OpenDNS was never vulnerable to this class of attack at any time. Our security model incorporates a number of security enhancements not commonly found in DNS implementations above and beyond the use of a strong TXID and source port randomization."
http://www.kb.cert.org/vuls/id/AAMN-7GDQALThankful People: 1an -
Hi infinity306,
Thanks for your reply.
Yes, I had seen the TXID comment but I guess I was hoping for a little more 'meat-on-the-bone' if I'm honest.
I appreciate that (as far as I understand) OpenDNS uses a lot of proprietary code in its implementation (although it was originally based on djbdns if I remember correctly) and I obviously wouldn't expect OpenDNS to make themselves susceptible to attack by discussing their security measures in great detail.
However, I guess I was hoping for a comment (preferably from OpenDNS themselves
) along the lines of:
"We acknowledge the work done by Bert Hubert and the concerns held by Dr Paul Mockapetris and can confirm that OpenDNS is remain - and have always been - completely invulnerable to cache poisoning attacks regardless of the time taken and/or bandwidth used due to our implementation of the following countermeasures:
1) TXID
2) Source port randomization
3) 'ABC' countermeasure
...
N) 'XYZ' countermeasure"
FWIW, I'm not suggesting that OpenDNS is vulnerable. It's just that as some time has now passed since the original July '08 announcements and the fact that there are still some rumblings in the technical press about DNS services being vulnerable, now might be a good time for an announcement that qualifies OpenDNS' position with regard to Hubert's/Mackaptetris' observations and concerns.
Regards,
Ian.. -
- CommentAuthorinfinity306
- CommentTimeApr 27th 2009
What no Mention of Dan Kaminsky? After all he is the 1 who discovered the Flaw, and is mentioned in most of your links...http://www.doxpara.com/?s=opendns, He himself suggests OpenDNS. -
- CommentAuthormaintenance
- CommentTimeApr 28th 2009
Yes, some different vulnerabilities continue to be found, but OpenDNS' DNS implementation has been very sound. Djbdns is also very good, even though Mr. Bernstein had to confirm a vulnerability in his implementation (something different - not the Kaminsky pwnage), which was patched.
Interesting you should mention it, though. Guess who has co-authored a draft with Hubert, if not Mockapetris?
http://tools.ietf.org/html/draft-hubert-ulevitch-edns-ping-01
Let's not forget Paul Vixie and Daniel J Bernstein, along with Dave Ulevitch nad Dan Kaminsky. Many others are in vulnerability research as well as those creating DNS servers.
Did that wander around too much?
Thankful People: infinity306, 1an -
@infinity306
"What no Mention of Dan Kaminsky? After all he is the 1 who discovered the Flaw, and is mentioned in most of your links...http://www.doxpara.com/?s=opendns, He himself suggests OpenDNS."
Well, Dan didn't really discover THE flaw, he discovered a variation on a well known DNS cache vulnerability. What Dan did that others had so far failed to do, was to whip up sufficient industry interest and help liaise to get a fix applied. Actions for which he was rightly applauded.
As Hubert points out in his blog of July '08 [ http://blog.netherlabs.nl/articles/2008/07/09/some-thoughts-on-the-recent-dns-vulnerability ] the Kaminsky 'patch' was all well and good, but the broader issue was known about many years before then - to the point where Bernstein's 1999 release of djbdns already contained countermeasures to it and Hubert himself wrote a blog about a proposed RFC in May '06. Disappointingly, nearly three years later, it still only has 'Auth48' status but does now at least have a RFC number (http://tools.ietf.org/html/rfc5452)
Furthermore, the original question asked in this thread related to comments made by Hubert and Mockapetris _after_ the Kaminsky patch was applied. They postulated that the patch didn't absolutely stop an attack from being successful, but rather extended the probable time required from minutes to hours (given sufficient bandwidth.)
So, no mention of Dan although I admire the man's contribution(s) to DNS security.
My request was for confirmation that OpenDNS isn't vulnerable to either the specific 'long-and-hard' variation of the 'Kaminsky' vulnerability nor to DNS cache spoofing / poisoning / call it what you will in general.
I'll re-iterate that I don't think OpenDNS is vulnerable and from an operational perspective I will continue to use it and recommend it.
From an academic perspective however, I would like to see some comment and/or confirmation from OpenDNS themselves with, if possible, explanations as to why they are secure.
ATB,
Ian.. -
Administrator1an,
Have you seen the IETF draft that Bert co-authored with our CTO?
http://tools.ietf.org/html/draft-hubert-ulevitch-edns-ping-01
We also have countermeasures we will not be discussing publicly.Thankful People: infinity306, maintenance -
miked
"We also have countermeasures we will not be discussing publicly."
Well, that is somewhat re-assuring, but claims of security by obscurity are not 100% ideal. Do you use BIND, Unbound or your own DNS resolver/cache software? Quickly viewing your site I didn't notice where you state that.
Would OpenDNS be planning to make use of edns-ping to secure the stub resolver <-> OpenDNS hop against spoofing? While stub resolvers are more difficult to attack than public resolvers, they typically only have 16 bits of protection against spoofing, since port randomisation is either not implemented or reversed by NAT devices, which is less than ideal.
George Barwood -
- CommentAuthormaintenance
- CommentTimeApr 29th 2009
OpenDNS has it's own brew.
I don't think that this is necessarily security through obscurity (although it could be). There are other reasons not to disclose such information.Thankful People: miked -
Hi miked,
"Have you seen the IETF draft that Bert co-authored with our CTO?"
Yes, thanks to it being mentioned it earlier in the thread. (Thanks, maintenance :-)
David (Ulevitch) has been kind enough to reply to me off-board. Amongst other things, he tells me he hopes to make a comment here soon.
ATB,
Ian..Thankful People: maintenance -
- CommentAuthormaintenance
- CommentTimeMay 1st 2009
Very cool. I'll be interested in anything David U. has to say.
1 to 11 of 11
This discussion has been inactive for longer than 30 days, and is thus closed.
