Archive for April, 2012

As seen on the DNSSEC Deployment Working Group mailing list:

The DNSSEC Deployment Initiative, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), is planning a DNSSEC Workshop at the ICANN meeting in Prague, Czech Republic on 27 June 2012. 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 Costa Rica meeting on 14 March 2012. The presentations and transcripts of the presentations are available at http://costarica43.icann.org/node/29659.

We are seeking presentations on the following topics:

1. DNSSEC activities in Europe
This is a key panel and we are seeking participation from those who have been involved in DNSSEC deployment in Europe as well as those who have a keen interest in the challenges and benefits of deployment. Key questions are to consider include: what would help to promote DNSSEC deployment? What are the challenges you have faced when you deployed DNSSEC? Can DNSSEC make the information users receive more reliable?

2. ISPs and Validation
ISPs are beginning to take the first step to full DNSSEC implementation that will allow web users, with software applications like browsers, to validate that the destination they are trying to reach is authentic and not a spoofed website. We are seeking ISPs to participate in a panel discussion or provide presentations on their DNSSEC deployment plans, challenges, and benefits for users.

3. The realities of running DNSSEC
Now that DNSSEC has become an operational norm for many registries and registrars, 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? Has DNSSEC made DNS more ‘brittle’ or is it just a run-of-the-mill operational practice?

4. 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 challenges to deployment for these organizations? Do they foresee raising awareness of DNSSEC with their customers?

5. 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?

6. DNSSEC in the wild
What operational statistics have we gathered about DNSSEC? Is it changing DNS patterns? How are our nameservers handling DNSSEC traffic? Is the volume as expected? Have we seen anything unusual? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones?

7. DANE and other DNSSEC applications
Using DNSSEC as a means of authentication for http transactions is an exciting development of DNSSEC. What is the progress of the DNS-Based Authentication of Named Entities (DANE) initiative? (See http://datatracker.ietf.org/wg/dane/.) How soon could DANE become a deployable reality and what will be the impact of such a deployment, e.g. impact on traditional certification authorities (CAs)?

8. The Great DNSSEC Panel Quiz
Ever fancied pitting your wits against your colleagues? Demonstrate your knowledge and expertise in DNSSEC in our Great DNSSEC Panel Quiz. We are looking for four or five people to join us in a light-hearted quiz.

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. Here are the relevant deadlines:

10 May 2012 — Deadline to submit brief description of presentation from interested participants
04 June 2012 — Deadline to submit presentation slides

Please respond to [email protected] no later than 10 May 2012 as indicated above. We hope that you can join us.

Thank you,

Julie Hedlund

On behalf of the DNSSEC Workshop Program Committee:
Luis Diego Espinoza, NIC .cr
Steve Crocker, Shinkuro
Simon McCalla, Director of IT, Nominet UK
Russ Mundy, Cobham
Ondřej Surý, NIC.cz
Lance Wolak, Vice President, Marketing & Sales, .ORG, The Public Interest Registry

We agree with our friends at the ISOC Deploy360 Programme when they say that the e-learning course on DNSSEC from SIDN, the .NL registry, is excellent.

It’s not news to anyone involved in the deployment of DNSSEC, but some of the Internet protocols we use today were designed years ago, when the Internet itself was as much a research project as the research projects it helped facilitate at university and government or government-funded institutions. Many of the insecure protocols of those days have been replaced or augmented by more secure versions. Telnet and rlogin/rsh have given way to ssh. There’s now HTTPS in addition to HTTP and many other protocols now support end-to-end security using SSL/TLS.

Even with all of these changes to transport and application-level security, infrastructure security has lagged behind. DNSSEC is one piece of the puzzle to secure the infrastructure. It ensures that the mappings that DNS provides — that are required by just about every other protocol and application on the Internet — are the ones intended by domain owners.

But even having validating mappings that result in, among other things, IP addresses is insufficient. Another piece of infrastructure — this one far more hidden from end users than DNS — is routing. Specifically, it’s the Border Gateway Protocol (BGP) that is used to identify how packets should flow between corporate and ISP networks across the Internet to get to their intended recipients.

BGP has been under study to improve its security for as long as DNS. Many of the same organizations that have funded or performed work on improving DNS security have done the same for BGP.  The US Department of Homeland Security, which funds the DNSSEC Deployment Initiative, has also funded work on securing BGP.

As reported in The Register, those securing BGP are benefiting from the deployment of DNSSEC with the development of BGP Route Origin Verification (ROVER).  According to the article,

Several early adopter telcos and ISPs are in the process of publishing route origins in their reverse DNS and signing with DNSSEC. In addition, Secure64 has established a Rover Testbed available at “rover.secure64.com” (registration required).

This adds BGP to the growing list of protocols and services that can benefit from leveraging DNSSEC deployment.

As reported previously, the .UA hostmaster provided a schedule for DNSSEC deployment at ICANN43.

In a comment this past Friday on that article and in a press release on their own site, the .UA hostmaster announced that they’re signed, their DS is in the root, and several companies are already using DNSSEC to protect their domains.   They end their press release with the following:

UA is our home, let’s make it safe!

The recommendations that were previously announced have been published on the FCC’s CSRIC III website.

In brief, the report (318KB PDF)  lays out four levels of possible deployment with respect to validation and recommends that all ISPs implement at least the next to highest level, DNSSEC-aware resolvers, if not the highest level, actual validation at the ISP level.  This lays the foundation for ISPs to go to the next step and, perhaps more importantly, enables end systems to do their own validation without having to bypass the ISP’s DNS service completely.