Archive for June, 2012

A minor (personal) milestone — I’ve collected DNSSEC data for the root and TLDs for 366 days (1 year because of the leap day).  During the collection I’ve done periodic analysis to see how DNSSEC is being driven by experts and have given a number of presentations on what’s been happening.  How DNSSEC is being run?  How do the operations differ from what the protocol engineers and RFC writers forecasted?  There are presentations in the archives for APRICOT, ICANN, IEPG, RIPE and CENTR meetings that have been held this past winter and spring that cover these questions from different angles.

Now, at the one year mark, for fun, a look at what’s not changed.

Not so noteworthy, because KSK’s are expected to be used on the order of years, these records have been a constant:

• 70 DNSKEY records holding SEP/KSK’s
• 44 DNSKEY RRSIG records, usually signed by SEP/KSK’s
• 46 DS records in the root

But these fairly noteworthy:

• 6 RRSIG records for NSEC/NSEC3PARAM and SOA
• 9 DNSKEY records holding ZSK’s (not alarming, but…)
• 40 NSEC3PARAM – specifically 40 unchanged salts

First an explanation is needed (as usual when analyzing any set of data) – when I write that an RRSIG is unchanged, that refers to the signed-by fields and not the signature payload itself.  The TLDs are refreshing signatures as needed, but when the key isn’t changed (as well as some other parameters) my analysis considers the RRSIG to be the same.

What this analysis says is that there are 6 TLDs that have used a ZSK for a full year to generate signatures. Each of the 6 keys is RSA-SHA1 and 1024 bits long. So some are challenging the (“CW”) notion that long lived keys will break. Publishing a ZSK for a year (per se) is not risky, but it shows that at least 9 ZSK’s have a longer lifetime that expected.

Besides the 6 ZSK keys that signed every day, the other three, two never generated signatures and one did so over about a 9 month period.

The 40 unchanged NSEC3PARAM records indicate that 40 TLDs have run NSEC3 for a year (plus) and have not changed the salt (as opposed to the 4 TLDs that change the salt daily or nearly daily).  The RFC recommends “with every signing” but few do “batch” signing anymore.

Final note – these counts do not cover the TLDs that have begun operations within the past 366 days.

Ed Lewis

Director, Member of Technical Staff at Neustar

As seen on the DNSSEC Deployment Working Group email list:

Invitation to Informal Gathering of DNSSEC Implementers in Prague 26 June

On behalf of the DNSSEC Deployment Initiative and CZ.NIC, DNSSEC Implementers are invited to attend an informal gathering to discuss and exchange information on their DNSSEC implementation experiences during the ICANN meeting in Prague, Czech Republic. This is a unique opportunity to meet with and talk to key implementers, such as CZ.NIC, Nominet UK, ISC, IIS Sweden, and others. We do ask that in order to participate you should come prepared to say a few words about your experiences. This is a peer-to-peer event for implementers.

Where: Pivovarsky klub

When: Tuesday, 26 June 2012, 6:00 to 8:00 pm

Note that this event is in addition to the other DNSSEC events scheduled during the ICANN meeting. These are:

Monday, 25 June: 4:00-5:30 pm — DNSSEC for Everybody – Roma, Details: http://prague44.icann.org/node/31657

Wednesday, 27 June: 8:30 am to 1:45 pm — DNSSEC Workshop at ICANN Meeting – Congress I, Details: http://prague44.icann.org/node/31749

**Please RSVP to [email protected] no later than Friday, 22 June if you would like to attend.**

Best regards,

Julie Hedlund

On behalf of Ondřej Surý, CZ.NIC and Steve Crocker and Russ Mundy for the DNSSEC Deployment Initiative

As with other recent ICANN meetings, there will be a DNSSEC workshop at ICANN 44.  The workshop will be held on Wednesday, 27 June 2012 from 08:30 until 13:45 CEST (UTC/GMT +2 hours).   Remote participation is available for the meeting.

The agenda for the meeting as it currently stands:

1. Introduction and Presentation: DNSSEC Deployment Around the World: Steve Crocker, Shinkuro

2.  DNSSEC activities in Europe

3. ISPs and Validation

4. The realities of running DNSSEC

5. DNSSEC and Enterprise Activities

6. DANE and other DNSSEC applications

7. The Great DNSSEC Panel Quiz

We’ve taken to putting up animated maps of DNSSEC adoption in country code TLDs (ccTLDs) every few months (6 March 2012, 4 June 2012).   One question we get is,  “So, what does the legend in the maps we produce indicate?”  From the past through the date of the map, the following are from observation.  For dates beyond the date of the map, the following are either an extension of the observation or based on stated plans.

• Experimental  (yellow) — We have reason to believe that the ccTLD is (or will be) experimenting with DNSSEC.
• Announced (orange) — The ccTLD has announced that they will support DNSSEC.
• Partial (green)  — The ccTLD has signed their zone, but has not yet passed DS records up to the root and may or may not be accepting signed delegations.
• DS in Root (blue) — The ccTLS is signed  and DS records for its KSKs are (or will be)  in the root zone, but it is not yet accepting signed delegations.
• Operational (red) — The ccTLD is signed, it has DS records in the root, and it is accepting signed delegations (DS records from child zones).

We can and do identify current Partial and DS in Root statuses programatically.  Everything else needs human input.  Specifically, your input sent to info @ dnssec-deployment.org.

This animated GIF shows announced, estimated, and actual DNSSEC adoption by ccTLDs from January 2006 through July 2014 as of 4 June 2012.  The map is a work in progress.  We’re pretty sure about the past and present.    If you manage a ccTLD and have a schedule for deployment or have updates/corrections, let us know at info @ dnssec-deployment.org.  We’d like to see a more colorful, even completely red, map in the future