Category: DNSSEC

Apr 08

New Maps Show Current State Of Global DNSSEC Deployment

Do you want to see where DNSSEC has been deployed around the world? We’re now delighted to publish a series of maps showing DNSSEC deployment on a global and regional basis. The maps can be found here:

http://www.internetsociety.org/deploy360/dnssec/maps/

The maps are created by Shinkuro, Inc., and we are publishing them with their permission and support. The maps will be updated regularly and we’ll be updating the page periodically when there are major changes.

You are free to use the maps in presentations or other materials. Note that there is a high-resolution PDF file for the global map. For those looking to see the trends, there is also an animated GIF that shows the deployment trend over the past as well as into the future (based on public statements around future deployment plans).

2013-04-03-2013-04-03

We’re pleased to bring you these maps… and look forward to the day when even more of the map is colored in green!

Apr 04

Report: Signed Root Deployment – Framing the Issues (DNSSEC Industry Coalition, 2009)

Report on issues with signing the DNSSEC rootIn April 2013, Steve Crocker circulated this report with the following comment:

In June 2009, a year before the root was signed, the DNSSEC Industry Coalition, led by PIR, and the DNSSEC Deployment Initiative, held a symposium, Signed Root Deployment: Framing the Issues, to look at possible consequences of signing the root and the next steps after it was signed.

We had an excellent symposium and drafted a report.  Sadly, we couldn’t quite complete the editing process, so the draft lay unpublished, incomplete, since then.

The concerns expressed during the symposium about the consequences of a much larger root zone are now well behind us.  However, the sections on key distribution and use and on key rollover remain relevant, which is why we are pushing this draft out at this late date.

We are posting the report here at Steve’s request to make it available to the larger community.

Apr 02

ICANN Seeking Comment on DNSSEC Root Key Rollover Process

ICANN.jpgWhen should ICANN roll over the root Key Signing Key (KSK) that is at the core of the DNSSEC global chain of trust? How often should it do a rollover? What kind of notifications should be made in advance? What else should be considered?

These are some of the questions for which ICANN is seeking comment in their “Consultation on Root Zone KSK Rollover“.  They want to hear from a range of people out there on several specific questions they list.

COMMENTS ARE DUE BY APRIL 12, 2013!

All comments are to be sent to comments-root-zone-consultation-08mar13@icann.org.  Do note that submitted comments are posted publicly on ICANN’s website (which enables you to also see what others are saying) after being reviewed by their team.

To step back and explain this a bit, the “Root Zone Management Partners” of ICANN, Verisign and NTIA signed the root of DNS back in July 2010. For those who want the full details, the DNSSEC Practice Statement (DPS) for the root zone KSK spells out the process that occurred.

In keeping with common practice, there are two keys for the root zone: the Key Signing Key (KSK) and the Zone Signing Key (ZSK). The ZSK is used to sign all the records in the root zone – and the KSK is used to sign the ZSK.  The ZSK is rolled over quarterly, as described in the DPS for the root zone ZSK.

The root zone KSK has NOT yet been rolled over since the key was put into production in July 2010.

Rolling over the keys in any kind of system such as DNSSEC is an important part of ensuring the system’s integrity.  Generating and deploying new keys limits the exposure should an attacker somehow be able to compromise a key.  ICANN has a contractual requirement to perform a KSK “within 5 years” of the deployment of the root zone KSK, i.e. by sometime in 2015.

ICANN is asking for comments on a specific set of questions (although the last one is rather open-ended):

  1. What prerequisites need to be considered prior to a first scheduled KSK rollover?
  2. When should the first scheduled KSK rollover take place?
  3. What should the IANA Functions Operator (ICANN) and the other Root Zone Management Partners do to gauge the technical and end-user impact of a KSK rollover following the first scheduled KSK rollover?
  4. How often should a scheduled KSK rollover take place, following the first one?
  5. How far should the published calendar for scheduled KSK rollovers extend into the future?
  6. What public notification should take place in advance of a scheduled KSK rollover?
  7. What other considerations are necessary for the Root Zone Management Partners to take into consideration prior, during, and after a planned key roll over?

They have also published a PDF file with more background and information.

From our perspective, this is an extremely important consultation and:

WE STRONGLY ENCOURAGE READERS TO SUBMIT COMMENTS BY APRIL 12th!

In our view within the Deploy360 team, we believe that the root KSK needs to be rolled sooner rather than later and should be rolled over on a regular basis.  We believe there needs to be solid operational experience with rolling the root KSK so that in the unlikely event that the KSK ever should be compromised an emergency KSK rollover could be rapidly performed with minimal impact. We obviously hope that a compromise of the root KSK will never occur, but see value in having the operational experience so that an unscheduled rollover can be more of of a routine process.  There may also be problems found in the initial KSK rollover and we need to find those issues out NOW while DNSSEC is still in the early stages of deployment. If we are going to break anything, lets do it now and fix things before DNSSEC gets massively deployed.

In speaking with others about this issue, I’ve generally found most people having a similar viewpoint. But I have seen some points of view in some mailing lists that we should not roll the KSK this early in the deployment as it could have a negative impact on DNSSEC deployment.  As mentioned earlier, the counterpoint is that if a root KSK rollover breaks something, let’s find that out now.

ICANN wants to hear from you – and is again seeking comments up through April 12.  Please take a moment to read the consultation document and provide comments if you can.

Note that there will be a session at the DNSSEC Workshop at ICANN 46 next week in Beijing specifically on this KSK rollover topic that will be available for remote viewing (albeit at 2:15pm Beijing time).

P.S. If you would like to understand more about key rollovers, section 4.1 of RFC 6781 goes into detail about different rollover processes.

UPDATE #1: When this post was first published, the comment due date in the block quote near the top incorrectly said the due date was April 20th. This was corrected.

Apr 01

DNSSEC Presentations Coming Up at ICANN46 in Beijing

ICANN 46 logoNext week at the ICANN 46 meetings in Beijing, China, there will be a series of DNSSEC-related workshops. I (Dan York) will be there at ICANN 46 and will be participating in these sessions. If you are able to attend in person, the events will be an excellent way to learn more about DNSSEC.

NOTE: Remote participation IS possible. See the links below to listen to the live streams.

The major DNSSEC-related meetings are on Monday, April 8, 2013, and Wednesday, April 10, 2013. They are:

DNSSEC for Everybody – A Beginner’s Guide

Monday, 8 April 2013 – 5pm-6:30pm, Auditorium – http://beijing46.icann.org/node/37065

This very basic introductory session is aimed to help attendees understand more about how DNSSEC can secure the Domain Name System and make the Internet more secure. As DNSSEC gets more widely deployed it is critical to understand how DNSSEC works. This session provides an interactive and fun way to learn how DNSSEC works, what tools are available to help and what best practices are currently being used.

DNSSEC Workshop

Wednesday, 10 April 2013, 8:30am-2:45pm, Rainbow – http://beijing46.icann.org/node/37125

This 6+ hour workshop brings together industry leaders on DNSSEC for a series of panel discussions about the state of the art in implementing DNSSEC, current best practices, government regulations and operational practices. Sessions also include talks about the latest and innovative uses of DNSSEC. Panels at ICANN 46 include:

  • Introduction and DNSSEC Deployment Around The World
  • DNSSEC: Regulative, Legislative and Persuasive Approaches to Encouraging Deployment
  • DNSSEC Deployment in Asia Pacific
  • Use of DNSSEC in the Reverse Name Space
  • The Operational Realities of DNSSEC
  • DNSSEC Innovation: DANE and Other DNSSEC Applications
  • Root Key Rollover

There will be case studies and reports on some of the latest tools. Of interest to many may be the talk from someone at CNNIC about China’s plans for deploying DNSSEC and signing .CN.  I’ll be moderating the panel on “DNSSEC Innovation” as well as providing a brief tutorial about the DANE protocol and how it helps.  Several of the other panelists will also be talking about DANE so it should be a good session.

I’ve attended several of these workshops now and have been very impressed by the quality of the sessions in terms of technical content.  If you’re at all interested in DNSSEC, I really can’t recommend the event strongly enough.  In full disclosure, I joined the Program Committee for this ICANN 46 workshop, so I’m a wee bit biased… but it also means I’ve seen many of the proposals as well as the completed slide decks – and I can say that there will be some excellent sessions there.

On Monday evening, there will also be an informal gathering of people involved with implementing DNSSEC to discuss and exchange information about DNSSEC implementations.  As noted in the email announcement, you need to RSVP by Thursday, April 4, as it is being held at a local restaurant and a count of attendees is needed.

In looking over the ICANN 46 schedule, another meeting I will probably attend is the “Joint DNS Security and Stability Analysis Working Group (DSSA)” on Thursday, April 11, 2013.  While it is not specifically about DNSSEC, it relates to “DNS security” in general and I would think it should be a rather interesting session given the recent DDoS attacks going on that are using DNS amplification.

If you are going to be at ICANN 46 and would like to meet with me to talk about DNSSEC, IPv6, routing resiliency or just Deploy360 in general, please feel free to drop me a note or find me in one of these sessions mentioned here.

You can also listen to an audio version of this post at:

Mar 29

Comcast Publishing Domains Failing DNSSEC Via Twitter

Comcast DNS Twitter accountHow do you know when a domain is failing DNSSEC validation? What if there was a way to let the broader industry know about these validation failures?  The folks over at Comcast’s DNS team have been trying an experiment for a while in posting these DNSSEC validation failures publicly to Twitter at:

https://twitter.com/comcastdns

If you are a system/network operator deploying DNSSEC and want to be alerted when sites are found to be failing validation, following this Twitter account is one way you can get alerts.

I don’t know whether publishing domains failing DNSSEC validation via Twitter will really be a long-term solution to letting the wider industry know about domains that are currently failing validation, but I applaud Comcast’s DNS team for trying something different … and I do follow the account myself because I find the occasional tweets interesting to see.

Mar 27

APNIC Offering DNSSEC Training in Mongolia April 1-3

APNIC logoWe noticed that our friends over at APNIC are offering DNSSEC training in Ulaanbaatar, Mongolia, from April 1-3 and since, well, we’ve never written anything about Mongolia on this site before, we figured we ought to do so!

The course is APNIC’s DNS/DNSSEC workshop and sounds like an excellent offering.  Given that APNIC was recently tweeting about this event we are assuming there is still space available.

The training session is one in a whole series of training workshops APNIC is offering on topics including DNS/DNSSEC, IPv6, Routing and more.

Given that Mongolia’s .MN TLD is signed with DNSSEC (as shown in the list of signed TLDs), we’re looking forward to seeing more signed .MN domains and more usage of DNSSEC in Mongolia after this workshop!

Mar 27

Video: Emil Ivov about Jitsi, a VoIP softphone supporting IPv6 and DNSSEC

jitsi.jpgThe Jitsi audio/video softphone and messaging client supports both IPv6 and DNSSEC.  How did it get started with IPv6 support?  Why did it add DNSSEC? What value does DNSSEC add to VoIP and IP communications?   We first wrote about Jitsi’s DNSSEC support almost a year ago, but earlier this month at IETF86 I had a chance to sit down with Jitsi project lead Emil Ivov and ask him these questions and much more:

Jitsi is available for Windows, Mac OS X and Linux from:  http://jitsi.org/  It used to be called the “SIP Communicator” but when they added support for XMPP (Jabber) and XMPP/Jingle back in 2011 they changed the name to be Jitsi.

Given my own personal interest in VoIP / IP communications, I’m planning to write a bit more about Jitsi as I get a chance to do so.  If any of you use Jitsi and create any screencasts about its IPv6 or DNSSEC support – or write up any articles about those capabilities – please do let us know as I’d like to include more on our site about this great project.

Mar 26

Video: What are “Negative Trust Anchors” for DNSSEC?

What are “negative trust anchors” for DNSSEC? What function do they perform? Why do we need them? In this video, Dan York interviews Jason Livingood about his Internet-Draft on this topic and answers these and other questions:

The Internet-Draft can be found at:

http://tools.ietf.org/html/draft-livingood-negative-trust-anchors

Jason and his co-author are seeking comment and would appreciate feedback from people about this draft – does it make sense? Would you use it? Do you see any ways to improve their ideas? Their email addresses can be found at the end of the document and they are definitely open to feedback.

Jason Livingood is Vice President of Internet & Communications Engineering at Comcast and is one of the co-authors of this draft.

More information about DNSSEC can be found at the Deploy360 website at:
http://www.internetsociety.org/deploy…

This interview was recorded at the 86th meeting of the Internet Engineering Task Force (IETF) in March 2013 in Orlando, Florida, USA.

Mar 25

Slides: DANE, the next big thing after DNSSEC

What is the DANE protocol all about? How does it protect Internet communication? How does it relate to SSL/TLS certificates? What is wrong with the Web’s public key infrastructure (PKI), anyway?

At a recent cybersecurity conference in the Netherlands, Marco Davids of SIDN gave a presentation titled, “DANE, the next big thing after DNSSEC,” that covers these and other questions – and does so with a good degree of detail. His slides are available:

DANE presentation by SIDN

We, too, agree that DANE has a great potential to make the Internet much more secure by marrying the strong integrity protection of DNSSEC with the confidentiality of SSL/TLS certificates. We would encourage you to look at our DANE resources and start looking at what you can do today!

Mar 22

Google Clarifies DNSSEC Support – Opt In Now, Full Validation Coming Soon

Google logoAfter Google’s announcement earlier this week of DNSSEC validation support in their Public DNS service, there was some concern and discussion in various DNSSEC mailing lists about the fact that DNSSEC validation was not being performed by default and required a client to request validation.  Folks at Google clarified that this was just part of their initial rollout and that providing full validation is in their plans.

They have now also updated their FAQ about DNSSEC support in Google Public DNS and most importantly updated these two questions (my emphasis added):

Does Google Public DNS support the DNSSEC protocol?
Yes. Google Public DNS is a validating, security-aware resolver. Currently this is an opt-in feature: for queries coming from clients requesting validation (the AD and/or DO flag is set), Google Public DNS verifies that response records are correctly authenticated. Validation by default (i.e. for all queries) will be enabled soon.

Which client resolvers currently enable DNSSEC?
Unfortunately, most standard client stub resolvers do not enable full DNSSEC checking and cannot be easily reconfigured to do so. We have decided to make our initial launch only cover resolvers that explicitly ask for DNSSEC checking so that we become aware of any problems before exposing our users to possible large-scale DNS failures due to DNSSEC misconfigurations or outages. Once we are happy that we can safely enable DNSSEC for all users except those who explicitly opt out, we will do so.

It’s great to see Google responding to questions and adding these clarifications – and from the point of view of advocacy for DNSSEC deployment, it is great to have Google out there endorsing and promoting DNSSEC as a way to increase Internet security.

(And you can easily get started with DNSSEC if you haven’t already.)

For those of you who enjoy listening to audio, I recorded some audio commentary on our SoundCloud channel about why I view this news from Google as incredibly important: