May 2013 archive
May 05
The Dan York Report Episode #1: Intro To The Show, And – Could You Go Off The Internet For A Year?
May 03
Could You Go for a Year Without Internet Access? Paul Miller Reports on His Experiment… (Featured Blog)
May 02
Speaking Live On VUC Podcast About DNSSEC And VoIP/UC on Friday, May 3
Would you like to chat with me (Dan York) about DNSSEC and DANE and how they might work with voice-over-IP (VoIP) and unified communications (UC)? Or would you just like to listen to my views on the subject?
If so, you can join in to the live “VoIP Users Conference (VUC)” conference call / podcast at 1:00pm US Eastern on Friday, May 1, May 3, 2013.
Based off of some of the information I shared in my SIPNOC presentation last week about DNSSEC and VoIP, I’ll be giving an overview of both DNSSEC and DANE and then opening a conversation about what possibilities there might be to use DNSSEC/DANE to provide a higher level of security to VoIP and other forms of IP telecom.
I’ll also be pointing people to our new “DNSSEC and IP Communications” page where I’m starting to list some of the VoIP tools and services out there now that work with DNSSEC (and I’m looking for more items to add).
To join the call, you can either connect in to the Google+ Hangout at 1:00 pm US Eastern – or alternatively call in via the SIP, Skype or regular old phone numbers listed on the top of the VUC page for the episode. There is also an IRC backchannel where text chat occurs during the episodes.
If you can’t listen live, the show will be recorded and you can listen to it later.
I’ve been a participant in the VUC shows for several years and it’s a good group of people and always some interesting conversation. They happen every Friday normally at 12 noon US Eastern – but due to a scheduling conflict I’m going on at 1:00pm. Do tune in tomorrow and join us in the conversation about DNSSEC and VoIP!
May 01
Confirmed – Google’s Public DNS Now Performs DNSSEC Validation For ALL Queries By Default
It’s official… Google’s Public DNS service is now performing DNSSEC validation for all DNS queries by default!
When news broke back on March 19 that Google had enabled DNSSEC validation on its Public DNS service, there was some initial concern after people noticed that Google was only performing the DNSSEC validation when requested. This led to a clarification a few days later from Google that their initial rollout required a client to request DNSSEC validation so that they could test out the service – and that full validation was coming soon.
The Official Word
Yesterday, Google’s Warren Kumari posted in the dnssec-deployment mailing list that full validation IS now happening:
We have recently enabled validation by default globally, and you should now get SERVFAIL for validation failures. Apologies again for the original, unclear announcement.
The blog / documentation has not been updated yet (that will probably happen in the next few days) but we wanted to give you the good news as soon as possible.
And indeed a quick test to see if I could get the DNS records for a test domain known to have a bad DNSSEC signature did produce the expected “SERVFAIL” message and correctly did not return any DNS records:
$ dig @8.8.8.8 www.dnssec-failed.org ; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.dnssec-failed.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60286 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A
This is great news for those of us who are advocates of DNSSEC and means that anyone using Google’s Public DNS servers for DNS name resolution are now automatically receiving the greater security of DNSSEC. Anyone using those servers will know that (for signed domains) the information they are getting out of DNS is the same information that the domain operator put into DNS – and not that of an attacker seeking to have you go to some other site.
If you, too, want to gain access to the increased security of DNSSEC, all you have to do is configure your computer or home router to have as its DNS servers the Google Public DNS servers:
8.8.8.8
8.8.4.42001:4860:4860::8888
2001:4860:4860::8844
That’s it!
Moving DNSSEC Validation Even Closer
As awesome as this move by Google is (and it is awesome), you could still increase the security provided by DNSSEC a bit more. Because Google’s Public DNS servers are not on your local network and are rather somewhere out across the Internet, there is still a chance that an attacker could insert himself or herself between you and Google’s DNS servers. The attacker could then pretend to be sending you back the correct information and masquerading as Google’s Public DNS servers.
To get the highest level of DNSSEC security, you ideally want to be performing the DNSSEC validation on at least your local network and potentially even your local computer. There’s a great whitepaper out from the folks at SURFnet called “Deploying DNSSEC: Validation on recursive caching name servers” that explains how you can simply enable DNSSEC validation for three of the common DNS servers used by enterprises and networks today.
Hey, if Google can enable DNSSEC validation, why can’t you?
If you can’t do DNSSEC validation locally (for example, if you only have a home WiFi router that doesn’t perform validation) then getting the validation performed at your ISP may be the next step… and if your ISP won’t do DNSSEC validation then you really have no other choice but to use a service like Google’s Public DNS services. Their DNSSEC validation is definitely far better protection than none at all!
Again, kudos to Google’s Public DNS team for taking this step and we look forward to the day when all DNS resolvers just perform DNSSEC validation automatically.
May 01
Confirmed – Google’s Public DNS Now Performs DNSSEC Validation For ALL Queries By Default
It’s official… Google’s Public DNS service is now performing DNSSEC validation for all DNS queries by default!
When news broke back on March 19 that Google had enabled DNSSEC validation on its Public DNS service, there was some initial concern after people noticed that Google was only performing the DNSSEC validation when requested. This led to a clarification a few days later from Google that their initial rollout required a client to request DNSSEC validation so that they could test out the service – and that full validation was coming soon.
The Official Word
Yesterday, Google’s Warren Kumari posted in the dnssec-deployment mailing list that full validation IS now happening:
We have recently enabled validation by default globally, and you should now get SERVFAIL for validation failures. Apologies again for the original, unclear announcement.
The blog / documentation has not been updated yet (that will probably happen in the next few days) but we wanted to give you the good news as soon as possible.
And indeed a quick test to see if I could get the DNS records for a test domain known to have a bad DNSSEC signature did produce the expected “SERVFAIL” message and correctly did not return any DNS records:
$ dig @8.8.8.8 www.dnssec-failed.org ; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.dnssec-failed.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60286 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A
This is great news for those of us who are advocates of DNSSEC and means that anyone using Google’s Public DNS servers for DNS name resolution are now automatically receiving the greater security of DNSSEC. Anyone using those servers will know that (for signed domains) the information they are getting out of DNS is the same information that the domain operator put into DNS – and not that of an attacker seeking to have you go to some other site.
If you, too, want to gain access to the increased security of DNSSEC, all you have to do is configure your computer or home router to have as its DNS servers the Google Public DNS servers:
8.8.8.8
8.8.4.42001:4860:4860::8888
2001:4860:4860::8844
That’s it!
Moving DNSSEC Validation Even Closer
As awesome as this move by Google is (and it is awesome), you could still increase the security provided by DNSSEC a bit more. Because Google’s Public DNS servers are not on your local network and are rather somewhere out across the Internet, there is still a chance that an attacker could insert himself or herself between you and Google’s DNS servers. The attacker could then pretend to be sending you back the correct information and masquerading as Google’s Public DNS servers.
To get the highest level of DNSSEC security, you ideally want to be performing the DNSSEC validation on at least your local network and potentially even your local computer. There’s a great whitepaper out from the folks at SURFnet called “Deploying DNSSEC: Validation on recursive caching name servers” that explains how you can simply enable DNSSEC validation for three of the common DNS servers used by enterprises and networks today.
Hey, if Google can enable DNSSEC validation, why can’t you?
If you can’t do DNSSEC validation locally (for example, if you only have a home WiFi router that doesn’t perform validation) then getting the validation performed at your ISP may be the next step… and if your ISP won’t do DNSSEC validation then you really have no other choice but to use a service like Google’s Public DNS services. Their DNSSEC validation is definitely far better protection than none at all!
Again, kudos to Google’s Public DNS team for taking this step and we look forward to the day when all DNS resolvers just perform DNSSEC validation automatically.
The post Confirmed – Google’s Public DNS Now Performs DNSSEC Validation For ALL Queries By Default appeared first on Internet Society.
