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

Ethics and ‘Big Data’ Geospatial Research

On March 3 2016 a paper was published titled “Tagging Banksy: using geographic profiling to investigate a modern art mystery”. The article describes a technique for analysing geospatial aspects of a large data set of artworks to identify the author of the graffiti. The abstract of the article already gives you an idea of where this is heading:

More broadly, these results support previous suggestions that analysis of minor terrorism-related acts (e.g., graffiti) could be used to help locate terrorist bases before more serious incidents occur, and provides a fascinating example of the application of the model to a complex, real-world problem.

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] ‘Slimme’ Meter uitlezen met een USB Bub

Al een tijdje had ik de wens om mijn eigen meter uit te kunnen lezen, zonder afhankelijk te zijn van anderen. Op alle ‘slimme’ meters zit een P1 interface die dat mogelijk maakt. De documentatie die op internet te vinden is, is flink verouderd. De output van de P1 interface is ook wat veranderd, waardoor sommige instellingen niet meer kloppen. Hieronder mijn bevindingen, zodat anderen het ook makkelijk kunnen doen.

Continue reading

On Taxis and Rainbows: Anonymising is not easy

I’ve written a series of blog posts for the Rathenau Institute on ethical issues in data research. In this article I show that proper anonymisation of data is no easy task. This article is a translation of the Dutch original, and is available under CC-BY


In 2013 Chris Whong discovered that the data of all taxi rides in New York City was available based on the FOIL (the Freedom of Information Law). After filling out some forms, providing a large USB flash drive and waiting a few days, he received his flash drive with nearly 20 gigabytes of data. Continue reading

[Dutch] Data verzameling op Smartphones: Big Brother in je broekzak

Ik heb als onderzoeker en docent bij de opleiding System and Network Engineering van de Universiteit van Amsterdam een serie blogs geschreven. In deze serie belicht ik in opdracht van het Rathenau Instituut ethische vraagstukken bij data-onderzoeken. In deze bijdrage ga ik  dieper in op dataverzameling door smartphone apps. Niet alleen de app zelf maar ook het feit of je telefoon op Android of Apple’s iOS draait is van invloed op hoe er met je gegevens wordt omgegaan. Ook gepubliceerd op het Data denkers blog. Deze blogpost is beschikbaar onder CC-BY. Continue reading

Explaining Computer Networks

The Internet is a complicated infrastructure, which is taking over our lives. Users should have some understanding of how this works, so that they better understand regulation or commercial impact of (new) measures. Most articles trying to explain the Internet make things very complex, and they don’t need to. There are only two concepts that you need to know to understand networking: layers and adaptations. Once you understand these concepts, you can fit them together to form a full networking stack. This explains how we do networking on the Internet, but also on other current, and future networks.

Continue reading

[Dutch] Tracking op basis van publieke data

Ik heb als onderzoeker en docent bij de opleiding System and Network Engineering van de Universiteit van Amsterdam een serie blogs geschreven. In deze serie belicht ik in opdracht van het Rathenau Instituut ethische vraagstukken bij data-onderzoeken. In deze bijdrage beschrijf ik hoe openbare data van een dienst zoals Twitter op meer manieren kan worden hergebruikt dan gebruikers veelal voorzien.  Ook gepubliceerd op het Data denkers blog. Deze blogpost is beschikbaar onder CC-BY.

Continue reading