Dan York

Just a guy in Vermont trying to connect all the dots...

Author's posts

Could You Go for a Year Without Internet Access? Paul Miller Reports on His Experiment… (Featured Blog)

Could you sign off of the Internet today -- right now, in fact -- and not come back online for 12 months? If you are a reader of CircleID, odds are pretty good that the answer is probably an emphatic "No!" This is, after all, a site for "Internet Infrastructure" and for most of us visiting the site (or writing here) the "Internet" is completely woven into the fabric of our lives... and we have a hard time thinking of a life without it. More...

Speaking Live On VUC Podcast About DNSSEC And VoIP/UC on Friday, May 3

VUC logoWould 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!

Confirmed – Google’s Public DNS Now Performs DNSSEC Validation For ALL Queries By Default

Google logoIt’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.4

2001: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.

 

Confirmed – Google’s Public DNS Now Performs DNSSEC Validation For ALL Queries By Default

Google logoIt’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.4

2001: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.

CERN Celebrates 20 Years of The Free And Open Web (Featured Blog)

Of all the many applications and services that run on top of the Internet, arguably none has been more successful than that of the World Wide Web. Invented by Tim Berners-Lee back in 1989 while he was a physicist at CERN, the "Web" has fundamentally changed almost every aspect of our life... and become a part of basically every aspect of our life. Think of a part of your life... and then think of the websites that are part of that. More...

CERN Celebrates 20 Years of The Free And Open Web (Featured Blog)

More...

FIR Podcast Hits Episode #700 – Publishes Special Interview With Shel and Neville

As most readers probably know by now, I'm been a weekly contributor to the "For Immediate Release (FIR)" podcast since back in 2005, and all those years later I continue to find the FIR episodes extremely useful ways to stay up on what is going on with social media, marketing, PR, podcasting and the intersection of all of those topics along with technology and business.

Last week Shel Holtz and Neville Hobson, the FIR co-hosts, passed the tremendous milestone of FIR episode #700. It's a pretty remarkable achievement to publish 700 instances of anything... but of a 60-90 minute podcast, week after week after week, is pretty amazing.

Shel and Neville tried to keep the actual FIR episode #700 to be fairly "regular" in terms of content, but at a suggestion from the FIR Google+ Community, they did allow themselves to be interviewed by Donna Papacosta about the show. Both the show and the interview are well worth listening to, in my opinion.

Congratulations, Shel and Neville, on publishing 700 episodes of FIR! Now I'm looking forward to the next 700 episodes...


If you found this post interesting or useful, please consider either:


Can DNSSEC and DANE Help Make Voice-over-IP (VoIP) and Unified Communications (UC) More Secure?

Can DNSSEC help make voice and video communications over IP more secure?  Could DNSSEC combined with DANE provide a means to more easily distribute the TLS/SSL certificates needed for VoIP phones and systems?  Can DNSSEC help ensure that you are talking with the correct VoIP system or application server?  Can DNSSEC improve the security of the many WebRTC-based clients being developed? How can a DNS-based public key infrastructure (PKI) help improved the security of IP-based communications?  (whether you call it “VoIP”, “unified communications”, “real-time communications” or just simply “telecommunications”)

These were among the questions that I set out to address in a presentation at the SIP Network Operators Conference (SIPNOC) 2013 last week in Reston, Virginia. Speaking to network operators ranging from large carriers and telcos to smaller “over-the-top (OTT)” startups, I used this set of slides to frame the discussion:

I also spoke about how two VoIP software products have already incorporated DNSSEC – the Jitsi softphone and the Kamailio server – and mentioned the new “DNSSEC and IP-based Communications” resource page I’m starting to build (and for which I would appreciate any suggestions).

I don’t necessarily have the “answers” to these questions (although I have opinions :-) )… I was more starting to raise the questions. The DNS community has been building this mechanism (DNSSEC) that provides a “trust layer” and can increase the security of DNS, as well as, via DANE, the entire TLS/SSL certificate infrastructure that we have come to rely upon.  How can we use these improvements to increase the security of IP communications?

For some further context, you may be interested in this recording I made on the topic:

I think there could be some good potential benefit here – and I’m looking forward to further discussions on this topic in the weeks and months ahead.  I’d love to hear your thoughts… either as comments to this post on our site or in social networks … or via direct email to me.

How could we use DNSSEC to increase the overall security of our communications infrastructure?

 

P.S.  I’ll also be appearing on the VoIP Users Conference (VUC) podcast on this coming Friday, May 3, 2013, to discuss these ideas within that community (to which anyone is welcome to join in). More details soon… 

Comcast Launches IPv6 Trials For Business Customers – Sign Up Today

comcast business logoWe were very pleased to see news yesterday on Comcast’s corporate blog about the launch of IPv6 services for businesses. Comcast’s John Jason Brzowski wrote there that:

  • Business Ethernet customers have had full IPv6 service and support in place for them since the beginning of 2013.

  • IPv6 trials are about to get underway for our Business Internet customers and we hope to launch full support shortly after completing the trials. Customers interested in signing up to participate in the trials can do so at http://www.comcast6.net/index.php/commercial-broadband-ipv6-form.

It is excellent to see Comcast offering these trials to their business users and we look forward to hearing of the success of those trials and the move to full IPv6 support.  Congrats to the team at Comcast for getting to this point.

If you are a Comcast Business customer, now is a time when you can sign up and get started with ensuring that your networks work fine with IPv6.   Why wait?

DNSSEC and IP Communications (including VoIP, UC, RTC, SIP)

This page will serve as a repository of information related to how DNSSEC and DANE can work with communications protocols based on IP, including voice-over-IP (VoIP), unified communications (UC). real-time communications (RTC) and the use of the Session Initiation Protocol (SIP).

Documentation

  • (need to identify any documentation on this topic)

Presentation Slides

Communities

There is a good amount of discussion about DNSSEC happening in various DNSSEC communities around the Internet although at the current time there is no specific area focused on VoIP and DNSSEC.

Softphones

We are aware of the following softphones that support IPv6:

Communications Equipment and Software

Beyond softphones, we are aware of the following equipment that supports IPv6.

Additional resources will be added to this page as we become aware of them.

Know of additional resources related to IPv6 and IP communications that we should list?  Please let us know!