Category: DNSSEC

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.

Sep 18

6 TLDs for Honduras, East Timor And Multiple Islands Are Now Signed With DNSSEC

dnssecWe were delighted to learn from Garth Miller, the administrative contact for the .CX top-level domain (TLD), that 6 more TLDs have been signed with DNSSEC and now have DS records in the root zone.  This means that people and businesses with domains registered in these TLDs can now receive the higher level of security possible with DNSSEC:

If you have a domain registered in those TLDs, your registrar should now be able to pass the required DS record up to the TLD registry. (See our page about registrars and DNSSEC for more information about this process with some registrars.)  If your registrar does not yet support the uploading of DNSSEC information, now would be a great time to start asking them! :-)

Congratulations to Garth Miller and the teams associated with the various TLDs for making these signed TLDs happen.  Per ICANN’s TLD Report, there are now 111 out of 318 TLDs signed which is excellent progress.  (These new signed TLDs are also visible on the DNSSEC deployment maps we recently published.)

P.S. Bonus points if you know where all the islands are!  I had to pull out a map for a couple of them.

Sep 17

4 More Days To Submit Speaking Ideas For DNSSEC Workshop At ICANN 48

icann48Will you be attending the ICANN 48 meeting in Buenos Aires, Argentina, in November 2013? If so, you have four more days to submit a speaking proposal for the DNSSEC Workshop planned for Wednesday, November 20, 2013.  I wrote about the call for speakers earlier but since that time the program committee decided to extend the proposal deadline to this Friday, September 20, 2013.  (We received feedback that people were still returning from summer holidays and our original deadline was too close to that.

We have a great line up of speakers so far, including some excellent folks to give us updates on DNSSEC in Latin America, but we still have room for a few more proposals.  The Call For Participation is included again below, along with the email address to which to send your ideas.

Thanks – and we’ll see you in Buenos Aires!

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

Sep 12

FreeBSD 10 To Include OpenSSH With DNSSEC Support (for SSHFP records)

freebsd-logoVery cool news out of the FreeBSD team yesterday… the upcoming FreeBSD 10 will include support in OpenSSH for DNSSEC. The key point is this:

This means that OpenSSH will silently trust DNSSEC-signed SSHFP records.

What this means is this: when you go to ssh into an unknown system (i.e. one that is not in your “known_hosts” file), OpenSSH will do a query for a SSHFP record and use DNSSEC validation to ensure that the SSHFP record is indeed the one that the domain operator wants you to use.

This process of using a SSHFP record was defined in RFC 4255 back in 2006.  If you are familiar with how ssh (a.k.a. “secure shell“) works, when you connect to an unknown system for the first time you are presented with the “fingerprint” of the public key of the server to which you are connecting.  In theory you could verify this fingerprint through some out-of-band mechanism (perhaps seeing it on a web page or having received it separately in an email).  In practice, the vast majority of people just hit enter/return or type “yes” or something like that.

In the RFC 4255 mechanism, the operator of the server would publish a SSHFP record in DNS that would have the fingerprint of the SSH public key.  This is the same key fingerprint that would normally be presented to a user.  By using DNSSEC to sign the DNS zone that includes the SSHFP record, the server operator can provide a method for a DNSSEC-validating SSH client to verify that the SSH fingerprint is in fact the one that should be used to connect to the server.

This creates a higher level of trust and security in SSH connections.

It’s great to see this added to FreeBSD 10, which, according to the FreeBSD Release Engineering page, should be available sometime in November 2013.

For those curious, the SSHFP record is similar to what was defined six years later in RFC 6698 for the DANE protocol, which is really no surprise as they share a common author, Jakob Schlyter.  DANE’s TLSA record is a bit more complex and, for instance, allows for the inclusion of a complete SSL/TLS certificate rather than just a fingerprint.  In both cases, though, the idea is the same – use a DNS record to provide a means to verify a public key, and use DNSSEC to provide integrity protection so you know that you can trust the DNS record.

Great to see this being rolled out in an enabled state. Kudos to the FreeBSD team for doing this!

Sep 09

New DNSSEC Deployment Maps Available

2013-09-09-2013-09-09Curious to see where DNSSEC is being deployed around the world? I’m pleased to note that we’ve updated the DNSSEC deployment maps we have available at:

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

These maps are produced by the team at Shinkuro, Inc.  The data on the map should line up with other sources of DNSSEC statistics, such as ICANN’s TLD DNSSEC Report, although the Shinkuro maps do reflect additional information about planned deployments gathered from industry sources and ccTLD operators.

Note that these maps represent signed top-level domains (TLDs), which you need before you can sign your domain using a registrar and DNS hosting provider.  Additional sites with statistics about the number of signed domains under various TLDs can be found on our DNSSEC statistics page.

We’re pleased to see the continued growth of DNSSEC around the world.  Have you signed your domain and/or set up DNSSEC validation yet?  If not, how can we help you get started?

Sep 03

Video Interview: Matt Larson on the Future of DNS and DNSSEC

What needs to be done to get DNSSEC further deployed? What is the future of DNSSEC and DNS in general?  At IETF 87 in Berlin we had a chance to sit down with Matt Larson, formerly of Verisign and now Chief Architect at Dyn. Matt shared his thoughts with us:

We appreciated Matt’s time and wish him all the best in his new role at Dyn.

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

Aug 21

New USENIX Paper: Measuring the Practical Impact of DNSSEC Deployment

usenix-dnnsec-082013At the recent 22nd USENIX Security Symposium in Washington, DC, a paper was presented that is now available for download: Measuring the Practical Impact of DNSSEC Deployment, written by several researchers from the University of California along with security researcher Eric Rescorla.  Their work was to explore the cost vs benefit of deploying DNSSEC.  As they note in their abstract:

We have performed a large-scale measurement of the effects of DNSSEC on client name resolution using an ad network to collect results from over 500,000 geographically-distributed clients. Our findings corroborate those of previous researchers in showing that a relatively small fraction of users are protected by DNSSEC-validating resolvers. And we show, for the first time, that enabling DNSSEC measurably increases end-to-end resolution failures. For every 10 clients that are protected from DNS tampering when a domain deploys DNSSEC, approximately one ordinary client (primarily in Asia) becomes unable to access the domain.

They go on to provide a background of DNS and DNSSEC, explain their methodology and systems and then outline their results.  To perform their tests, they used web-based ads in what seems like a method similar to what Geoff Huston and George Michaelson have been doing at APNIC. (I have not specifically compared the two methodologies, but both are using web-based ads.)

The paper reaches several interesting conclusions.  First, they found that DNSSEC validation was performed by about 2.6% of users out there. Second, they found that about 1% of clients failed to retrieve a validly DNSSEC-signed resource – and that this was primarily from clients in the Asia Pacific region and was related to DNS resolution falling back to TCP to accommodate larger packet sizes.

The full document is definitely worth a read as there is a wealth of information and also links out to other studies and surveys.  They also include some good cautions in there for people undertaking similar advertising-based studies.

My one question about the study was when the measurements were taken and whether it was before or after Google enabled DNSSEC validation on their Public DNS servers back in May.  I couldn’t find the timeframe in the study, but that could be important, as Geoff Huston’s latest measurements showed a jump in DNSSEC validation from 3.3% to 8.1% after Google made their change.

Regardless, it’s great to see these kind of studies out there and I look forward to reading any further research the team may perform in this area.

Aug 16

Friday Humor: “Keep Calm and Enable DNSSEC” (and IPv6, too!)

keepcalmandenablednssecGiven that it’s a Friday afternoon and the end of our work week, I felt there was no better way to end the week than to highlight the image tweeted out by Marco Davids of SIDN this morning.  Yes, indeed, we in the DNSSEC community now have our own version of the (overused?) “Keep Calm” Internet meme…

(And you can get the full-size version via Marco’s Twitter account.)

Now in seeing Marco’s tweet, I learned of www.keepcalm-o-matic.co.uk which I kind of knew had to exist out there somewhere, but had just never taken the time to find.

So… in order that IPv6 advocates don’t feel left out… I’ve created a “Keep Calm and Enable IPv6″ image as well!  (And yes, I tried fitting both DNSSEC and IPv6 in, but didn’t like the result.)

Anyway, thanks, Marco, for giving us something to smile about today!   Have a great Friday afternoon… and for those of you have a weekend ahead of you, I hope you have a great one!

Aug 15

Digging Into The August 14 .GOV Outage Related To DNSSEC

dnssecOver the past day there have been a number of news reports talking about the brief outage that occurred yesterday, August 14, 2013, when sites ending in .GOV were unreachable if you were performing DNSSEC validation on those domain names.  Many of those news reports are pointing at Johannes Ullrich’s post on the SANS ISC Diary site where he noted this issue.

The issue was fixed relatively quickly and the speculation on the dns-operations mailing list was later verified by a message sent from Verisign’s Duane Wessels to a number of mailing lists:

On the morning of August 14, a relatively small number of networks may have experienced an operational disruption related to the signing of the .gov zone.  In preparation for a previously announced algorithm rollover, a software defect resulted in publishing the .gov zone signed only with DNSSEC algorithm 8 keys rather than with both algorithm 7 and 8.  As a result .gov name resolution may have failed for validating recursive name servers.  Upon discovery of the issue, Verisign took prompt action to restore the valid zone.

We can argue, perhaps, with the statement that “a relatively small number of networks” experienced this issue as those “networks” include all of Comcast’s 18 million users plus the millions of users out there who are using Google’s Public DNS services, as well as all the many other ISPs around the world who have enabled DNSSEC validation for their customers.

However, it may be true that a relatively small number of users of those networks happened to be visiting .GOV sites during the time period in question.

Regardless, the important part is to note here that this was an operational issue with the administration of DNSSEC for the .GOV domain rather than any particular issues related to the technology behind DNSSEC.  As Duane Wessels had noted in an earlier message back on July 30, 2013, the .GOV zone is preparing to make a change to make its deployment of DNSSEC more secure:

An algorithm roll for the .gov zone will occur at the end of August, 2013.  This notice is provided as a courtesy to the DNSSEC community.  No action should be required on your part.

The .gov zone is currently signed with algorithm 7 (RSASHA1-NSEC3-SHA1) and will be changed to use algorithm 8 (RSA/SHA-256), bringing it in line with other top-level domains such as as .com, .net, and the root zone.  The zone will be signed with both algorithms for a period of approximately 10 days.

Further scheduling details will be provided one week before the algorithm roll begins.

It seems that in Verisign’s preparations for that change an error was made and an incorrectly configured zone file was published instead.  While obviously it would be preferable if the mistake had not been made, kudos to the team at Verisign for correcting the issue quickly and for also reporting back to the larger DNS / DNSSEC operations community on what the problem was that occurred.

Duane Wessels noted in his message today that Verisign is still planning to proceed with the algorithm rollover at the end of August and so we can expect to see more communication from them as they proceed with the change.