July 17, 2014 archive

Jul 17

Congrats to Spain (.ES) and Croatia (.HR) on on their DNSSEC-signed TLDs in the DNS Root

Croatia and SpainCongratulations 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.

Jul 17

A Huge Amount Of DNSSEC Activity Next Week At IETF 90 In Toronto

DNSSEC badgeIf you are interested in DNSSEC and/or “DNS security” in general, there is going to be a great amount of activity happening in a number of different working group sessions at IETF 90 next week in Toronto.

I wrote about all of this in a post on the ITM blog, “Rough Guide to IETF 90: DNSSEC, DANE and DNS Security“, a part of the Rough Guide to IETF 90 series of posts.

You can read the full details (and find links to all the drafts), but here’s a quick summary:

  • The DNSOP (DNS Operations) Working Group will be talking about DNSSEC key and signing policies and requirements for DNSSEC validation in DNS resolvers.  The group will also talk about the “DNSSEC roadblock avoidance” draft before getting into what should be a lively discussion about how we better optimize the distribution of data in the root zone of DNS.
  • The DANE Working Group will discuss a number of ways the DANE protocol can be used with applications such as OpenPGP, SMIME, SMTP and more.  There will also be a discussion of turning the “DANE Operational Guidance” draft into an actual update/replacement for RFC 6698 that defines DANE. It should be very interesting session!
  • The SIPCORE Working Group will discuss a draft about using DANE and DNSSEC for SIP-based Voice-over-IP (VoIP).
  • The TRANS Working Group will explore whether or not there is a role for Certificate Transparency (CT) to play with DNSSEC and/or DANE.
  • The HOMENET Working Group will discuss two different drafts relating to DNSSEC and customer-premise equipment (CPE) such as home wifi routers.

And a couple of other working groups may have DNSSEC-related discussions as well.  All in all it will be a very busy week at IETF 90!

Again, more details and links to all of the associated drafts can be found in the Rough Guide to IETF 90 article about DNSSEC.

If you aren’t able to actually be in Toronto, you still can participate remotely – see the IETF 90 Remote Participation page for more information about how you can join in to the discussions.

If you are in Toronto, please do feel free to say hello and introduce yourself.  You can pretty much expect to find me in all of these various DNSSEC-related sessions (and many of the IPv6-related sessions, too).

The post A Huge Amount Of DNSSEC Activity Next Week At IETF 90 In Toronto appeared first on Internet Society.

Jul 17

A Huge Amount Of DNSSEC Activity Next Week At IETF 90 In Toronto

DNSSEC badgeIf you are interested in DNSSEC and/or “DNS security” in general, there is going to be a great amount of activity happening in a number of different working group sessions at IETF 90 next week in Toronto.

I wrote about all of this in a post on the ITM blog, “Rough Guide to IETF 90: DNSSEC, DANE and DNS Security“, a part of the Rough Guide to IETF 90 series of posts.

You can read the full details (and find links to all the drafts), but here’s a quick summary:

  • The DNSOP (DNS Operations) Working Group will be talking about DNSSEC key and signing policies and requirements for DNSSEC validation in DNS resolvers.  The group will also talk about the “DNSSEC roadblock avoidance” draft before getting into what should be a lively discussion about how we better optimize the distribution of data in the root zone of DNS.
  • The DANE Working Group will discuss a number of ways the DANE protocol can be used with applications such as OpenPGP, SMIME, SMTP and more.  There will also be a discussion of turning the “DANE Operational Guidance” draft into an actual update/replacement for RFC 6698 that defines DANE. It should be very interesting session!
  • The SIPCORE Working Group will discuss a draft about using DANE and DNSSEC for SIP-based Voice-over-IP (VoIP).
  • The TRANS Working Group will explore whether or not there is a role for Certificate Transparency (CT) to play with DNSSEC and/or DANE.
  • The HOMENET Working Group will discuss two different drafts relating to DNSSEC and customer-premise equipment (CPE) such as home wifi routers.

And a couple of other working groups may have DNSSEC-related discussions as well.  All in all it will be a very busy week at IETF 90!

Again, more details and links to all of the associated drafts can be found in the Rough Guide to IETF 90 article about DNSSEC.

If you aren’t able to actually be in Toronto, you still can participate remotely – see the IETF 90 Remote Participation page for more information about how you can join in to the discussions.

If you are in Toronto, please do feel free to say hello and introduce yourself.  You can pretty much expect to find me in all of these various DNSSEC-related sessions (and many of the IPv6-related sessions, too).

Jul 17

Administrative Update: Web site migrating to a new server

FYI, over the next few days we plan to be migrating this DNSSEC Deployment Initiative website to a new server on infrastructure supported by the Internet Society. During that time we don’t expect there to be any service disruptions, but for a brief period of time during the actual migration you may experience an issue with the validity of the TLS/SSL certificate as we switch to using a new certificate.

Please note that the “dnssec-deployment@dnssec-deployment.org” email discussion list will also be migrated to a new mailing list server.  While the address of the list will stay the same, the underlying SMTP headers will change by virtue of the move to a new server.  If you are a subscriber and are filtering or white-listing messages based on various SMTP headers, you may want to plan to update those filtering/white-listing rules once the list is migrated.

We will post an update when the migration has been completed.