Dit is de gearchiveerde site van het DNSSEC Kennisplatform (2012-2018).
Actuele informatie over DNSSEC vind je op https://sidn.nl/dnssec/.

Installatie trust anchor voor nieuwe root KSK

Op dit moment is ICANN bezig met de roll-over van het KSK-sleutelpaar van de DNS -root. Dat betekent dat ICANN het huidige cryptografische sleutelpaar dat de basis vormt voor de DNSSEC-infrastructuur (KSK-2010) vervangt door een nieuw sleutelpaar (KSK-2017).

• achtergrond
• veel gestelde vragen

Het eerste gedeelte van dit artikel behandelt de verschillende manieren waarop beheerders van validerende resolvers het publieke gedeelte van het nieuwe sleutelpaar als trust anchor op hun systemen kunnen installeren. Het tweede gedeelte richt zich specifiek op de handmatige update van het trust anchor en de automatische installatie via de update-functie van het operating system. De automatische installatie via DNSSEC zelf (op basis van RFC 5011) wordt in een follow-up artikel behandeld, tesamen met een overzicht van de meest gebruikte resolver software-pakketten en hun ondersteuning van deze feature.

Opties

Het hoe en wat voor het installeren van de nieuwe publieke sleutel hangt af van een drietal factoren: de gebruikte DNS-server software, het operating system (OS) of de distributie waarop die software draait, en het moment waarop men het nieuwe trust anchor geïnstalleerd wil hebben. De installatie moet in ieder geval uiterlijk op 11 oktober 2017 voor elkaar zijn. Vanaf die datum kunnen digitale handtekeningen gebaseerd op het oude sleutelpaar niet meer gevalideerd worden. Daarmee worden dan alle Internet-domeinen onbereikbaar voor de gebruikers/applicaties van de betreffende resolver.

Er zijn drie manieren om de nieuwe publieke sleutel als trust anchor geïnstalleerd te krijgen:

1. handmatig (out-of-band):
   De sleutel is inmiddels beschikbaar voor download vanaf de IANA site. Beheerders kunnen deze handmatig als trust anchor in de configuratie van hun resolvers installeren.
2. automatisch via een software-update:
   Ontwikkelaars van DNS-software zullen de nieuwe publieke sleutel als trust anchor opnemen in nieuwe versies van hun pakketten. Hetzelfde geldt voor de DNS-software die met Linux- en andere OS-distributies meegeleverd wordt. In deze gevallen wordt de nieuwe sleutel tesamen met de andere systeem-updates automatisch op de server geïnstalleerd.
3. door middel van een automatische update via RFC 5011 (in-band):
   RFC 5011 maakt het mogelijk om automatisch nieuw sleutelmateriaal op een bestaande validerende resolver te laten installeren. Daarvoor wordt gebruikgemaakt van de bestaande DNSSEC-infrastructuur: De bovenliggende DNS-server maakt de nieuwe sleutel beschikbaar in de vorm van een DNSKEY-record. Door het zetten van de speciale SEP-vlag (Secure Entry Point) weet de resolver dat deze sleutel als trust anchor geïnstalleerd kan worden. De authenticiteit van het nieuwe sleutelmateriaal is gegarandeerd door de digitale handtekening onder het DNSKEY-record, verifieerbaar via het bestaande trust anchor.

Afweging

Hoewel de ontwikkelaars van diverse resolver software-pakketten al hebben aangeven dat die RFC 5011 ondersteunen of gaan ondersteunen, zijn op dit moment alleen de opties 1 en 2 beschikbaar. De nieuwe publieke sleutel is namelijk pas op 11 juli in de root zone gepubliceerd en moet daar uit veiligheidsoverwegingen nog minstens 30 dagen staan voordat deze mag worden overgenomen. In een follow-up artikel zullen we een overzicht van de meest gebruikte resolver software-pakketten geven en hun ondersteuning van RFC 5011. Gebruikers van die pakketten kunnen ervoor kiezen om 10 augustus af te wachten, om vervolgens alleen te testen of het nieuwe trust anchor inderdaad goed geïnstalleerd is.

Gebruikers van andere resolver software moeten de afweging maken of zij willen wachten op een nieuwe versie van hun pakket die RFC 5011 eventueel wel ondersteunt of dat zij het nieuwe trust anchor met de hand installeren. Wij raden aan om in ieder geval een datum vast te stellen waarop men besluit niet langer te wachten op ondersteuning vanuit software of operating system maar de installatie zelf ter hand te nemen.

Handmatige installatie (optie 1)

De handmatige installatie van het nieuwe trust anchor begint met het binnenhalen van de publieke KSK-sleutels van de website van IANA. Naast het XML-bestand met de sleutels zelf (root-anchors.xml) vind je op dezelfde pagina ook een digitale handtekening (root-anchors.p7s) en de certificaten van ICANN (icannbundle.pem). De onderlinge consistentie van dit drietal kun je als volgt verifiëren:

  openssl smime -verify -in ./root-anchors.p7s -inform DER 
      -content ./root-anchors.xml -CAfile ./icannbundle.pem

Voor het tonen van het certificaat gebruik je dit commando (gewoon openen in Firefox werkt ook):

  openssl x509 -text -noout < ./icannbundle.pem

Aangezien alle drie bestanden van dezelfde pagina afkomstig zijn en het betreffende ICANN-certificaat self-signed is, biedt deze check op zichzelf echter geen garanties voor de authenticiteit van het XML-bestand.

Authenticatie

Het vertrouwen in het trust anchor voor de DNSSEC-root is gebaseerd op de brede publicatie ervan door de Internet-autoriteiten: de publieke sleutel is "well known". Als je overal online dezelfde sleutel terugvindt, kun je er steeds beter op vertrouwen dat je daarmee inderdaad de juiste te pakken hebt. Voor de daadwerkelijke ingebruikname van de sleutel als trust anchor is het dus van belang om de authenticiteit ervan via verschillende bronnen vast te stellen.

Voor de authenticiteit van de zojuist binnengehaalde publieke KSK-sleutels kan men in eerste instantie vertrouwen op de HTTPS-verbinding met de website van IANA (helaas ondersteunt deze nog geen DANE). Beter is om voor het downloaden en authenticeren van de sleutels de speciaal hiervoor ontwikkelde 'DNSSEC Trust Anchor Fetcher' te gebruiken. Dit Python-script voert de volgende stappen uit:

1. download het sleutel-bestand van de IANA site via HTTPS
2. download de digitale handtekening van de IANA site via HTTPS
3. valideer de handtekening met behulp van het ingebouwde ICANN-certificaat
4. haal de sleutels uit het XML-bestand
5. controleer de geldigheidsperiode van deze sleutels
6. verifieer dat deze sleutels overeenkomen met de publieke KSK-sleutels van Google Public DNS en die in de root zone zoals gepubliceerd op InterNIC.net
7. bewaar de sleutels in de vorm van DS- en DNSKEY-records

Op deze manier worden de sleutels in het XML-bestand van de IANA site via de digitale handtekening verankerd aan het in het script ingebouwde ICANN-certificaat (en dus aan GitHub via HTTPS), aan Google Public DNS (via DNS-over-HTTPS) en aan de root zone file op InterNIC.net (via HTTPS).

De interne werking van het script (alleen gebaseerd op OpenSSL) is voor elke systeembeheerder goed te volgen en te verifiëren. De locaties van de bestanden op de website van IANA zijn ook gespecificeerd in RFC 7958. En ook de authenticiteit van dit artikel op deze webpagina is verankerd via HTTPS, DNSSEC en DANE. Dat alles bij elkaar moet er voor zorgen dat beheerders, maintainers en ontwikkelaars inderdaad de juiste trust anchors in hun systemen opnemen.

Concreet

Het maken van een lokale kloon van de 'DNSSEC Trust Anchor Fetcher' direct vanaf GitHub kan als volgt:

  git clone https://github.com/iana-org/get-trust-anchor.git

Alternatief is een download in de vorm van een ZIP-bestand:

• https://github.com/iana-org/get-trust-anchor/archive/master.zip

Voor het uitvoeren van het script gebruik je dit commando:

  python get_trust_anchor.py

De output ziet er dan als volgt uit:

  [user@system get-trust-anchor]$ python ./get_trust_anchor.py 
  Validation of the signature over the file succeeded.
  There were 2 KeyDigest elements in the trust anchor file.
  Added the trust anchor 0 to the list:
  {'Algorithm': '8',
   'Digest': '49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5',
   'DigestType': '2',
   'KeyTag': '19036',
   'validFrom': '2010-07-15T00:00:00+00:00',
   'validUntil': ''}
  Added the trust anchor 1 to the list:
  {'Algorithm': '8',
   'Digest': 'E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D',
   'DigestType': '2',
   'KeyTag': '20326',
   'validFrom': '2017-02-02T00:00:00+00:00',
   'validUntil': ''}
  Trust anchor 0: there was no validUntil attribute, so the validity is OK.
  Trust anchor 1: there was no validUntil attribute, so the validity is OK.
  After the date validity checks, there are now 2 records.
  Fetching via Google Public DNS...
  Found KSK 257 3 8 'AwEAAagAIKlVZrp...ulqQxA+Uk1ihz0='.
  Trust anchor 0 matched KSK 'AwEAAagAIKlVZrp...ulqQxA+Uk1ihz0='
  There were 1 matched KSKs.
  Writing out ksk-as-dnskey.txt.
  The key tag for this KSK is 19036
  Writing out ksk-as-ds.txt.
  Deleting the temporary files.

Zoals je kunt zien kon alleen de oude sleutel (KSK-2010) gevalideerd worden via Google Public DNS. De KSK-2017 sleutel was hier nog niet in de root zone opgenomen. Vanaf 11 juli kunnen beide sleutels gevalideerd worden en worden beide weggeschreven naar de bestanden ksk-as-dnskey.txt en ksk-as-ds.txt.

Wie dit script wil opnemen in een geautomatiseerd update-proces moet zich afvragen of de installatie van trust anchors zonder menselijke tussenkomst — of een controle vooraf op zijn minst — wel een goed idee is. Het grootste gevaar is immers niet dat de verkeerde sleutels worden geïnstalleerd — dat merk je snel genoeg — maar dat er een extra trust anchor wordt bijgeplaatst. Doe je de update met de hand, dan weet je dat het er op dit moment precies twee moeten zijn.

Automatische installatie via een software-update (optie 2)

Voor een deel van de validerende resolvers zal de nieuwe publieke root KSK-sleutel al als trust anchor geïnstalleerd zijn als onderdeel van een (automatische) software-update — wellicht zelfs zonder dat de beheerder daar iets van heeft gemerkt. Ook toen de nieuwe sleutel nog niet als DNSKEY-record in de root zone was gepubliceerd, hebben ontwikkelaars van DNS-software en maintainers van OS-distributies deze zelf al vanaf de eerste publicatie in februari in hun systemen kunnen opnemen, op precies dezelfde manier zoals hierboven beschreven.

Hieronder geven we een overzicht van de drie bekendste resolver software-pakketten met hun huidige status (30 juni) voor wat betreft de nieuwe publieke root KSK-sleutel.

BIND named

BIND named, de meeste gebruikte DNS-server, ondersteunt vanaf versie 9.7.0 de 'managed-keys' feature. Deze wordt aangezet middels de (default) configuratie-optie 'dnssec-validation auto'. Daarmee haalt de server bij het opstarten de actuele publieke KSK-sleutels zoals gepubliceerd in de root zone binnen en installeert deze als trust anchors. Hierbij gebruikt de server de trust anchors ingebouwd in de code en gespecificeerd in de 'managed-keys' statements om de managed key database (in managed-keys.bind, of per view) te initialiseren ('initial-key'). De server gebruikt de hard-gecodeerde trust anchors echter alleen als deze niet door een externe 'bindkeys-file' (default: bind.keys) zijn overruled. Omdat named deze initialisatie alleen uitvoert bij de eerste start (als de managed key database nog leeg is), zullen latere updates via RFC 5011 moeten komen.

Trust anchors gespecificeerd in een 'trusted-keys' statement zijn per definitie statisch. Deze configuratie-optie werd geïntroduceerd met de eerste implementatie van DNSSEC-validatie in BIND versie 9.6.2.

Concluderend: Gebruik je BIND versie 9.7 of nieuwer, dan kun je een verouderde configuratie met een 'trusted-keys' statement voor de publieke root KSK-sleutel het beste vervangen door een nieuwere configuratie die gebruikmaakt van de 'managed-keys' feature. Gebruik je nog een installatie gebaseerd op versie 9.6.x, dan zit er niets anders op dan de KSK-2017 sleutel handmatig in de bestaande configuratie toe te voegen.

Unbound

De configuratie-opties van de validerende resolver Unbound voor het specificeren van de trust anchors zijn vergelijkbaar met die van BIND. Tesamen met ondersteuning voor RFC 5011 werd in versie 1.4.0 de 'auto-trust-anchor-file'-optie geïntroduceerd. Die specificeert het bestand dat de managed keys bevat:

  auto-trust-anchor-file: "/etc/unbound/root.key"

Voor de initialisatie daarvan is de 'unbound-anchor' tool beschikbaar:

  unbound-anchor -a "/etc/unbound/root.key"

Deze haalt de publieke root KSK-sleutels binnen, doet dan alle checks zoals aangegeven in RFC 7958, en installeert tenslotte de nieuwe trust anchors in de betreffende file.

De in de code ingebouwde sleutels en ICANN-certificaten fungeren hierbij als basis (hints) voor de bootstrap van het systeem. Vanaf versie 1.6.1 levert Unbound ook het KSK-2017 trust anchor standaard mee als onderdeel van de software. De ingebouwde certificaten kun je overrulen in de file '/etc/unbound/icannbundle.pem'.

Door de 'unbound-anchor'-opdracht op te nemen in het startup script voor Unbound, maak je de initialisatie vergelijkbaar met die van BIND. Verdere updates vinden plaats volgens RFC 5011, waarvoor een paar keer per maand de root zone wordt gecheckt (tracking).

Statische trust anchors kun je specificeren in de 'trust-anchor-file' (default leeg), of in de configuratie zelf middels de 'trust-anchor'-optie.

Resumerend: Gebruikers van Unbound versie 1.4.0 en nieuwer kunnen gebruikmaken van de automatische update via RFC 5011. In oudere installaties moet je de KSK-2017 sleutel handmatig toevoegen als statisch trust anchor.

PowerDNS Recursor

De PowerDNS Recursor ondersteunt DNSSEC-validatie pas vanaf versie 4.0. De ontwikkelaars van deze resolver hebben als uitgangspunt om zo veel mogelijk van de complexiteit voor hun gebruikers (beheerders) te verbergen en te automatiseren. Voor de trust anchors betekent dit dat de publieke root KSK-sleutels hard in de software gecodeerd zijn. Omdat RFC 5011 niet ondersteund wordt, is de beste manier om de KSK-2017 sleutel in de Recursor te krijgen op te waarderen naar versie 4.0.5, waaraan het nieuwe trust anchor is toegevoegd.

Is opwaarderen geen optie, dan kun je de KSK-2017 sleutel via de Lua-interface aan de Recursor laten toevoegen. Het volgende commando laat zien of de Lua-feature inderdaad beschikbaar is:

  pdns_recursor --version

De Lua-opdracht zelf ziet er dan als volgt uit:

  addDS('.', "20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D")

Deze opdracht kun je in de vorm van een scriptje in de startup sequence opnemen.

Om de nieuwe sleutel toe te voegen zonder de resolver te herstarten (zodat de inhoud van de cache niet verloren gaat), kan je dit commando gebruiken:

  rec_control add-ta . 20326 8 2 
      E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

Om te zorgen dat dit trust anchor ook na een herstart van de resolver gebruikt blijft worden, moet je ook in dit geval het Lua-scriptje nog toevoegen.

Met dit commando tenslotte kan je opvragen welke trust anchors op dit moment door de Recursor gebruikt worden:

  rec_control get-tas

Windows DNS Server

Microsoft introduceerde een eerste, beperkte versie van DNSSEC als onderdeel van Windows Server 2008 (DNS Server) en Windows 7 (bevat de DNS client, een stub resolver). Volgens Martin Vliem, de National Security Officer bij Microsoft Nederland, wordt de DNS Server met name gebruikt in een 'split DNS'-configuratie ter facilitering van Active Directory. Voor deze interne zones is DNSSEC sowieso geen optie, omdat deze altijd dynamisch zijn.

Het aantal oude configuraties voorzien van DNSSEC-validatie is volgens Vliem heel beperkt, omdat op zowel de server als de client validatie expliciet aangezet moest worden. Bovendien ondersteunt deze eerste versie van DNS Server alleen SHA-1, dus deze kan de root zone (ondertekend met SHA-2) sowieso niet valideren, alleen SHA1-gebaseerde islands of trust. Daarbij is van belang om te weten dat de DNS Server als extra veiligheidsmaatregel zelf ook valideert als de client daar niet om vraagt.

Vanaf Windows Server 2012 bevat de DNS Server een volledige DNSSEC-implementatie, inclusief ondersteuning van RFC 5011. Alleen beheerders van oudere systemen moeten dus controleren of hun servers DNSSEC wellicht valideren. Is dat het geval, dan moeten zij de nieuwe KSK-2017 sleutel handmatig als trust anchor aan hun systemen toevoegen. Dat kan als DNSKEY-record via de DNS Manager of de Dnscmd.exe tool (in het bestand %windir%System32DNSTrustAnchors.dns). Trust anchors geïnstalleerd op een domain controller worden opgeslagen in de forest directory partition van de Active Directory Domain Services (AD DS) en automatisch naar alle domain controllers in het forest gedistribueerd.

Uitgangspunt

De hierboven beschreven resolver software-pakketten en hun configuratie dienen slechts als uitgangspunt. In de praktijk kan een bestaande installatie er heel anders uitzien, bijvoorbeeld omdat de maintainer van een OS-distributie de KSK-2017 sleutel al als trust anchor aan "zijn" package heeft toegevoegd. Tegelijkertijd bestaat het gevaar dat een installatie wel een nieuwe versie van de resolver software bevat, maar dat deze nog gebruikmaakt van een inmiddels verouderde configuratie. In dat geval kun je het beste de bestaande configuratie opwaarderen naar de huidige software-versie.

De automatische installatie van het nieuwe trust anchor middels RFC 5011 wordt in een follow-up artikel behandeld, net als het testen of alles inderdaad naar behoren functioneert.