Category: DNSSEC

Sep 07

Speaking in Montenegro about DNSSEC on September 12

ccTLD conference in MontenegroOn Wednesday of this week I’ll be speaking about DNSSEC at the 5th international conference for ccTLD registries and registrars of CIS, Central and Eastern Europe in Budva, Montenegro.  I’m very much looking forward to this event as it is entirely focused around the concerns of registries and registrars – and they are one of the key groups who can accelerate the deployment of DNSSEC.  In fact, you can see DNSSEC come up a few times on the agenda  – and I’m looking forward to hearing the case study of the .UA deployment of DNSSEC.

My session on Wednesday is titled “Key Steps in Accelerating DNSSEC Deployment” and for the registries and registrars the steps really can be ultimately reduced down to these:

  • Registries need to make it as simple as possible for registrars to upload DS (Delegation Signor) records into the registries’ zones.
  • Registrars need to make it as simple as possible for DNS hosting providers to upload DS records into the registrars databases.

Those two steps right there would greatly accelerate the deployment of DNSSEC in those ccTLDs.

That’s not all I’ll talk about, of course.  I’m also going to be discussing the growth of the .NL signed domains as that example may be something some of the ccTLDs can replicate. I’ll be talking about how the ongoing work with DANE securing SSL/TLS certificates via DNSSEC should spur enterprise interest in deployment.  I’ll be providing some examples of a good user experience … and much more.  I’ll be making the slides available later and potentially an audio or video recording if I am able to do so.

The main point of my attendance, too, is to interact with registries and registrars and find out what we can do to make it easier for them to deploy DNSSEC.  That feedback will certainly help our DNSSEC content roadmap and help us prioritize what materials we are creating first.

If you attending the event I look forward to meeting up with you,  and I look forward to learning from those there about DNSSEC – and all the other issues – in the Central and Eastern European region.

Sep 07

.NL Becomes First TLD To Pass 1 Million DNSSEC-Signed Domain Names!

History was made today in the ongoing effort to deploy DNSSEC globally and bring about a more secure Internet -

.NL became the first top-level-domain (TLD) to pass 1 million DNSSEC-signed domain names!

Celebrated in tweets from SIDN, the operator of the .NL registry, and from Bert Hubert, principal author of PowerDNS, as well as in an announcement from SIDN, the milestone can be clearly seen in the unofficial .NL statistics site operated by PowerDNS:

It is also visible on SIDN’s home page where they also show the total number of .NL domains:

Note, too, the significance of those numbers –

over 20% of all .NL domains are now signed!

Outstanding to see… and we look forward to seeing how much higher it grows.

We’ve previously covered (also here) the rise of the .NL domain and we’re delighted to see them hit this milestone! Kudos to the folks at SIDN, PowerDNS, SURFnet, NLNet Labs and everyone else involved!

Now we just need to get all the other TLDs moving on the same path!  (Including .COM, which has just over 106,000 domains signed… as Bert commented to me on Twitter, .NL had more signed delegations added yesterday than .COM has in total!)

Want to help?  Here are some steps for how you can get started signing your domain!

 

Sep 04

Summer is over… time to get back to IPv6 and DNSSEC – how can we help?

Wonderful day to be out on the water!Here in the northern hemisphere where I live, summer is now basically over. People are (mostly) back from vacations. Kids are returning to school. The rhythms and routines are returning… the weather is getting cooler… the days are getting shorter… people are turning their focus a bit more back to work.

Which means it is a perfect time to get back to deploying IPv6 and DNSSEC!

Let’s make it happen now!  You’ve still got a few months left to get a project underway in 2012!  Or you can be planning for a deployment that will happen in 2013…

Take a look at our IPv6 and DNSSEC resources to see what is out there to help you get started.  If you are a website owner, take a look at our “IPv6 for content providers” page that we’ve created… we’re planning to build out the other pages in a similar style for other audiences. If you have a domain name registered, look at our page about how to sign your domain with DNSSEC using various domain name registrars.

If you don’t see a resource that helps you get started, check out our content roadmap to see if what you are looking for is in our plans… and please let us know if you don’t see what you need.

Now is the time to deploy IPv6 and DNSSEC – how can we help?

Aug 28

Over 760,000 .NL Domains Now Signed With DNSSEC

The Netherlands now leads the world in terms of DNSSEC-signed domains with over 760,000 .NL domains signed with DNSSEC. A tweet from SIDN, the operator of the .NL domain, clued us in to this milestone this morning. You may recall us writing about the .NL growth back in early July when the number of domains was cruising up towards 100,000… now about 7 weeks later the the growth is approaching 8X that number:

DNSSEC growth in dot NL domain

As shown in the graph from the PowerDNSSEC team, the .NL growth has surpassed other domains that have been promoting DNSSEC such as .SE, .BR and .CZ.  It has also, sadly, eclipsed the number of DNSSEC-signed .COM domains.

Kudos to the SIDN team for their efforts to encourage DNSSEC adoption within their registrars and hosting providers. We look forward to seeing them pass the million domain mark soon!

P.S. If you want more information about how to sign your own domain using DNSSEC, check out our instructions for several registrars.

Aug 13

Speaking About DNSSEC in Bogotá, Colombia, on Tuesday, August 14…

Logo for DNSSEC event in ColombiaTomorrow, Tuesday, August 14, 2012, I (Dan York) will be in Bogotá, Colombia, speaking about DNSSEC and offering ideas for network operators and registrars about how they can accelerate the deployment of DNSSEC based on some of what we’ve seen. This is part of a full day titled “Taller DNSSEC”  (“DNSSEC Workshop”) sponsored by .CO INTERNET and the Cámara Colombiana de Informática y Telecomunicaciones (C.C.I.T.) along with NIC Chile, LACNIC, ICANN, COLNODO and we here at the Internet Society.

More information and the full agenda for the day can be found on LACNIC’s page for the event.

As .CO was signed with DNSSEC back in March 2011, the foundation is certainly there for moving adoption forward within that ccTLD… and hopefully within other usage throughout the region.

Having never been to Colombia before, I’m looking forward to visiting and participating in this event. It will be interesting on a personal level as outside of my presentation and the one from ICANN everything else will be in Spanish… and my Spanish capability is not a whole lot more than “uno, dos, tres…”.   :-)      So I’m looking forward to learning a bit while I’m there.  If you are going to be at tomorrow’s event, please do stop by and say hello!

Aug 08

Looking for DNSSEC Training? Here Is Some Courseware…

DNSSECLooking for some material to teach people about DNSSEC? Would you like to run your own training session? Or incorporate some DNSSEC material into other courses you have?

If so, Olaf Kolkman and the great folks at NLNet Labs have released some courseware coming out of some DNSSEC training they did earlier this year at:

http://www.dns-school.org/Slides/index.html

Available in PDF, Keynote and PowerPoint – and available under a Creative Commons distribution license – the material covers overall DNSSEC issues and also goes into deep dives in installing/configuring Unbound and OpenDNSSEC.

Great materials to have out there openly available – and many thanks to Olaf and the crew at NLNet Labs for making this material available to the public.

Jul 30

How To Hack OpenSSH To Add DNSSEC Validation

OpenSSH logoWould you like to have SSH just automagically use DNSSEC to verify the authenticity of the SSH keys you are using to connect to another system?

Over on his blog, Jan-Piet Mens lays out the steps to add exactly this, demonstrating how to add ldns support into OpenSSH. Essentially all you need to do is recompile OpenSSH with the “--with-ldns” option.

To back up a moment and explain a bit more, RFC 4255 defines how to store SSH keys in DNS as SSHFP resource records. With DNSSEC signing all the resource records for a domain, you can now verify the authenticity of those SSH keys with the use of a DNSSEC-validating resolver. This provides a more secure alternative than requiring you to in theory confirm an RSA fingerprint when you are connecting to a server.

So for this all to work, you need to:

  1. Have SSH keys for the target machine stored in DNS as SSHFP resource records.
  2. Have the domain for the target machine signed with DNSSEC.
  3. Compile and install OpenSSH with the ldns option.
  4. Have access to a DNSSEC-validating DNS resolver. (Which could be accomplished by installing DNSSEC-Trigger, for instance, or using a DNSSEC-validating DNS resolver from your ISP if they offer one.)

Once you have done those steps, the beauty of the process is that you are no longer prompted with the message “The authenticity of host ‘____’ can’t be established” with the RSA key and the question about do you really want to connect.

Right now you have to recompile OpenSSH to add the ldns support, but hopefully as DNSSEC becomes increasingly deployed more widely this will just be one of the standard compilation options so that you’ll be able to just go to the command-line and type “ssh” and let it automatically do the DNSSEC validation.

Thanks, Jan-Piet, for writing up these steps!

Jul 27

Warning! DNSSEC-Trigger Installation Issue After Mountain Lion Upgrade

Dnssec TriggerIf you are a Mac OS X user looking to upgrade to the brand new Mountain Lion release – and you also have installed DNSSEC-Trigger to have a local DNSSEC-validating DNS resolver, it seems there may be an issue during the upgrade process that you need to deal with.

[UPDATE: This issue apparently only affects new installations of DNSSEC-Trigger.  If you already have DNSSEC-Trigger installed, the upgrade to Mountain Lion works.  It is when you go to install DNSSEC-Trigger on Mountain Lion that the issue appears.]

Over on the dnssec-trigger mailing list, Olaf Kolkman of NLnet Labs writes about the problem with Mountain Lion and provides instructions for how to address the problem.  If you notice unbound not starting after  the Mountain Lion upgrade, you will need to follow Olaf’s instructions:

If the command
$ id unbound
returns “no such user”, you know that you have been bitten by this problem.

To fix:
Allocate yourself a free id. You can see the allocated ids using the following:
dscl localhost -list /Local/Default/Groups PrimaryGroupID
dscl localhost -list /Local/Default/Users UniqueID

Then assign the ids to the unbound user.
sudo dscl localhost -create /Local/Default/Users/unbound PrimaryGroupID <number>
sudo dscl localhost -create /Local/Default/Users/unbound UniqueID <number>

In his email message, Olaf also provides a “use-at-your-own-risk” shell script for performing this fix.  He also indicates that the DNSSEC-Trigger team will be including a fix in a new release sometime in the next few weeks.

Jul 17

Two Years Ago This Week, The Root Zone of DNS Was Signed With DNSSEC

Via a tweet from the ICANN DNS Ops team this morning, we were reminded that it was two years ago this week when the root zone of DNS was signed with DNSSEC and we could start validating the global “chain of trust” from the very beginning of the DNS tree.

As noted on www.root-dnssec.org, the timeline for the final signing of the root occurred over a one-month period:

  • June 16, 2010 – First key signing ceremony at the ICANN data center in Culpeper, Virginia.
  • July 12, 2010 – Second key signing ceremony at the ICANN data center in El Segundo, California.
  • July 15, 2010 – The signed root zone was publicly available.

Once the signed root zone was published on July 15, 2010, it made possible all the DNSSEC validation and usage that we are able to do today using the full global chain of trust.

For those interested in what was happening behind the scenes and the intense amount of security put in place around the key ceremonies, the annotated scripts for Ceremony 1 (June 16) and Ceremony 2 (July 12) make for an interesting view into the process.  The “script exceptions” at the end of each document, in particular, show the human side of the process and that even with the best of preparations sometimes things go wrong.  All in all a rather complete and interesting process.

Congratulations to all involved in the key signing two years ago! (Many of whose names appear regularly in our DNSSEC resources or DNSSEC-related blog posts.)

 

 

Jul 16

How To Write A DNSSEC Practice Statement (DPS)

Are you planning to start using DNSSEC with your domain – and are you planning to start signing your domain yourself? In other words, are you going to be doing all the signing on your own server and/or in your own facilities?  (Versus using a service at a DNS hosting provider that does all the DNSSEC-signing for you.)

If you are, then a good place to start your planning is with the creation of what is called a “DNSSEC Practice Statement” or more simply a “DPS”.  A DPS is a document that outlines how you are implementing DNSSEC for your domain – and what security measures you are putting in place.

Basically, it is a statement that can help other people understand whether they can trust the security you put in place.

Typically the DPS documents created so far are for Top-Level Domains (TLDs) as they have been the focus of much of the DNSSEC deployment efforts to date.  For second-level domains, very often you may be able to use the services of your DNS hosting provider to sign your domains and so a full DPS may not be needed. But if you sign your own domain, a DPS can be a useful way to plan out the security for your signing.

Regardless of what you do, the existing DPS documents make for great reading to help you understand the security you may or may not need to put in place to ensure the security and integrity of our DNSSEC operations.

The place to begin for many of you may be to take a look at this Internet-Draft that explains the rationale for creating a DPS and provides a sample framework:

http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework

Some of you who like to simply dive into examples to see how a DPS is written may want to start looking through the examples we’ve added to this page:

DNSSEC Practice Statements

In particular you may want to start with the “.SE” DPS as the folks from .SE have been very involved with creating the entire DPS framework.  As you look through the examples, you’ll see a variety of different styles and lengths, from the very simple to the very complex.

If you have 15 minutes to spare, this video from 2010 offers Anne-Marie Eklund-Löwinder from .SE explaining the value of a DPS and what should be included:

The important aspect of a DNSSEC Practice Statement is to capture in one document how you are implementing DNSSEC and how you are securing the tools, servers and other components involved with DNSSEC.  Even if you are an enterprise who might never publicly publish a DPS, writing such a document can be a very useful exercise to ensure you are planning for all the necessary aspects of using DNSSEC to sign your domain.

P.S. If you create and publish a DPS, we’re always looking for more examples to add to our DPS page. Please let us know where your DPS is located online so that we can consider adding it to the page.