Errata, new releases and other stuff will get a place there.

For good measure I even added a "Donate" button - we'll see how to that plays out.

The all deal with DNSSEC - note that most of them have been written a few years ago.

The article

• PulseAudio, never got that working btw, went back to ALSA.
• Tracker, what the hell was ever wrong with locate? Never got that working, and when I did, it was dog slow.
• I should be using evolution for emailing... no thanks! I'm a happy mutt user.
• There is no support for VI-key bindings in GTK... (which is not gnome's fault, but irritating none the less)

So I purged GNOME from my system and started using Xmonad, a tiling window manager. I'm still using GTK applications, because most of them still rule. But I'm happy that I'm leaving this whole GNOME business behind.

(DNSSEC, what is it? Does it ever happen?)

the pdf of the presentation

At the time I was employed at NLnet Labs

This RFC gives guidelines on how to setup secure zones in a world with DNSSEC. It also gives pointers for public and private key handling and deals with the key lengths and how to handle key rollovers.

older publication: 2001

Door

R. Gieben, miek@nlnetlabs.nl or miek@miek.nl

Voorwoord

In dit introductie artikel behandel ik DNSSEC en de beloftes en problemen die het met zich mee brengt. Daarbij wil ik uit leggen wat de bijdrage van NLnet Labs is geweest in het analyseren en oplossen van enkele van die problemen. Verder ga ik in op de plannen voor de uitrol van DNSSEC in Nederland in de nabije toekomst.

NLnet Labs is opgericht door Stichting NLnet om nieuwe protocollen en applicaties te promoten en te ontwikkelen voor het Internet. Er is een budget voor 15 jaar ontwikkeling door 6 developers.

DNSSEC

In de eerste dagen van het Internet was het een plek waar voornamelijk ontwikkelaars vanuit de wetenschap en het bedrijfsleven in een vriendschappelijke omgeven met elkaar konden communiceren. Het werd gebruikt als een medium om ideeen en informatie uit te wisselen. Beveiliging was hier geen issue. Vandaag de dag nu het Internet miljoenen gebruiker herbergt, zijn de risico's groter geworden. De risico's varieren van ongewenst tot ronduit gevaarlijk: van spam (grootschalig verspreiden van ongevraagde reclame) via virusssen en denial of service attacks, tot fraude met creditcard nummers. In al deze zaken speelt het ontbreken van een waterdichte indentificatie en authenticatie een hoofdrol.

Een van de systemen die goed werken in een vriendelijke omgeving, maar tegenwoordig kwetsbaar blijken te zijn, is het domain name system (DNS). De belangrijkste taak van het DNS is het verzorgen van een conversie tussen een domein name (bijvoorbeeld www.example.com) en een IP nummer (bijvoorbeeld 192.168.1.1). Mede dankzij de schaalbaarheid van het DNS is het Internet zo snel, zo groot geworden.

Echter, door het ontbreken van beveiliging kan men in een onvriendelijke omgeving de DNS informatie manipuleren en daarmee zowel de eigen identiteit verhullen als anderen de verkeerde kant op sturen. Dankzij het eerste kan men ongestraft SPAM en virussen verspreiden, het tweede vormt een directe bedreiging voor ieder vorm van e-commerce.

Als snel na de invoering van DNS realiseerde men zich deze kwetsbaarheid van het DNS (1990: Steven M. Belovin [2]). Het rapport daarover is vervolgens 5 jaar geheim gehouden uit angst voor grootschalige verlammingen van het toenmalige Internet. Ook was de groei van het Internet dusdanig dat niemand tijd had om na te denken over beveiliging. Alle prioriteit werd gegeven aan het draaiende houden van het systeem en aan het werk om de groei op te vangen (met groei percentages van 20 to 30% per maand geen sinecure). Pas in 1995 is er, om iets aan de problemen te doen, een extensie voor DNS voorgesteld: het secure domain name system (DNSSEC). DNSSEC gebruikt digitale handtekeningen (signatures) om antwoorden te authenticeren en misbruik te detecteren. Als een signature niet klopt, wordt de informatie die hierbij hoort weggegooid. Zodoende zorgt DNSSEC ervoor dat bovengenoemde security issues worden opgelost, maar het introduceert tegelijkertijd weer nieuwe problemen, DNSSEC

• is CPU intensie
• zorgt voor toename in de grootte van zonefiles (met een factor 3-5)
• zorgt voor toename van de communicatie tussen registries en registrars (zogenaamde "key management")

CPU intensief

NLnet Labs heeft onderzoek gedaan naar de deployment van DNSSEC. Hoewel DNSSEC een veel CPU intensiever is dan DNS zal dit waarschijnlijk niet veel problemen op gaan leveren. Computers worden immers steeds sneller en de thuisgebruiker hoeft alleen digitale handtekeningen te valideren (iets dat minder moeite kost dan het creeren van digitale handtekeningen). De zonefiles worden van te voren voorzien van hun signatures. Zoals bijvoorbeeld de .nl zone, bestaande uit 600.000 domeinen. Als heel .nl DNSSEC zou gebruiken zouden er 600.000 publieke sleutels (public keys) moeten worden gemaakt, alsmede de 600.000 bijbehorende signatures. Dit proces is vrij intensief, maar NLnet Labs heeft aangetoond dat dit voor de meeste zones op het Internet haalbaar is. Zelf .com (met 30 miljoen domeinen veruit de grootste zones van het Internet) heeft laten zien dat het signen van hun zone haalbaar is.

Zeer grote zonefiles

Ten gevolge van DNSSEC worden zonefiles groter, een factor 3 tot 5. Hele grote zonefiles zouden hierdoor tot onhandelbare proporties kunnen groeien. Bijkomend probleem is dat een DNSSEC zonefile gesorteerd moet worden, wat ook weer tot onoplosbare computercapaciteits problemen zou kunnen leiden. Maar, ook hier is vastgesteld dat dit zelfs voor de allergrootste zones met de hedendaagse (64-bit) systemen opgelost kan worden. DNSSEC zones zullen bovendien regelmatig van hernieuwde signatures moeten worden voorzien, aangezien deze signatures een gelimiteerde levensduur hebben. Dit zogenaamde resignen blijkt te kunnen in 5% van de originele signtijd en zal naar verwachting dus veel minder problemen opleveren. Het is met de standaard tools, op een desktop PC al mogelijk om de .nl zone twee keer per dag te resignen.

Key management

Een derde en minder eenvoudig oplosbaar probleem van DNSSEC is het key management. Hieronder vallen private key procedures en de procedures die beschrijven hoe public keys met de registry uitgewisseld dienen te worden. Zoals met alle public/private key crypto systemen is het van het uiterste belang, dat een private key geheim blijft. Aan de andere kant moet een private key ook beschikbaar zijn om signatures te creeeren. Deze situatie zorgt voor een spanningsveld waarvoor nog geen adequate oplossing is gevonden.

Verder bestaat key management ook uit procedures die vastleggen hoe een public key gesignd moet worden door de registry. Om duidelijk te maken waarom dat een moeilijk probleem is zal ik eerst wat dieper ingaan op de structuur van DNSSEC.

In DNS (en dus ook in DNSSEC) bestaat er een parent/child relatie tussen domeinen (zie Figuur 1); simpel gezegd is .nl de parent van ieder .nl domain (bijvoorbeeld miek.nl). En miek.nl is dan een child van .nl. Ook .nl is zelf weer een child en wel van '.' (root). In DNSSEC creeert elke zone een eigen public key, de zogenaamde zone signing key. Met deze zone signing key worden de signatures gemaakt over alle informatie van die zone. Dus wordt alle informatie in die zone beschermd door deze zone key (zie ook Figuur 2).

Natuurlijk moet ook die zone signing key zelf weer beveiligd zijn. Dit wordt normaliter in DNSSEC gedaan door de parent deze key te laten signeren. (er zijn ook andere methoden, zoals bv het in de Staats Courant publiceren en vervolgens hard configureren van de public key bij de resolver).

De zone key van miek.nl wordt dus gesignd door de zone key van .nl. Om alle DNSSEC zones van .nl te verifieren is slecht de zone key van .nl nodig. Wanneer deze zone key nu buiten het DNS om en op een veilige manier bij de thuisgebruiker kan worden afgeleverd, zal men instaat zijn een secure view te hebben op .nl.

In het ideale geval zal men de public key van de "root" zone thuis hebben en is er een secure view op het gehele Internet mogelijk. Na de invoer van DNSSEC signt "root" de zone key van .nl en .nl signt op haar beurt de public key van miek.nl. Dit process heet de "chain of trust" en kan gezien worden het grote voordeel van DNSSEC: 1 zone key is genoeg om alle signatures te kunnen verfivieren.

In de originele DNSSEC specificatie (RFC 2535 [4]) waren er 4 stappen nodig om de public key van een child bij de parent te krijgen (Figuur 3). Dit leverde te veel interactie op tussen de parent en child. De hoeveelheid administratie die nodig is om dit op een veilige manier te doen is ongekend en zal voor vrijwel alle TLDs (Top Level Domain, hieronder vallen .com, .org, .net, .etc.) tot onoverkomenlijke problemen leiden. NLnet Labs heeft heeft een voorstel gedaan om de key interactie efficienter te laten verlopen. Alleen bleek dit vast te lopen op bepaalde details in het DNS. Een van die details was dat er signatures ontstonden die er weliswaar identiek uitzagen, maar verschillende semantische betekenissen hadden. Later is dit voorstel in een andere vorm opnieuw ter stemming gebracht. Dit zogenaamde Delegation Signer (DS) model van Olufar Gudmanson heeft de goede punten van het NLnet Labs proposal in zich, maar omzeilt de problemen (Zie figuur 4). Deze DS draft is nu in last call bij de IETF en zal heel waarschijnlijk binnenkort geaccepteerd worden als een RFC. Dankzij DS zal het administratief mogelijk worden om DNSSEC uit te rollen in grote zones.

DNSSEC in .nl (.nl.nl experiment)

Uiteindelijk heeft het tot 2000 geduurd voordat de tools die DNSSEC protocol implementeren beschikbaar kwamen. En ook nu moet er weer gewacht worden voordat de tools die DS aankunnen klaar zijn. Ondertussen is NLnet Labs bezig met het opzetten van een schaduw registry voor DNSSEC in .nl [5]. In deze registry kunnen .nl domein houders hun domein laten registeren om deze secure te laten maken. De opzet is van dien aard dat er straks naast de DNS-view op .nl er ook een (secure) DNSSEC-view bestaat. Het is de bedoeling dat deze registry eind juni geheel operationeel zal zijn. (Mits de DNSSEC+DS software tijdig beschikbaar komt (1)). Het eerdere .nl.nl experiment waar al secure .nl.nl domeinen konden worden geregistreerd wordt dan afgesloten. Dankzij dit .nl.nl experiment is overigens duidelijk geworden dat DNSSEC RFC2535-style nooit gerealiseerd zou kunnen worden op TLD niveau: de communicatie overhead was gewoon te groot.

In de loop van 2002 zal duidelijk worden of dit schaduw experiment een succes wordt. Mocht dit zo zijn dan is de verwachting dat het SIDN (de officiële .nl registry) niet al te lange tijd daarna DNSSEC gaat aanbieden in .nl. Nederland zou met deze registry het eerste land ter wereld zijn die DNSSEC aan het invoeren is. Wanneer DNSSEC wordt uitgerold, zal het een infrastructuur bieden waarin allerlei cryptografisch materiaal kan worden gepubliceerd. Dit biedt ongekende mogelijkheden voor IPsec, PGP en elke andere service die cryptografie gebruikt en zal hopelijk het begin zijn van een veiliger Internet.

Voetnoten

• Dit hangt af van (administratieve) procedures in het Department of Justice en/of het Pentagon. De software is af, er moet alleen nog maar een handtekening gezet worden om de betaling goed te keuren.

published in 2003

DNSSEC mini HOWTO

By Paul Wouters (paul@xtdnet.nl)

Introduction

This article is a translation of the article "Secure DNS, Het beveiligingen van DNS in de praktijk that appeared in C'T magazine on March 14 2003.

DNSSEC in the .nl zone

The Dutch NIC (SIDN [http://www.domain-registry.nl/]>), The European Regional Internet Registry (RIPE), and NLnetLabs have created the first toplevel secure DNS. The experiment is running its own set of nameservers to guarantee that the experiment will not interfere with the production nameservers. The project started in November of 2002 with the goal of gaining experience in running DNSSEC for a TLD Registry.

For years, the IETF has been (re)designing the successor of the current DNS system. The new protocols have been changed so often, people began to wonder if it would ever happen at all. One would think that the DNS would have been one of the first protocols to be thoroughly secured. After all, practically all communication on the internet relies on the DNS. A malicious user only needs to manipulate the DNS to get control of the communication.

The standard DNS zonefile of the domain "ct.nl", with the standard "start of authority" (SOA), nameserver (NS), mail (MX), address (A) and alias (CNAME) resource records (RR's).

Digital Signature

Standard DNS queries and answers are easily faked. If third parties can observe the DNS traffic of any machine between the enduser and the DNS server that person is using, data can be easily manipulated. DNSSEC solves this problem by using digital signatures for all records. A key-pair is generated, of which the public key is put in the DNS itself, in the form of a KEY record. The private key is then used to digitally sign all records, including the public key record. These signatures are placed in the SIG records. A malicious user can still modify the DNS data, but without the private key, the the corresponding SIG records cannot be recreated to validate the changed records. The tampering will be noticed, and the spoofed DNS answers not believed. The beauty of this setup is that the entire zone can be signed on a very secure machine and then copied onto the nameserver. Even if one has full control of the nameserver, one cannot change any DNS record without breaking the SIG record. An attacker can ofcourse still destroy the nameserver, but at least no one will be tricked to connect to an attacker's malicious network, even after a nameserver compromise.

The ct.nl zonefile, secured with DNSSEC records. (KEY material shortened for readability).

DNSSEC has another new record type, the NXT record. This record gives us the opportunity to deny the existence of a certain RR. It is not enough to just not have a certain record to make it clear the requested RR doesn't exist. We have to proof this somehow.

The NXT record for ct.nl shows the existence of the NS, SOA, MX, SIG, KEY and NXT record types. It also tells us that the next RR, in alphabetical order, is going to be www.ct.nl. The NXT record of www.ct.nl shows that there is only a CNAME, SIG and NXT record. And since its NXT record points back to ct.nl, we know it is the last name in the chain. There is no zzz.ct.nl. And all this information was digitally signed. This is the essence of DNSSEC.

But we have a few wrinkles to iron out. The DNS is a hierarchical system. The zone above our zone, the parent zone, has some information about our zone. The nameserver of the parent zone contains nameserver (NS) records to point to the responsible nameservers of its child zones. And if the nameservers of the child zone themselves have names within their own zone (for example when ns.ct.nl is an NS record for ct.nl), then it also needs to pass that information to pass along as well ; the so-called glue records. If someone manages to manipulate those records in our parent zone, then it doesn't matter how secure our own server is. They will never reach our super-secure nameserver. So this information needs to be signed as well. But our parent doesn't have our private key, so it cannot sign those records on our behalf. Somehow, we will need to give our parent some information about our key, without turning it over.

The Hint

Of course this problem isn't new to DNS. The .nl nameserver (ns.nic.nl) already has NS records for our ct.nl zone. In our case these point to ns.xtdnet.nl. However, this answer is given without setting the so-called "authoritative answer" flag. The information is provided "as is". If we would ask the same question to ns.xtdnet.nl, it would yield the same answer, but this time the "authoritative answer" flag will be set. If ns.xtdnet.nl would give different answer, we would call this a "lame server". But for DNSSEC, this hint is not enough. After all, anyone can just claim to be an authoritative server. That is why DNSSEC gives a cryptographic hint, the Delegation Signer(DS) record.

The DS record contains the id and the hash of the KEY record of the child-zone. The DS record itself is signed by the parent-zone with a SIG record. To find the ct.nl zone we ask the .nl nameserver for both the NS and DS records. We receive a hint (NS) to use ns.xtdnet.nl as nameserver and a hash of the key (DS) that as far as .nl knows, should have signed the entire ct.nl zone. Then we go to ns.xtdnet.nl and ask for the KEY record of ct.nl. We receive the KEY record, and the signature that belongs to it. We hash the KEY and compare it with the hash in the DS record we received from the .nl nameserver. If they match, we have securely landed at the authoritative nameserver for ct.nl. and we can proceed to ask it about the ct.nl domain. All the answers of ns.xtdnet.nl will be digitally signed, and cannot be tampered with.

Securely resolving www.ct.nl, using the resolv tool made by Miek Gieben.

KEY roll-overs

However, with enough time and cpu-power, all crypto can be broken eventually. That is why it is very important to change your KEY's regularly. But we cannot just change the key, because then our parent's DS record will be wrong. So how do we renew our KEY's without constantly bugging the parent to update the DS record?

The trick is to use two KEY records in our zone, a zone-signing key (ZSK) and a key-signing key (KSK). We sign all KEY records with the KSK, then sign the entire zone with the ZSK. The KSK is the key for which our parent publishes the DS record. The zone-signing key (ZSK) can be relatively small (for instance 768 bits) if we recycle it every month. We can keep the KSK for a year if we make it a bit stronger, for example 2048 bit.

So we get the following path of trust: We trust the KEY of .nl, and thus we trust the NS and DS that ns.nic.nl serves us which, when used, ends us at ns.xtdnet.nl. We verify its KSK with the DS we got, so we trust the KSK which has signed the ZSK, which has signed all the data (RR's) of which we wanted to know the signed A record www.ct.nl. And we can now recycle the ZSK without notifying the parent. Though of course we just postponed our problem. We still need to recycle the KSK after a year, and we need to securely inform our parent about the new KSK.

To start a roll-over of the KSK we first create another KSK (let's call it KSK2) and add this third KEY to the zone. Then we can inform the parent (even insecurely!) that there is a new KSK. The parent checks whether its existing KSK (for which it has a DS to verify) has signed the new KSK2. If so, it will update its DS record to point to KSK2. Once we are sure that no cached copies of KSK are scattered around the world, we can remove KSK from our zone. For .nl, NLnetlabs has created such a procedure, SECREG (Secure registration).

From DNS to DNSSEC

Our last problem is that the world will not switch in a single moment from DNS to DNSSEC. So while some subtrees, such as .nl, might have switched, others, most notable the root zone (".") itself, might still be insecure. The resolve this issue, it is possible to define "secure islands" within a insecure tree. You can define a 'trusted key' for a particular tree. This is exactly what SIDN has done for .nl

We will now describe how to secure a .nl domain using DNSSEC and SECREG. Obviously, the SECREG part only applies to .nl domains, but you can still read the procedures involved in making any zone secure.

DNSSEC is still a fast moving target. The only software that can be used to create signed zones at this time is the latest snapshot of bind9.

In that snapshot, threading is broken, so you will need to disable that with --disable-threads. Zones signed with the snapshot can however be served by any recent nameserver software package, such as the stable versions of bind8 and bind9 or nsd. The only caveat is when using bind8. If you setup a secure zone, with signatures that are valid for a month, and you forget about your expeirment and let those signatures expire, bind8 will remove the record from the zone. Bind9 will keep serving the expired record, and leave it up to the resolvers querying it to determine whether or not to pass the expired record on to the application.

To not jeopardize the regular operations of the .nl zone, two separate DNSSEC aware CC:TLD nameservers, "bakbeest.sidnl.nl" and "alpha.nlnetlabs.nl" are used. If you want to test secure resolving, be sure to use those two servers instead of the official .nl nameservers. Of course you can also use tools such as dig or resolv.pl manually. If you wish to create your own secure recursing nameserver, you need to run the latest bind9 snapshot and add a trusted-key statement for the .nl key in named.conf:

trusted-keys {
"nl." 256 3 1
"AQOtBQXOH5L/wmOt01PuxXAfSk1bw/dneWPoCyl4yi8tLCjz+DkAs0mzAAvd9XUNpYDaf5KT
ciSs9254oeiE0s0FuYbxS4nm7veZSPCgWoHULFNJtKPNeb4EEblNkAsEGagwQJoIrjlAYKx4C
En3hPwElUlVko23I5tSSPPssxrVnQ==";
};

(The above should be on a single line)

Be aware that using bind9 snapshots will often kill some of the functionality of your nameserver. Do not run this on production servers, unless you know what you're doing and have extensive monitoring enabled. Even though the development is focused on dnssec, some snapshots also broke normal resolving, so be careful. The next step is to install Net::DNS::SEC from CPAN. Some of the perl scripts we use later on depend on it. Olaf Kolkman of RIPE NCC has written a management-tool that uses it extensively. Such a tool is vital once you start securing many zones. So after we have installed all our software, we're ready to secure our domain, fnl.nl. Ideally, this would be the time to remove the signing machine from the network, and only connect it to upload the signed zones to the primary nameserver. Other methods would be even better, such as transferring the zones with a USB pen-drive. The security setup of the signer machine is left as exercise for the reader.

We will start by creating the KSK and ZSK:

$ dnssec-keygen -a RSASHA1 -b 2048 -n ZONE fnl.nl
Kfnl.nl.+005+16217
$ nssec-keygen -a RSASHA1 -b 768 -n ZONE fnl.nl
Kfnl.nl.+005+25541

The private keys are in the files with extension .private. The public keys are in the files with extension .key. If you are creating a large amount of keys, you might need to use "-r /dev/urandom". This random source is slightly less secure, but will not block while you're waiting for new randomness to appear. It seems that, with Linux at least, the quickest way of getting more random is to move the mouse. Once we're done with the key-pair creation, we add the KEY records to the zonefile:

$ cat *key >> /var/named/fnl.nl

And after we've increased the zone's serial number, we're ready to sign the zone:

$ dnssec-signzone -o fnl.nl -k Kfnl.nl.+005+16217.key /var/named/fnl.nl Kfnl.nl.+005+25541.key

We can then copy the zonefile to our primary nameserver and reload the zone:

# rndc reload fnl.nl

(If you use RedHat, you can also use 'service named restart')

After a few minutes, your secondary nameservers should also have loaded the new zone. We will use the dig command to verify this. We recommend that people who are used to using the nslookup or the host command really break that habit by now. If you preferred the output of host or nslookup over the output of dig, you can now use the +multiline option to dig (which you can even put in a .digrc file) to get output that is very similar to nslookup or host. To verify if our secondary server received the new zone, we query a key record:

$ dig +dnssec +multiline -t key fnl.nl @ns.xtdnet.nl

We should receive an answer that contains both a KEY and a SIG record. Also take a close look at the "flags" section of the dig output. The Authoritative Answer (aa) flag will say whether or not the nameserver itself was responsible for the zone (authoritative). The Authenticated Data (ad) flag tells us whether our answer was verifiably secure using the dnssec extensions. The above query, contrary to what you might except, did not set the "ad" flag. The reason for this is that the verification of data is done by a resolver, and not by the authoritative server itself. It wouldn't make much sense to verify the zone on your own disk.

Creating the DS record

When we have our secure zones loaded on our nameservers, we can ask SECREG to vouch for our domainname and request it adds a signed DS record to the .nl zone. We can request this through email (for bulk registrations) or use the web-interface:

Selecting the correct KEY for SECREG.

At this point there is no way that SECREG can determine which key is your ZSK and which is your KSK, though a draft to make a distinction is on its way. If you used a different key-size when generating the keys, you can tell the keys apart by their size. If you used an equal size, you'll have to check your key id, which is apparent from the filename it uses. Once you've told SECREG which key is the KSK, the zone will appear as "processing".

Registrant and Registrar have two days to cancel the SECREG request.

SECREG decided to add a two day waiting period so that any involved party (Registrant or Registrar) has a chance to decline the request. This is an experimental policy, that might develope into a Best Current Practice ("BCP"). If no one declines the request, your zone will be added to SECREG. The .nl zone is refreshed every weekday between 7am and 11am. This 40 MByte file is then signed by the signing machine, currently a Pentium-III 1Ghz. This process takes about two hours, and when it is done, the file size has grown to 300 Mbyte. SECREG will send emails to the parties involved if it has successfully added a zone, which means adding and signing the DS record for your zone.

The "ad" flag is set. Dig has successfully found the address of our website using DNSSEC.

KSK roll-over

The KSK and ZSK do not have an expire date - only SIG records expire. The ZSK roll-over can be done whenever you want, since the KSK will just sign whatever ZSK you have. So this rollover just consists of deleting the old key, generating a new one, and updating the KEY record in the zone.

The KSK rollover needs to happen in a co-ordinated fashion with the parent, so that the DS record can be updated. First, one needs to create a new KSK:

$ dnssec-keygen -a RSASHA1 -b 2048 -n ZONE fnl.nl
Kfnl.nl.+005+16310

The public KEY record needs to be added to the zone. Assuming the zonefile lives in /var/named/fnl.nl, issue:

$ cat Kfnl.nl.+005+16310.key >> /var/named/fnl.nl

And after we increased the serial, both KSK's need to sign the KEY records and the ZSK needs to sign the entire zone:

$ dnssec-signzone -o fnl.nl -k Kfnl.nl.+005+16217 -k Kfnl.nl.+005+16310
 /var/named/fnl.nl Kfnl.nl.+005+25541

Then we need to propagate the new zone to the primary and secondary nameservers. Then we go back to the SECREG website and choose "rollover". It will present us with a TXT record containing a random challenge string. This needs to be signed using the sign.pl tool linked on that page, using the OLD KSK.

$ sign.pl
What is the full path to your private key? []
Kfnl.nl.+005+16217.private
What is your domain? []
fnl.nl
Record to sign: []
3600 IN TXT "random txt m80fN0LtmpXz2aQ"

Key path       : Kfnl.nl.+005+35861.private
Domain name    : fnl.nl
Record to sign : 3600 IN TXT "random txt m80fN0LtmpXz2aQ"

Is this correct (y/n)? y

fnl.nl.  3600    IN SIG TXT  5  2  3600  20030315125047 (
            20030213125047 35861  fnl.nl
            KHR718ehTtidLkTUbnf+NPPJymSo2jwrWTkPOvjKySFTe
            v6tRoCPkvQ2pZxnn7aR3hOCrMAWmwa7WCUJ4GzdPJD2fx
            M0zYkH722ewhVmayyZTTgGQ81cpVmbag/95/OR )

Using the sign.pl tool and our old KSK, we have signed the random TXT record as proof that are allowed to do a KSK roll-over.

If the signature is correct, SECREG knows we are the holder of the old KSK key, and that we are authorized to perform a key roll-over. SECREG will update the DS record, which will be published when the .nl zone gets reloaded. Our roll-over is complete.

The old KSK might still be in various caches on the net, so you should at least keep it for as long as its TTL was. Only when that time has past, can the old KSK be removed from the zone. Olaf Kolkman's maintenance tool does an excellent job of managing these roll-overs.

Conclusion

The Netherlands is the first TLD with a functional DNSSEC registry. One cannot expect to find many programs that already use the extra functionality that DNSSEC offers. Because of the many changes, even very recently, of the DNSSEC protocol, this hasn't really been possible so far. DNSSEC extensions are also missing from the POSIX libraries, such as the C-library, which means that every program which wants to support DNSSEC needs to write their own dns functions. The first applications to adopt DNSSEC will likely be FreeS/WAN, the most widely deployed Linux IPsec implementation, and OpenSSH. Both tools use public key cryptography, and need to fetch and verify their own application keys. These keys can be put into the DNS, but one can only rely on it if the DNS itself is secure. And the entire situation can become quite complex, as soon as DNSSEC finds it way into DHCP client updates, dynamic dns updates or IPsec opportunistic encryption. And hopefully browsers will also soon understand DNSSEC, so that online banking can implement real DNS security, instead of advising the user "to only continue when the name of our bank appears in the address bar". We have been waiting for DNSSEC for years. Let's hope the Dutch SECREG experiment gives everyone a push in the right direction.

Copyright (c) 2003

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

This is an older publication (from 2004).

This report gives an outline of the current status of SECREG, the Dutch experiment for introducing DNSSEC in NL.

It is written for SIDN (the people who take care of .nl) and it tries to explain what DNSSEC will mean for a registry.

Downloads are here:

• DNSSEC in NL Postscript
• DNSSEC in NL pdf

For future reference. My master's thesis can be found here. It details the development of the DNSSEC protocol, a supposed successor of the DNS on the Internet.

It was officially publiced as a research document by my university (University of Nijmegen).

You can find the thesis (pdf|ps) here:
CSI-report.pdf.
CSI-report.ps.