DNSSEC algorithm-rollover with simple scripts

Finally I’ve found some time to transition my DNSSEC setup to a new algorithm. It took a lot of research, reading and finding the right tools. It appears that still everyone is using automated setups, which means nobody knows what is going on anymore when you’re talking nitty-gritty details on DNSSEC.

As an example: there is a lot of discussion of people saying that the KSK/ZSK setup is not necessary anymore, certainly not with ECDSA. But there is no example of it anywhere on how to actually run a domain with a single key. Using OpenINTEL we found that the number of CSK situations is roughly 5% in the Netherlands, and around 1-2% for zones like .net, .com and .org. Note, this percentage is of DNSSEC domains, not all domains.

Here’s what I’ve done on moving my zone over to a single key ECDSA P-256 with SHA256, also known as Algorithm 13 in DNSSEC.
The tooling that I’ve used is the LDNS toolkit extended with my own signzone script and ldns-mergezone. All very simple tools that operate on text-based zone files and should work with any kind of DNS server.

Summary of the procedure

The global reasoning behind the methodology below is to prevent inconsistencies in DNS caches. This is why you first add new signatures without any key information. They can exist harmlessly alongside the old signatures. A strict reading of the RFCs require that signatures exist in every algorithm in DNSKEY records. Some older resolvers do this strict reading and may treat your entire zone as bogus if they encounter an algorithm without the corresponding signatures. This can possibly happen in certain cached situations.

This is why, once the current TTL runs out you are sure that the signatures exist everywhere, you can add the key information. Again, alongside the old signatures, so that the old key still works. At that point you have a zone that is valid by both the old key as well as the new key. Then you switch upstream to the new key. Once you’re happy that it works, the final step is that you remove the old key and then the old signatures. Again, to prevent a situation where there could be a key without the corresponding signatures.

If you want to verify your steps during the process, I recommend DNSviz.net or DNSSEC-debugger.

Initial step

Prepare the change in DNS, lower the TTL of your DNS zone. Depending on how fast you want to move you can lower to 5 minutes (600) or 1 hour (3600). In NSD the TTL is written as the number just after the RR type.

I moved the original keys and zonefile into a new directory “oldalgo”. Run a “signzone.sh” operation on it to make sure there is a new version number. The end result in this folder is only that you have a new SOA version number.

# signzone.sh oldalgo/1sand0s.nl.zone

Create a new directory “newalgo” with a copy of the same original zone file (with the old SOA) and generate a new key. We generate this key as a “KSK”, because that means the SEP flag is set. The flag value will be 257, but we can just use it to sign the entire zone.

# ldns-keygen -k -a ECDSAP256SHA256 1sand0s.nl

The zonefile in this directory must be edited so that the zone also contains the DNSKEY records of the oldalgo.

# egrep "IN[[:space:]]+DNSKEY" oldalgo/1sand0s.nl.zone.signed >> newalgo/1sand0s.nl.zone
# signzone.sh newalgo/1sand0s.nl.zone

Then as the first step of the transition you want to introduce the new signatures, without introducing a new key. The old signatures will be there as well. The oldalgo and newalgo zones should both have the same SOA version number. Then we use the ldns-mergezone utility to do the merging in the proper way for the first step.

# ldns-mergezone -f oldalgo/1sand0s.nl.zone.signed -t newalgo/1sand0s.nl.zone.signed -1 -o 1sand0s.nl.zone.signed
# nsd-control reload

The resulting situation in DNSviz should look like something like this (the yellow flags are a warning for the time being too close to the current):

Preparing for a new DNSKEY record with new signatures

Introducing the new DNSKEY record

In the second step we’re introducing the new DNSKEY, which will be signed by both keys. This means we’re editing the zones in the oldalgo folder:

# egrep "IN[[:space:]]+DNSKEY" newalgo/1sand0s.nl.zone.signed >> oldalgo/1sand0s.nl.zone
# signzone.sh oldalgo/1sand0s.nl.zone
# signzone.sh newalgo/1sand0s.nl.zone
# ldns-mergezone -f oldalgo/1sand0s.nl.zone.signed -t newalgo/1sand0s.nl.zone.signed -2 -o 1sand0s.nl.zone.signed
# nsd-control reload

The result is a zone that is signed by both the oldalgo and the newalgo (RRSIG), containing the identifiers (DNSKEY) of both keys. The trust boundary is still with the original key.

This results in a slightly updated picture at DNSviz showing that the new key is distributed with the zone:

Adding the new DNSKEY record alongside the old algorithm

Switching over to the new DNSKEY

We wait the TTL of your own zone to make sure that everyone has this new DNSKEY record. Make a record of the DS key that currently exists for your zone for safekeeping should something go wrong. Now we can change the DS record at your registrar to point to the new key. Depending on your registrar you may need to provide your own DS record, or just enter the keytag and the public key.

# ldns-key2ds newalgo/K1sand0s.nl.+013+45114.key
# less newalgo/K1sand0s.nl.+013+45114.ds
1sand0s.nl. 3600 IN DS 45114 13 2 0c29a394d7f5eae8088d29eff3ef3113bdf9b9456d27f78af0dde48c7a122e02

Once you’ve changed the new key information at your registrar, you have to wait until the upstream zone does an update, depending on the upstream this can take up to an hour.

In this stage, if you did something wrong, you can just switch back to the old DS record, by changing it back to point to the old key. Everything will go back to the old situation as soon as the upstream updates again. Should everything have gone correctly, it will look something like this:

Switching over to the new key and algorithm, alongside the old signatures and keys

Transition to the new situation

Everything should now be in order, the new RRSIGs have been distributed and the new DNSKEY record is known everywhere. Final ingredient is that the upstream DNS server also points to the new DNSKEY. The only thing left to do is to clean up. To be careful we remove the DNSKEY entries first, and the old signatures later. First edit the newzone and remove all the DNSKEY records, then go ahead as follows:

# vim 1sand0s.nl.zone # remove all the DNSKEY records
# signzone.sh oldalgo/1sand0s.nl.zone
# signzone.sh newalgo/1sand0s.nl.zone
# ldns-mergezone -f oldalgo/1sand0s.nl.zone.signed -t newalgo/1sand0s.nl.zone.signed -3 -o 1sand0s.nl.zone.signed
# nsd-control reload

Finally to the new production situation

Finally, once another TTL has expired you can go to the new production situation with just one (new) algorithm in the signed zone.

# cp newalgo/* .
# signzone.sh newalgo/1sand0s.nl.zone

The proper zone and just the single new key will be in this directory, so the zone can now be signed using the signzone script, which will introduce the proper DNSKEY record again.

And you’re done!

Zorgverzekeringen vergelijken op security en internetstandaarden (Update 9/12)

Het einde van het jaar nadert en dan is het tijd om je te oriënteren op je zorgverzekering. Dat kan je doen door allerlei vergelijkingswebsites en kijken naar vergoedingen en premies. Je kunt kijken naar het salaris van de directeur en wat hij ermee doet. Maar je kunt natuurlijk ook kijken hoe serieus ze hun security en internetstandaarden nemen. Hieronder een klein overzicht van mijn bevindingen

9/12/17 Update met SSLLabs score

Gesorteerd op score en op alfabetische volgorde:

  • A+ ONVZ https://www.onvz.nl/account/login
  • A+ Univé https://login.unive.nl/login
  • A+ Zekur https://www.zekur.nl/
  • A+ Zilveren Kruis https://inloggen-digid.zilverenkruis.nl
  • A+ ZorgDirect https://www.zorgdirect.nl/
  • A AnderZorg https://applicaties.anderzorg.nl
  • A DeFriesland https://www.defriesland.nl/Particulier/Login/Digid
  • A Ditzo https://mijnzorg.ditzo.nl/
  • A DSW https://mijn.dsw.nl
  • A Menzis https://applicaties.menzis.nl
  • A PNO https://web.pnozorgverzekering.nl
  • A StadHolland https://mijn.stadholland.nl/
  • A Zorg&Zekerheid https://apps.zorgenzekerheid.nl
  • A- FBTO https://inloggen.fbto.nl
  • A- Interpolis https://inloggen.interpolis.nl
  • B CZ https://mijn.cz.nl/
  • B DLZV https://mijn.dlzv.nl
  • B OHRA https://mijn.ohrazv.nl
  • C Bewuzt.nl https://mijn.bewuzt.nl/?login

De iPad app bij de verkiezingen

Dit jaar heb ik plaatsgenomen bij een stembureau in Utrecht met het idee dat ik het analoge proces van harte wil ondersteunen en graag aan anderen wil uitleggen waarom. Het trof, dit jaar werd ook net een stembureau app geïntroduceerd in Utrecht. Hieronder mijn ervaringen daarvan.

Continue reading

Making real use of DNSSEC: DANE

By now we can safely say that DNSSEC as a standard is here to stay. It may not be pretty or completely practical, but it is possible to implement it relatively easily. DNSSEC provides a little bit more assurance on the integrity of the DNS query results. This extra assurance does enable some other interesting applications, to increase the integrity of other systems. This is done through the standard called DANE: DNS-based Authentication of Named Entities. In this post I’ll walk through a couple of examples.

Update 23/7/2015:  Added email TLSA record instructions

Update 23/7/2015:  Corrected email TLSA record instructions

Continue reading

[Dutch] Afsluiting WOB verzoek Jeugdzorg

Op 3 december 2014 heb ik de uiteindelijke beslissing gekregen op mijn bezwaar. Dit besluit heeft erg lang op zich laten wachten nadat we op 10 september geprobeerd hebben het informeel op te lossen. De gemeente heeft haar besluit nu uitvoerig gedocumenteerd.

Continue reading

Beveiliging van Jeugdzorg ICT Infrastructuur

Het begon allemaal met een startknop. Niet veel later was er een dikke vinger. Na een jaar stond ik voor het eerst voor de rechter en uiteindelijk kreeg ik na veel aandringen te horen dat ik niets zou krijgen. Niet omdat het niet mocht, maar omdat er niets te halen viel. Maar daarmee kan ik wel laten zien dat de gemeente geen interesse lijkt te tonen voor de beveiliging van een belangrijke ICT infrastructuur. Een verslag van mijn eerste WOB-verzoek.

In oktober 2013 ging ik met mijn jongste dochter naar het consultatiebureau. De kinderarts zocht wat dingen op en ik keek mee op het scherm. Tot mijn schrik zag ik daar een grijze startknop. Zo een die hoort bij een uitgefaseerde Windows versie. Maar op die computer staat heel veel gevoelige informatie over mij, mijn dochter, maar ook over andere ouders en kinderen in de buurt, en verbonden met computers met gegevens uit heel Utrecht.

Continue reading

DNSSEC Key Rollovers Explained

In an earlier post I explained the idea of DNSSEC how to generate keys and sign your DNS zone. In this post I will walk you through the rollover methods as described in RFC 6781. You should understand the rollover process so that you can securely run your zone. This way you can  replace the key in a secure manner when necessary, without service interruptions.

In the earlier post I explained that there are two sets of keys for most DNSSEC signed zones, a Key Signing Key (KSK) and a Zone Signing Key (ZSK). The ZSK is used most often, and should be replaced about yearly, and is also the easiest to replace. Once that process is explained, it is easier to understand how to rollover a KSK also. Continue reading

Going down an elliptically curved rabbit hole

Yesterday I posted a guide to securing your nginx server with some good SSL settings. As I mentioned in that post, I am eager to get rid of RSA entirely, because it is going to be broken at some point in the not so distant future. So I spent part of the day researching the possibility of using Elliptic Curve Cryptography for my site, below are some of my findings.

Continue reading

Securing your site with nginx

This week in the Netherlands the news hit again that some secure websites where vulnerable to a downgrade attack. This attack is not new, but for the average user it is hard to detect. You have to be careful that you see the lock when you are entering your credentials.

Fortunately, most new web servers and browsers have a setting for it, called HTTPs Strict Transport Security (HSTS). With that feature enabled, if your browser has ever contacted a website over a secure link (HTTPS), then it will not allow a downgrade to plain HTTP for that host. This of course means that you are more secure, at least as long as you watch out for certificate warnings. I use the nginx webserver, and use some other things for security, which I’ll share with you below. The SSLLabs test will give this configuration an A+ currently.

Edit 26/3: @okoeroo gave me a better list of ciphers which scores even higher with SSLabs:

    ssl_ciphers  ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:ECDH-RSA-AES256-SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:CAMELLIA256-SHA:AES256-SHA;

Continue reading

Playing with TinySSH on FreeBSD and OS X

TinySSH is a new small SSH server using state-of-the-art encryption using the TweetNaCL cryptographic library. It piqued my interest as it claims to be an easily configured and auditable SSH server with new cryptographic primitives and has no dependency on OpenSSL. Its development target is Debian, but since it has limited dependencies it is not hard to get it to run on other systems. This post has some notes on how to get things up and running on a FreeBSD server and an OS X client.

Continue reading