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.

In addition to planning for DNSSEC and applying metrics, Government and TLD registry labs around the world are producing tools that enable the deployment of DNSSEC.

In the case of the ccTLDs, these same countries are leading in the adoption of DNSSEC.  The rest of us benefit from their sharing their work.  Following are some of the labs and what they provide.

CZ.NIC Labs (ICANN 44 is being hosted by CZ.NIC):

• DNSSEC Hardware Tester 
• DNSSEC Validator Extension for Web Browsers
• Knot Authoritative DNS Server

NLnet Labs:

• Unbound validating recursive and caching DNS resolver
• Dnssec-Trigger local Unbound server for end-system validation
• NSD authoritative only, high performance, simple and open source name server

Sandia National Laboratories:

• DNSViz DNS visualization tool

US DHS S&T Cyber Securtity R&D-funded:

• DNSSEC-Tools

Verisign Labs:

• DNSSEC Debugger DNSSEC analyzer

The US Federal Communications Commission‘s Communications Security, Reliability, and Interoperability Council (CSRIC) has come out with recommendations to ensure that end-users’ ability to use DNSSEC is not impaired by ISP infrastructure.  The report is not yet out, but there is a fact sheet and a press release  that states:

DNS Best Practices:

CSRIC recommended that ISPs implement best practices to better secure the Domain Name System. DNS works like a telephone book for the Internet, but lack of security for DNS has enabled spoofing, allowing Internet criminals to coax credit card numbers and personal data from users who do not realize they are on an illegitimate website. DNSSEC is a set of secure protocol extensions that prevent such fraudulent activity. This recommendation is a significant first step toward full DNSSEC implementation by ISPs and will allow users, with software applications like browsers, to validate that the destination they are trying to reach is authentic and not a spoofed website.

The slide presentation (2.7MB pptx) on DNSSEC from today’s meeting is available from the CSRIC III web site, as are FCC chairman Genachowski’s remarks.  A video of the meeting is also on the FCC’s web site.