Category: maps

We were very pleased to learn this morning that both Indonesia’s .ID and Vanuatu’s .VU country-code top-level domains (ccTLDs) had DS records uploaded to the root zone of DNS over the weekend.  What this means is that they have both entered the fourth of five deployment stages that we track as part of the DNSSEC Deployment Maps.

At some point soon, people who have registered domains under .ID and .VU should be able to upload their own DNSSEC records and be able to obtain the higher level of security and trust that comes with having their domain signed with DNSSEC.  We don’t yet know when the registries for .ID and .VU will start accepting DS records from registrants, but hopefully at some point soon.

Given that the records were entered into the root zone of DNS after I had finished updating the database on Friday for the DNSSEC Deployment Maps that were distributed this morning, I took the unusual step of re-generating the maps today after a quick database update.  Subscribers to the public dnssec-maps mailing list have all received a second set of maps for today.  Normally I might have just waited for next week but given Indonesia’s size it adds a nice bit of green to the Asia Pacific map and I wanted that to be shown.

With these two ccTLDs having their DS record in the root zone, this brings us to 97 of the 247 ccTLDs that we track in our database being signed with DNSSEC.  (There are also .EU and .SU which we consider more “regional” TLDs (and are both signed), but other lists count as ccTLDs, so you could say that we show 99 of 249 being signed.)  Given that most of the generic TLDs are signed and all the new gTLDs MUST be signed when they launch, the remaining 150 unsigned ccTLDs are the major area where attention will be focused over the next while in terms of getting TLDs signed.  ICANN’s DNS team is spending a good bit of time traveling to many of these countries to help them get their ccTLDs signed and operational.

Congratulations to the teams at .ID and .VU for getting their domains signed and linked in to the DNSSEC global “chain of trust”.  We look forward to learning that those two ccTLDs become “Operational” and second-level domains can begin uploading DNSSEC records soon.

Note – if you would like to learn more about how you can get started with DNSSEC, please visit our Start Here page to find resources tailored to your role or type of organization.

Today’s DNSSEC Deployment Maps have two great new additions for country-code top-level domains (ccTLDs): Australia’s .AU domain and Grenada’s .GD domain both had their DS record published in the root zone of DNS over the past few days.  What this means is that anyone who has registered a domain in .AU or .GD may soon be able to gain the increased security of signing their own domain with DNSSEC and tying it into the “global chain of trust” of DNSSEC.  To be clear, these two ccTLDs have entered the 4th of 5 stages of DNSSEC deployment where the DNSSEC chain of trust now extends from the root of DNS to the ccTLD itself.  The next “Operational” stage is where the ccTLD starts accepting DNSSEC records from registrants.  Hopefully that time will not be far away for both of these ccTLDs.  (To get ready, please visit our Start Here page to find out how you can prepare your organization to work with DNSSEC.)

Given Australia’s large size on a map, the new “DS in Root” bright green shows up wonderfully in the global view:

and even better in the Asia Pacific view:

Unfortunately with the resolution of our maps you can’t really see Grenada on the Latin America map, but I can tell you that it is one of the six ccTLDs in the “DS in Root” stage in the map:

Congratulations to the teams at both ccTLD registries!

In the case of Australia’s .AU, the registry organization, auDA, has been experimenting with DNSSEC since back in 2008 and 2010, and signed the .AU zone back in April 2014 (entering into our “Partial” state on the maps).  The news this past week is the culmination of all that work over several years.  AuDA has also published two pages of interest:

• DNSSEC page, showing their intended deployment timeline
• Interim DNSSEC Policy and Practice Statement (DPS) for the .au Domain

We look forward to learning that auDA is accepting DNSSEC records from .AU registrants and enters the fully “Operational” state.

In the case of Grenada, the first we knew was when the DS record was published in the root zone (seen on stats sites like this one). I couldn’t see any further information on Nic.gd, so I don’t know their further plans at this point.  Regardless, it was a wonderful surprise to learn that .GD was signed and had the DS record in the root zone!

In fact, November was a great month for ccTLDs and DNSSEC with Norway’s .NO signing and Ireland’s .IE signing and also entering the “Operational” state.

All great to see!  We’re looking forward to the day when our DNSSEC deployment maps are all green!

If you want to get started with DNSSEC – or just learn more of what it is all about, please visit our Start Here page to find resources tailored for your type of organization or role.

If you have been receiving our DNSSEC deployment maps by email or just using the maps from our web page, you need to know an important fact:

The maps we’ve been publishing recently have had the incorrect status set for several countries.

The maps published last week on October 14, 2014, (and the ones distributed via email today) have now been fully verified to have the correct status of all country-code top-level domains (ccTLDs).

The maps are correct today!

To explain a bit more, in preparation for last week’s DNSSEC Workshop at ICANN 51 I was puzzled by something that didn’t seem right with we were publishing.  Specifically, Australia was showing up in a September map as having a “DS in Root” when I knew for a fact that .AU did not (and could easily confirm using “dig” at the command-line).  Diving into the issue more, I discovered what happened.

One of the strengths of our set of DNSSEC deployment maps is that we track 5 stages of DNSSEC deployment versus simply showing whether they are publishing a DS in the root zone.  This allows us to do some forward projection to what we think the state of DNSSEC deployment may be in the future based on statements made by various ccTLDs about their plans for DNSSEC deployment.

But what if those plans don’t work out exactly right?

Our database contains records for each ccTLD based on both factual data (such as whether they have a DS record in the root zone) and observed information that could be from announcements, presentations at industry conferences, blog posts, email messages, etc.

In this case, there were forward-looking records for a number of ccTLDs that had been entered into the database but then had not actually happened on the projected dates.  For whatever reasons, various plans and public statements did not hit their target dates.

I spent my plane flight out to Los Angeles going through the tedious exercise of comparing our database with a list of TLDs that had a DS in the root zone, and then followed that up with further confirmations once I had Internet access in L.A.  The end result is that I identified the forward-looking records that needed to be changed and updated our database in time to generate the maps I needed for last Wednesday’s workshop.

I also identified a hole in our process where I was not routinely checking the forward-looking records to be sure that they were in fact happening.  This is all part of the learning process after we took on maintenance of these maps from Shinkuro, Inc., earlier in 2014.  Now we’ll be sure to check this in the future.

I do apologize if anyone used these maps in recent presentations over the past few months.  We’ll be working to make sure they stay updated in the time ahead.

By the way, if you do want to receive these DNSSEC deployment maps by email each week, you can subscribe to the public email list.  The maps are distributed via email each Monday morning, along with comma-separated value (CSV) files containing the DNSSEC status of all the ccTLDs and the generic TLDs (gTLDs).

And… if you want to get started with DNSSEC yourself, please visit our Start Here page to find resources aimed at your type of organization or role.

Do any of you have any suggestions for a better palette of colors for us to use for our DNSSEC deployment maps?  We generate them every Monday morning and send them out to a public mailing list (to which any of you are welcome to subscribe).  Here is a recent global view (click/tap to see larger image):

My issue (and maybe this is just me) is that I’m not entirely fond of the colors used in the “early” stages of a TLD’s deployment.  As we note on the deployment maps page, we track a TLD through five stages of DNSSEC deployment:

• Experimental – Internal experimentation announced or observed
• Announced – Public commitment to deploy
• Partial – Zone is signed but not in operation (no DS in root)
• DS in Root – Zone is signed and its DS has been published
• Operational – Accepting signed delegations and DS in root

The most important states are the final two when DNSSEC for the TLD is “working”.  I like the existing green colors for those two states, although the “DS in Root” green is perhaps a bit brighter than I would want.  The point is that we want to use green to show the “good” states of DNSSEC deployment – and over time we’d like to see the whole map go to that darker shade of green.

It is the first three states that bother me a bit.  There is a progression between those three states as it often goes like this:

• Someone from a TLD says at a conference or on a mailing list that they are experimenting with DNSSEC.  We can then flag them as “Experimental”.
• Perhaps next someone from that TLD issues a formal statement, publishes a blog post or these days sends out a tweet or posts another social media update saying that they are going to deploy DNSSEC.  We can then flag them as “Announced”.
• Then at some point the TLD’s zone is actually signed with DNSSEC, but the DS key hasn’t been uploaded to the root.  Now we can put them as “Partial” in the database.

In my ideal world I’d have some color progression that shows the movement along this path.  The orange, yellow and blue we currently use don’t really show a progression.   I’ve tried using different shades of yellow or orange but you also want it to be easy to determine what state a given TLD is in – and for that the current set of colors does work.

Anyway… if anyone has ideas I’d be open to hearing them.  The software we’re using can set the colors to be any of the typical hex-encoded colors used in web pages.  It can’t do shading or lines or anything like that, just colors.

Please feel free to leave suggestions here – or contact me directly at york@isoc.org.  Thanks!

P.S. And if you would like to help get more domains signed with DNSSEC, please see our “Start Here” page to find resources targeted at your type of organization!

Congratulations to the teams at the top-level domains (TLDs) of both .ES (Spain) and .HR (Croatia) for getting their DNSSEC-signed TLDs in the root of DNS!  Looking at Rick Lamb’s DNSSEC Deployment Report today I can see that as of yesterday both TLDs had a DS record in the root zone of DNS.

Both will now appear with the “DS In Root” status in our DNSSEC deployment maps that get generated every Monday (and to which all are welcome to subscribe).

What this means is that the TLDs have been signed with DNSSEC and as of yesterday can now participate in the “global chain of trust”. DNSSEC-signed second-level domains under .ES and .HR will now be able to have their signatures validated and confirmed from the root of DNS all the way down to their domains.

Now… I should say that this is technically possible at this point in time.  The DS records for .ES and .HR are now in the root zone.  Second-level domains could be validated from the root all the way down.

However, we can’t tell from external observations whether someone with a .ES domain can provide their DS record up to the .ES TLD – and the same for .HR.  We can’t tell if those registries are allowing DNSSEC signatures from second-level domains.  So it might or might not be possible today… but there is no longer a technical roadblock in the DNS system – it is now up to the TLD registries to allow registrars to submit DNSSEC records for domain registrants.  (And once we can confirm that they are allowing DS records from second-level domains we’ll set their status to “Operational” in the DNSSEC deployment maps.)

Congratulations again to both teams – and if you have registered a .ES or .HR domain, you can now start asking your registrar to find out when you will be able to get the increased security of DNSSEC and try new services like the DANE protocol!

Want to get started with DNSSEC and DANE? Check out our “Start Here” page to find resources tailored to your type of organization – or please let us know if you need additional material.

P.S. In entering the information about .HR for Croatia into our DNSSEC Deployment Map database, I discovered that the status had been previously incorrectly set to “Operational” based on some earlier information that had not been updated.  Croatia has been showing up in that state since the end of March 2014.  We regret that error and now will correctly be showing Croatia as “DS in Root” on the maps that get generated on Monday, July 21, 2014.

I’ve made a couple of updates recently to our DNSSEC Deployment Maps section of the site.

First, I updated the page to display the most recent deployment maps from yesterday, April 28, 2014.  The big change from previous maps is that Australia now appears in blue as the folks there have signed the .AU top-level domain on their production servers, but the DS is not yet in the root of DNS (that is scheduled for August 2014 right now).

Second, I changed the settings on the archive of the ‘dnssec-maps’ mailing list to be publicly accessible.  This means that anyone can simply go to the archive to obtain the most recent set of DNSSEC deployment maps and also the comma-separated value (CSV) files that track all the domains, including generic TLDs and the “newgTLDs”.   The deployment maps are generated automatically every Monday morning so with the list archive publicly available you can always get to the most recent version of the maps.

Ultimately I’d like to figure out how to have the maps automatically update on a page on our site by way of some type of WordPress plugin or other mechanism, but for the moment I’m still manually updating the images on the DNSSEC deployment maps page whenever there have been major changes or after a longer period of time has passed.

If you’d like to receive these maps automatically every Monday, you can simply subscribe to the ‘dnssec-maps’ mailing list and you’ll receive an email with the maps and CSV files each week.    If you have ideas for enhancements, we’re also tracking those over on Github – feel free to raise “issues” with any ideas or feedback you have.

The positive reaction to our publishing of DNSSEC deployment maps has been great to hear and I wanted to provide a quick update.

1. The DNSSEC deployment maps are published every Monday. The best way to receive the most current maps is to subscribe to the dnssec-maps mailing list.   I will be updating our DNSSEC Deployment Maps web page from time to time when there are major changes, but the most recent maps will always go out to the mailing list.  (I’d love to automate the posting to the web page – ideas about how to do so in WordPress are definitely welcome!)

2. There is a Github repository where you can file issues/suggestions. In preparation for making the source code publicly available, we’ve created a repository on Github at https://github.com/Deploy360/dnssec-maps/ We still need to do make some changes to the code to make it publicly available, but in the meantime the major feature of the Github repo is that we now have a convenient place to track “issues”, which could be bugs or feature ideas or more.  If you have a Github account (or want to create a free one), you are welcome to raise issues at:

https://github.com/Deploy360/dnssec-maps/issues

I don’t have a timeframe for when we’ll make the code available – it’s honestly a bit of a background task that I’m trying to fit in amongst everything else and with IETF 89 fast upon us it may not happen for a few weeks.  Meanwhile, though, the issue tracker is already being helpful.

3. All newgTLDs have been entered up to now. I finally caught up with the backlog of all the DNSSEC-signed “new generic top-level domains (newgTLDs)” that have been delegated by ICANN and now have a DS record in the root zone.  These newgTLDs don’t show up in the DNSSEC deployment maps but do show up in the CSV files that are emailed out every Monday.  Given that ICANN is delegating more newgTLDs on a weekly basis, it will be a constant effort to update our database, but at least now we’re caught up to the present time.

4. Visualizing the DNSSEC status of the generic TLDs is of interest. As I noted in a recent post here, I would like to think about how we could provide an image in the email that visualizes the DNSSEC status of all the generic TLDs, both the “newgTLDs” and all the ones that existed before.  Suggestions and ideas would be welcome, either to this post or to the “issue” on Github.

That’s the quick update… I am glad some folks are finding this service useful and welcome any comments and feedback.  Thanks!