Categories
Deploy360 Domain Name System Security Extensions (DNSSEC)

DNSSEC Algorithm Roll-over

ripelabs_128RIPE Labs have just published an interesting article about their experiences of rolling over the algorithm used to sign a DNSSEC zone. The RIPE NCC was one of the first organisations to sign its zones with DNSSEC which meant using RSA/SHA1 as this was the only defined algorithm at the time.

In recent years it’s been demonstrated that SHA1 has certain vulnerabilities which is why RFC 5072 standardised the use of SHA2, even though many validators did not support it at the time. Since then, SHA2 has has become better supported by validators, and this combined with the fact that the root zone is now signed with SHA2, was the reason for the RIPE NCC to roll over the ‘ripe.net’ domain to the stronger algorithm.

This proved less than straightforward as firstly their original signer software could only sign the zone with either SHA1 or SHA2 but not both. A new version of the signer was therefore required, but after setting up a test system and introducing SHA2, it became apparent that BIND and Google DNS were able to validate the zone, whereas Unbound and Verisign DNS did not.

Further investigation traced this to the use of separate Zone Signing Keys (ZSKs) and Key Signing Keys (KSKs) and expectation of some validators that the algorithm signalled by the Delegation Signer (DS) record is used to sign all records in the zone. This is a more strict interpretation of RFC 6840, and whilst the latest version Unbound does now have an option to relax this validation requirement, implementors should be aware of this issue.

The recommendation of RIPE Labs is that the KSK and ZSK should be rolled at the same time, and the old ZSK should not be withdrawn until the KSK roll-over is complete. NLnet Labs have also published an article on rolling DNSSEC algorithms on OpenDNSSEC as the current version of OpenDNSSEC does not directly support this.

References

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC) Tutorials

Case Study: The Experience of Signing Go6.SI with DNSSEC

Some time ago Matthijs Mekking, one of the authors, maintainers and coders for the OpenDNSSEC project asked me why go6.si domain was not signed. My answer was that I need a short, precise and deployment/operations-oriented document with clearly described steps on how to setup the signing platform, how to add a zone and sign it.

Matthijs accepted the challenge and soon we got the first draft of the document to Go6lab. There were some errors in the procedure, so together we fixed them. Matthijs added some more information that he saw as needed for better understanding and re-tested the procedure again – and this time it worked. After some cycling through the Linux distributions we found that using Fedora and installing OpenDNSSEC from their repository usually brings you the latest version of the code – and the issue that we found in first round of testing was fixed in new version (the issue was that if you had OpenDNSSEC signer as “bump in a wire” between silent primary and secondaries that served the signed zone – signer did not understand “NOTIFY” message from primary and did not transfer new zone for signing).

opendnssec_logo_120We decided to install OpenDNSSEC signer as “bump in a wire”, fetching the unsigned zones from the “silent” primary server, where we edit and change the zones (with notify to signer), sign the zones on signer server and push them over AXFR to two secondary servers that acts like primary and secondary DNS for that zone. Seems easy – and it is, in a way 🙂

The “silent” primary server runs on PowerDNS with a mysql database backend. The two secondary servers that are serving the signed zones are both running bind9.

At first glance all worked fine, following the deployment guide we added go6.si, go6lab.si and zorz.si zones for signing (zorz.si was a test “mule” to see if the process works). The signer got the zones, signed them and pushed them to both name servers nsec1.go6lab.si and nsec2.go6lab.si. Our .si TLD dnsmaster Benjamin Zwittnig inserted for us DS records in .si zone and the whole thing started to work. We are pressing now our registrar to implement the tool to insert DS records to .si zone without bothering Benjamin.  Hopefully this happens soon.

So, with DS records in parent zone we were able to test the whole thing and all was fine… until I stopped changing the zones and the primary server did not send any NOTIFY to signer server that there is a change in the zone for some time. And that “some time” was exactly the time that was set for a zone to expire. What happened was that signer server realized that the zone expired and instead of asking his primary name server for retransmit (AXFR) – the server expired the zone and stopped serving it.

So, zorz.si was off-the-Internet for 20 minutes!  When my monitoring system alerted me that there is something wrong with DNS responses for that domain, I immediately figured out that signer expired the domain without refreshing it at the primary server.

As I needed to solve this issue quickly I created cronjob that forces a NOTIFY for all signed domains on hidden primary server every day at midnight – and so domains never expires on signer server. I also reported this bug to Matthijs and I think that the fix will be done in next release of the software.

It’s good to have a real environment where we can test and stress-out these new tools that are making the Internet a safer place – and also make these tools better with finding bugs before they hit somebody else in a big production environment.

You can now download the latest draft of Matthijs’ opendnssec-start-guide document that I used to set up the whole thing. Please note – it’s a draft, so all comments, suggestions and ideas are more than welcome.

screen-capture-278How did we test if our DNSSEC signing was correct and valid? We used three tools:

… but there are many others out there, described at our DNSEC Tools page.

P.S. If you would like to get started with DNSSEC, please visit our Start Here page to find resources tailored for your type of organization or role.

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC)

Free DNSSEC Training May 22-23, 2014, in Stockholm, Sweden

OpenDNSSEC logoAre you in Stockholm, Sweden, (or can easily get there) and interested in learning more about DNSSEC? If so, we’ve learned that the great folks at OpenDNSSEC will be offering a free two-day training class on May 22-23, 2014.  More info can be found at:

http://www.opendnssec.org/support/trainings/

The agenda is online as are the study materials. This training is obviously aimed at people who will use OpenDNSSEC as a means of signing their DNS zones and if you haven’t considered that option before you may want to do so.

Given that this is a hands-on workshop, it is not available for remote participants.  As the web page notes, the OpenDNSSEC team is open to bringing this training to other locations.

For other training options, please visit our DNSSEC Training page.

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC)

OpenDNSSEC Offering Free DNSSEC Training Oct 10-11 in Stockholm, Sweden

OpenDNSSECInterested in learning more about how to use OpenDNSSEC to secure your DNS infrastructure with DNSSEC?  We recently learned from a post by Patrik Wallström in the DNSSEC LinkedIn Group that there will be a free training class in Stockholm, Sweden, on October 10 and 11, 2013.  More information and a registration link can be found at:

https://www.opendnssec.org/support/trainings/

Patrik notes:

You are welcome to attend a free training course in OpenDNSSEC.  It is a two-day training, where you get a mixture of theory and hands-on experience. We will be using virtual servers hosted by Amazon, so please bring your own laptop.

The full agenda for the training class can be found on the .SE site.

It’s great to see this training happening in Stockholm – and Patrik notes that people can contact him to discuss offering this training in your community (his contact info is on the training page).