Category: ICANN

Nov 14

Should The Root DNSSEC Key Be Rolled? ICANN’s SSAC Issues Some Guidance

ICANN SSAC 63Should the root key of DNSSEC be rolled over?  And if so, when and under what conditions?  We’ve mentioned this discussion before and even sent in our own comments to ICANN.  After reviewing all those comments and consulting with many people, the ICANN Security and Stability Advisory Committee (SSAC) has now issued their guidance in a document, “SAC063 – SSAC Advisory on DNSSEC Key Rollover in the Root Zone“.  The document is well worth a read and explains SSAC’s thinking on a variety of issues.  For a quick summary, SSAC issued five recommendations that I would paraphrase as:

1:  ICANN and partners should immediately undertake a worldwide communications effort to publicize the root zone KSK rollover motivation and process as widely as possible.

2: ICANN staff should coordinate a testing program to analyze the behavior of validating resolvers to identify problems that could be caused the the root KSK rollover.

3: ICANN staff and the community should identify clear and objective metrics for acceptable levels of “breakage” resulting from a key rollover.

4: ICANN staff should coordinate the development of rollback procedures to be executed in case things go wrong.

5: ICANN staff should coordinate the collection of information during this KSK rollover so that lessons can be learned for future rollovers.

This SSAC report is issued in time for next week’s ICANN 48 meeting in Buenos Aires where this topic will again be in the conversation within DNSSEC circles.  ICANN has contractual requirements to roll the key within five years of the signing of the root in July 2010 and so efforts are underway to make sure this can be done in a sensible manner.

Oct 24

Watch LIVE at 1:00pm US EDT today – ICANN’s DNSSEC Key Signing Ceremony XV

icann-at-15-logoIn about 15 minutes, at 1:00pm US EDT, you can watch live as members of the DNS/DNSSSEC community engage in a “Key Signing Ceremony” that will result in the generation of new keys used for managing DNSSEC at the root of the Domain Name System (DNS).  The live stream will be at:

http://dns.icann.org/ksk/stream/

The schedule, list of attendees and other information can be found at:

http://dns.icann.org/ksk/upcoming-ceremonies/cer15/

The ceremony begins at 1:00pm and is scheduled to end at 4:00pm US EDT. The script that is being followed during the ceremony is available at:

http://data.iana.org/ksk-ceremony/15/KC15_Scripts.pdf

These documents may also be helpful in understanding what happens:

Essentially what is going on is the creation and signing of new “zone-signing keys (ZSKs)” that are being signed by ICANN’s “key-signing key (KSK)” and then deployed by the ZSK operator.

As you will see if you watch, there is a very specific process that is used to ensure the integrity and security of the key signing process.  It is all documented and then archived so that there is full transparency about what goes on.

If you are interested in understanding how DNSSEC works at an operational level, you may find watching today quite informative. If you are unable to watch the stream live, it will be recorded and made available from the archive link for this 15th key signing ceremony.  (And as these key signing ceremonies happen quarterly, the next will be along in just a few months.)

Oct 24

4 NewgTLDs Launched Yesterday Marks Dawn of “DNSSEC From The Start” TLDs

dnssecYesterday was a big day for the Domain Name System (DNS). After a long process, ICANN formally delegated the first four of the “new generic top-level domains (newgTLDs)”, marking the beginning of the largest expansion of the domain name space ever. In addition to the existing “generic TLDs” like .com, .org, .net, etc., and the existing “country code TLDs (ccTLDs)” like .nl, .cz, .tv, etc., over the months and years ahead there are some 1,400 newgTLDs that are expected to be launched.

These first four newgTLDs are interestingly not English-language names like “.shop” or “.bank”, but instead what are called “Internationalized Domain Names (IDNs)” in non-Latin alphabets:

  • شبكة (xn--ngbc5azd) – Arabic for “web/network”
  • онлайн (xn--80asehdb) – Cyrillic for “online”
  • сайт (xn--80aswg) – Cyrillic for “site”
  • 游戏(xn--unup4y) – Chinese for “game(s)”

Yesterday’s “delegation” means that these TLDs now appear in the root zone of the DNS and the registries who operate these TLDs can now begin the process of selling domain names underneath these TLDs.  There is a formal process the registries have to go through to get started, but soon we should see these TLDs available as options for registration at the registrars who are supporting these TLDs.

Now, the exciting aspect of this news from a Deploy360 point of view is simply this:

All of these newgTLDs MUST be signed with and use DNSSEC!

From the very beginning of their operation these newgTLDs are already starting out with more security enabled than many of the existing country-code TLDs (ccTLDs).  If you look at ICANN’s “TLD DNSSEC Report” you can see that pretty much all of the existing major “generic TLDs” (ex. .com, .org, .net, .edu) are signed with DNSSEC.  Similarly over 100 of the existing ccTLDs are signed with DNSSEC.  These four newgTLDs can also be found in that report, with a nice green bar showing that they are all signed with DNSSEC.

The key point here is that these new registries must:

1. Keep the TLD signed with DNSSEC from an operational point of view.
2. Accept DNSSEC records (DS/DNSKEY) from registrars (or domain registrants depending upon the business model).

One important point:

Support of DNSSEC by a newgTLD does NOT mean that ALL domains registered under the newgTLD will be secured with DNSSEC!

But it means that all domain names registered under the newgTLD CAN be secured with DNSSEC – and that is a great step forward!

Furthermore, the new ICANN Registrar Accreditation Agreement (RAA) will require all “ICANN-accredited registrars” to support the passing of DNSSEC records from a domain name registrant up to the TLD registry. This means we should be seeing a great amount more of DNSSEC support from within the registrars.  Hopefully the DNS operators (which are sometimes part of registrars) will follow with making it easy for domain name holders to sign their domains.

All in all this newgTLD launch is great news for those of us looking at add more security to the Internet through the use of DNSSEC.  From here on out all the newgTLDs will be launched with DNSSEC – and hopefully this will also put some competitive pressure on the lagging ccTLDs (and a few lagging gTLDs) to join the rest of the TLDs that have already signed their domains.

And in the end, we’ll have a more secure Internet protecting users from attackers and also enabling new an innovative forms of security such as DANE’s protection of SSL/TLS certificates.

Congratulations to all the teams at these four registries (and their operators) and also at ICANN on this launch of the first new – and secure – gTLDs!

P.S. Want to understand DNSSEC and how (or why?) you can get started?  Check out our DNSSEC Basics page…

 

 

 

 

Sep 20

ICANN’s 2013 RAA Requires Domain Name Registrars To Support DNSSEC, IPv6

dnssecHow do we get more domain name registrars to support DNSSEC?  I don’t know how many times I’ve heard this:

“I want to sign my domain, but my registrar doesn’t support DNSSEC – what do I do?”

It’s been one of the proverbial questions that has indeed been a barrier to getting more domains signed.  As most of the largest top-level domains (TLDs) are now all signed, and an increasing number of smaller TLDs are getting signed, and as the tools for signing domains have become increasingly easy to use, there are fewer and fewer reasons not to add the increased level of security to your domain using DNSSEC.

Except… you need the registrar for your domain name to accept your DNSSEC information (either a DS or DNSKEY record) and pass that information up to the TLD registry (such as “.org”, “.com”, “.nl”, etc.).

That is the key role played by a registrar.  And that is the missing link for many people in having their signed domain fully integrated into the global chain-of-trust of DNSSEC.

Now, ICANN has maintained a list of registrars supporting DNSSEC and we’ve posted some tutorials about registrars and DNSSEC. A number of us have also been promoting DNSSEC to registrars at ICANN events through the DNSSEC workshops there (such as the one coming up at ICANN 48 in Buenos Aires) but the fact remains that many registrars are not yet supporting DNSSEC.

This may change soon, though, for one very simple reason.

ICANN has updated their “Registrar Accreditation Agreement (RAA)” that all “ICANN-accredited registrars” (and it’s a big list!) must sign to continue their affiliation with ICANN. The 2013 RAA, passed by the ICANN Board of Directors in June 2013, includes several provisions related to both DNSSEC and IPv6.  The final 2013 RAA, available as a PDF file, has this section 3.19:

3.19 Additional Technical Specifications to Implement IPV6, DNSSEC and IDNs. Registrar shall comply with the Additional Registrar Operations Specification attached hereto.

The actual “Additional Registrar Operation Specification” is found on page 67 of the agreement and states for DNSSEC:

1. DNSSEC

Registrar must allow its customers to use DNSSEC upon request by relaying orders to add, remove or change public key material (e.g., DNSKEY or DS resource records) on behalf of customers to the Registries that support DNSSEC. Such requests shall be accepted and processed in a secure manner and according to industry best practices. Registrars shall accept any public key algorithm and digest type that is supported by the TLD of interest and appears in the registries posted at: <http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec- alg-numbers.xml> and <http://www.iana.org/assignments/ds-rr-types/ds-rr- types.xml>. All such requests shall be transmitted to registries using the EPP extensions specified in RFC 5910 or its successors.

What this means is that registrars that wish to continue their ICANN accreditation must accept DNSSEC information from customers and relay that up to the TLD registries.

My understanding from people involved with the process is that the registrars are supposed to sign this agreement this year and if they do, the agreement is supposed to come into force by January 1, 2014.

While I’d of course love to think that this means that the big huge list of ICANN-accredited registrars will all be accepting DNSSEC records by January 1, I suspect that we’ll see some implementations by then… with others to follow at some point in 2014.  The good news is that this new RAA will cause some registrars to at least get DNSSEC higher on their priorities.

The other factor here is that all the “new generic TLDs” (a.k.a. “newgtlds”) that ICANN is planning to start adding over the next months and years all mandate that DNSSEC is included as part of their operations.  For registrars to fully support those newgtlds they will need to have DNSSEC support, anyway, so even without the 2013 RAA they will have another incentive to look at DNSSEC.

Now, the 2013 RAA only affects ICANN-accredited domain name registrars and there are certainly many other registrars that are not affiliated with ICANN.  They therefore won’t be required to support passing of DNSSEC records.  I’d like to think, though, that at some point there will be enough market momentum that those registrars will need to support DNSSEC … and hopefully lists like ICANN’s can just fade away as DNSSEC becomes just something offered by at least the majority of all registrars.

We’ll see… but this is certainly a positive step for removing this missing link for getting DNSSEC-signed domains into the global chain of trust.

I’ll note, also, that the 2013 RAA requires registrars to accept IPv6 records for domain names.  From that “Additional Registrar Operation Specification” on page 67 of the RAA:

2. IPv6

To the extent that Registrar offers registrants the ability to register nameserver addresses, Registrar must allow both IPv4 addresses and IPv6 addresses to be specified.

This, too, is excellent news as it will help organizations make their content and services more easily available over IPv6 in addition to IPv4.

Yet to be seen is how this all happens in reality and in what timeframe implementations actually occur… but it’s definitely a positive step in the deployment of both protocols and of enabling a more secure and innovative Internet.

P.S. If you’re a registrar looking to get started with DNSSEC and/or IPv6, please do browse our resources – and please do let us know if there are any ways we can help you get your deployment happening!  Are there specific questions you have?  Tutorials you’d like to see?  How can we help you?

NOTE: I should mention that I first learned of these RAA requirements through a talk that Michele Neylon gave at the ICANN 47 DNSSEC Workshop in Durban, South Africa in July. Michele now heads the Registrar Stakeholders Group within ICANN.

Aug 27

Call for Speakers For DNSSEC Workshop at ICANN 48 in Buenos Aires

icann48Will you be attending the ICANN 48 meeting in Buenos Aires, Argentina, in November 2013?  If so, are you interested in speaking about DNSSEC at the DNSSEC Workshop planned for Wednesday, November 20, 2013?

The DNSSEC Workshop program committee, of which I am a member, is seeking speakers for sessions on:

  • DNSSEC activities in Latin America
  • The operational realities of running DNSSEC
  • DNSSEC and enterprise activities
  • When unexpected events occur
  • Preparing for root key rollover
  • DANE and other DNSSEC applications
  • DNSSEC automation
  • Guidance for registrars in implementing DNSSEC
  • APIs between registrars and DNS hosting operators

In this session, we are particularly interested in hearing from people who have found (or developed) solutions for automating their implementation of DNSSEC.  We are also very interested in hearing from registrars given that the 2013 Registrar Accreditation Agreement (RAA) with ICANN will require ICANN-accredited registrars to at the very least support the acceptance of DNSSEC records from registrants.

The full “Call for Participation” is below that provides more details.  If you have an idea for a presentation, please send a brief 1 or 2 sentence description to dnssec-buenosaires@shinkuro.com which will reach the whole program committee. (Please send email rather than leave a comment here.)

We already have some solid speakers who have indicated their interest and so we’re very much looking forward to another excellent session.  I’ll also note that the ICANN meetings are free to attend – you have to register but there is no cost. You just have to pay for your travel and expenses to get to Buenos Aires.   The DNSSEC Workshop will also be streamed live over the Internet for those wishing to watch/listen and will be archived for later viewing.

These workshops are really excellent technical sessions. I would encourage you to attend if at all possible and I would definitely encourage you to submit a proposal to speak.  We’re always interested in hearing new perspectives.

Call for Participation — ICANN DNSSEC Workshop 20 November 2013

The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), is planning a DNSSEC Workshop at the ICANN meeting in Buenos Aires, Argentina on 20 November 2013. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN meeting in Durban, South Africa on 17 July 2013. The presentations and transcripts are available at: http://durban47.icann.org/node/39749.

We are seeking presentations on the following topics:

1. DNSSEC Activities in Latin America:
For this panel we are seeking participation from those who have been involved in DNSSEC deployment in Latin America, but also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions: What can DNSSEC do for you? What doesn’t it do? What are the internal tradeoffs to implement DNSSEC or not?

2. The Operational Realities of Running DNSSEC
Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What’s best practice around key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? What operational statistics have we gathered about DNSSEC? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones?

3. DNSSEC and Enterprise Activities
DNSSEC has always been seen as a huge benefit to organizations looking to protect their identity and security on the Web. Large enterprises are an obvious target for DNS hackers and DNSSEC provides an ideal solution to this challenge. This session aims to look at the benefits and challenges of deploying DNSSEC for major enterprises. Topics for discussion:
* What is the current status of DNSSEC deployment among enterprises?
* What plans do the major enterprises have for their DNSSEC roadmaps?
* What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so?
* What are the challenges to deployment for these organizations? Do they foresee raising awareness of DNSSEC with their customers?

4. When Unexpected DNSSEC Events Occur
What have we learned from some of the operational outages that we have seen over the past 18 months? Are there lessons that we can pass on to those just about to implement DNSSEC? How do you manage dissemination of information about the outage? What have you learned about communications planning? Do you have a route to ISPs and registrars? How do you liaise with your CERT community?

5. Preparing for Root Key Rollover
For this topic we are seeking input on issues relating to root key rollover. In particular, we are seeking comments from vendors, ISPs, and the community that will be affected by distribution of new root keys.

6. DANE and Other DNSSEC Applications
The DNS-based Authentication of Named Entitites (DANE) protocol is an exciting development where DNSSEC can be used to provide a strong additional trust layer for traditional SSL/TLS certificates. There is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as:
* What are some of the new and innovative uses of DANE in new areas or industries?
* What tools and services are now available that can support DANE usage?
* How soon could DANE become a deployable reality?
* How can the industry used DANE as a mechanism for creating a more secure Internet?

7. DNSSEC Automation:
For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. Topics for which we would like to see presentations include:
* What tools, systems and services are available to help automate DNSSEC key management?
* Can you provide an analysis of current tools/services and identify gaps?
* Where in the various pieces that make up DNSSEC signing and validation are the best opportunities for automation?
* What are the costs and benefits of different approaches to automation?

8. Guidance for Registrars in Supporting DNSSEC:
The 2013 Registrar Accreditation Agreement (RAA) for Registrars and Resellers requires the support of DNSSEC beginning on January 1, 2014. We are seeking presentations discussing:
* What are the specific technical requirements of the RAA and how can registrars meet those requirements?
* What tools and systems are available for registrars that include DNSSEC support?
* What information do registrars need to provide to resellers and ultimately customers?

We are particularly interested in hearing from registrars who have signed the 2013 RAA and have either already implemented DNSSEC support or have a plan for doing so.

9. APIs Between the Registrars and DNS Hosting Operators:
One specific area that has been identified as needing focus is the communication between registrars and DNS hosting operators, specifically when these functions are provided by different entities. Right now the communication, such as the transfer of a DS record, occurs primarily by way of the domain name holder copying and pasting information from one web interface to another. How can this be automated? We would welcome presentations by either registrars or DNS hosting operators who have implemented APIs for the communication of DNSSEC information – or from people with ideas around how such APIs could be constructed.

In addition, we welcome suggestions for additional topics.

If you are interested in participating, please send a brief (1-2 sentence)
description of your proposed presentation to dnssec-buenosaires@shinkuro.com by **Friday, 06 September 2013**

We hope that you can join us.

Thank you,

Julie Hedlund

On behalf of the DNSSEC Workshop Program Committee:
Steve Crocker, Shinkuro
Mark Elkins, DNS/ZACR
Cath Goulding, Nominet UK
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, CNNIC
Russ Mundy, Sparta/Parsons
Ondřej Surý, CZ.NIC
Lance Wolak, .ORG, The Public Interest Registry
Yoshiro Yoneya, JPRS
Dan York, Internet Society

Jul 15

Watch “DNSSEC For Everyone – A Beginner’s Guide” Live Today From ICANN47

ICANN 47 meeting in Durban, South AfricaWant to understand what DNSSEC is all about?  Would you like to understand how DNSSEC helps make DNS more secure?  And why DNSSEC is important?

Today (July 15, 2013) we’ll be streaming the “DNSSEC For Everyone – A Beginner’s Guide” session live out of ICANN 47 in Durban, South Africa. This is a fun session that takes a humorous view on DNSSEC… and includes a number of people (myself included) acting out a skit showing how DNS and DNSSEC work! :-)    Feedback from past sessions is that this all has helped people understand better how this all works – and so we encourage you to watch if you can.

You can watch the video and slides for the session at:

http://icann.adobeconnect.com/dur47-hall1b

An audio-only streaming option is also available from the session page on the ICANN 47 web site.

The session begins at 5:00pm in Durban, South Africa, which is also 5:00pm in central Europe and 11:00am in US Eastern time.

If you can’t watch the event live, I will be recording the video locally and will post a copy to the Deploy360 YouTube channel as soon as I can.

 

Apr 05

Heading to Beijing For ICANN 46

Icann46-beijingTomorrow morning I'm starting a trip to Beijing for the 46th meeting of the Internet Corporation for Assigned Names and Numbers, a.k.a. "ICANN". ICANN is the organization at the heart of the Domain Name System (DNS) and I'll be there specifically to take part in several DNSSEC workshops related to how to better secure DNS.  I'll also attend an IPv6 workshop and some of the many other meetings scheduled for the week-long event. 

These are very good technical meetings in the midst of all the other business-related meetings at an ICANN event. You can participate remotely if you are interested to do so (details are in those links).

Some colleagues of mine prepared the "Internet Society's Rough Guide to ICANN 46's Hot Topics" which gives a sense of what those of us from the Internet Society will be doing there at ICANN.

ICANN meetings are always crazy-busy and I'm looking forward to meeting up with people I know from a variety of contexts.  We've got an outstanding program lined up for the DNSSEC workshop, so that will be a great event.

I've never been to China, so this should be an interesting experience.  I probably won't have much time to look around, but I'm hoping to squeeze in a few hours during the week to look around (probably during some morning runs, if the weather and pollution levels will allow me to do so).

If you are going to be at ICANN 46, please feel free to contact me.  I'll also of course be posting some live updates from there as well.

Here's a quick audio commentary on my trip:

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

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:

Jan 11

Still Time To Submit A DNSSEC Speaking Proposal for ICANN 46 in Beijing

As we mentioned previously, there will be another DNSSEC Deployment Workshop on April 10, 2013, as part of ICANN 46 in Beijing, China.

The program committee is still open to receiving proposals if you would like to be considered for the agenda.

These DNSSEC workshops at ICANN meetings are outstanding places to meet with people involved in DNSSEC deployment and to present ideas, case studies, new tools and more.

See our earlier article for a full list of the kinds of topics for which the program committee is seeking proposals.  If you have a DNSSEC-related idea for a talk that doesn’t fit into those areas, don’t be afraid to submit it as the program committee provides that list for guidance.

The workshop agenda is filling up quickly… but there is still room for a few more speaking slots if you get a proposal in soon.  You need to send your proposal to dnssec-beijing@shinkuro.com by January 15th to be considered.

And if you don’t want to present but are interested in attending, if you can get yourself to Beijing attendance at the DNSSEC Deployment Workshop is free.  The event will also be live-streamed out so you will be able to watch it remotely.