I haven't seen anything posted on the OOMA forums about the upcoming DNS SEC security changes that are supposed to be implemented at the Top Level Domain Level on May 5th, I think with other phase changes going on through July I think. This is outside my area of interest (other than being affected by the changes) Most news articles think it will correct some serious DNS security flaws, while being transparent (unnoticed) to most folks. I've seen a couple of other tech articles warning of 'severe' internet disruptions however. I did run the free Ripe packet replysize test and know that my current configuration won't pass packets larger than 512bytes and that my resolver does not have DNSSEC and EDNS enabled - what I don't know is if this is going to be an issue after May 5th or going forward with the most important internet service on home network (that be OOMA), i.e - no phone = unhappy family.
donliA coupleimprove DNS security
The problem the DNSSEC articles are describing is when your server *does* set the DO bit, but can't handle responses greater than 512 bytes (firewall, intermediary, etc. is configured not to allow it) then you could encounter problems. Before May 5, you might already have had problems but didn't notice it because the first request failed and it rolled over to a server that didn't have DNSSEC enabled.
Also, most of the time people use their ISPs DNS resolver. The resolver in their router is just a mini caching resolver. So it will depend what the ISPs DNS resolver decides to do. I'm sure those guys are ready to dump the extended DNSSEC responses if they all of a sudden start getting lots of phone calls.
The distinction between May and July is in May all top-level servers will be DNSSEC aware and honor the DO bit, but will be sending dummy signature data. In July that will change to real DNSSEC data.
It is unlikely Ooma would have a problem since it would need to inadvertently set the DO bit. I don't have Ooma in the line of fire for DNS requests so I don't know if it does that, but it is unlikely. If you have run the Ripe test with the mini-DNS resolver in Ooma and it says DNSSEC isn't enabled then you will be fine after May 5.
The test is here for others that might be curious
http://labs.ripe.net/content/testing-yo ... ize-issues
You can read about the "DO" bit here:
Anyway, if I understood your response it's my ISP DNS resolution that's the key - the TLD's HAVE to change May 5th but the ISP's don't and I guess the ISP's will continue to honor older configurations that don't set DNSSEC OK for the forseeable future?
It is my understanding that the TLDs also honor the DO bit so as long as your DNS request doesn't have the bit set, your responses will be the same as always.coldsteel wrote:Anyway, if I understood your response it's my ISP DNS resolution that's the key - the TLD's HAVE to change May 5th but the ISP's don't and I guess the ISP's will continue to honor older configurations that don't set DNSSEC OK for the forseeable future?
The concern they seem to be pointing out is if your requests have DO bit set to receive DNSSEC info, you are now guaranteed to receive greater than 512 byte responses from the TLDs. If you had an undiagnosed problem with > 512 byte responses before (and had DO bit set for DNSSEC) you might not have seen any problems because even if your response from one TLD was dropped because it had > 512 bytes, DNS would timeout and query again, at which point another TLD server, which wasn't configured for DNSSEC, would give you the regular smaller response. Now since all the TLDs will give > 512 byte responses if DO bit is set for DNSSEC, if you have this problem of > 512 byte DNS responses being lost or filtered out, and you are going to the TLDs directly, the responses won't get to you anymore, essentially making your Internet unusable.
Now if you don't have DO bit set for DNSSEC info or you don't go directly to the TLDs and the resolver you are using is configured to still give you <= 512 byte responses, then there shouldn't be any issue. You indicated that you ran the Ripe test and it said that even though you can't receive > 512 byte responses, meaning you don't have the DO bit set to receive DNSSEC info. That is why I'm saying you should be fine. Your DNS responses should continue to be < 512 bytes even if you went to the TLDs directly because you don't have DO bit set for DNSSEC.
Now there could always be bugs where things don't work the way they are supposed to and that could cause issues, but if things work according to the specs, you shouldn't have issues with the May 5 transition. I can't speak for others because they could have different DNS setups from you and also have different results from the Ripe test.
I just know I'm not changing, setting or moving anything for the next couple of days so if anything breaks it won't be because I did something.OpenDNS engineer and security researcher Matthew Dempsky says the company "put a lot of thought into" adopting DNSCurve at this time and concluded it made more sense than DNSSEC because it's simpler and easier to deploy and manage than DNSSEC -- and because it uses stronger cryptography. "DNSSEC is not a very viable solution as a whole," Dempsky says. "While there are increasing efforts to deploy it ... there's been a lot of testing with questionable results. There are still a lot of compatibility issues to be worked out."
I think it is more accurate to say Dan Bernstein (of qmail and djbdns fame) developed DNSCurve. OpenDNS decided to deploy Bernstein's DNSCurve but that doesn't mean they aren't going to adopt DNSSEC (see editor's note at bottom of the announcement link below), just that they are going to take a wait and see attitude with DNSSEC. DNSCurve and DNSSEC are not mutually exclusive. One is protecting the queries. The other is protecting the records.coldsteel wrote:I hope things do go smoothly tomorrow - I've just seen some comments on dslreports that my DNS provider, OPENDNS is not going to adopt DNSSEC and that they had developed and deployed an alternative to DNSSEC, called DNSCurve.
DNSCurve basically encrypts and authenticates your DNS session (essentially doing something similar to what ssl does for https queries, but for dns and with more advanced cryptography)
DNSSEC is trying to protect the actual records themselves from tampering by signing the DNS zone records.