Nog vier weken tot de root KSK roll-over: check je DNSSEC trust anchors!
Validerende resolvers die RFC 5011 ondersteunen zouden inmiddels de nieuwe publieke root KSK-sleutel als trust anchor geïnstalleerd en geactiveerd moeten hebben. Gebruik je nog software die RFC 5011 niet ondersteunt en je hebt het nieuwe trust anchor nog niet handmatig geïnstalleerd, dan wordt het de hoogste tijd om dat alsnog te doen. Vanaf 11 oktober zijn namelijk alle internetdomeinen onbereikbaar voor gebruikers van resolvers die niet van het nieuwe trust anchor zijn voorzien.
In dit artikel laten we zien hoe je de beschikbaarheid van het nieuwe trust anchor kunt controleren.
Geautomatiseerde testomgeving
ICANN heeft een geautomatiseerde testomgeving opgezet waarmee operators van validerende resolvers de correcte werking van het RFC 5011 update-mechanisme op hun systemen kunnen controleren. Daarvoor moeten zij eerst handmatig een trust anchor voor een speciaal subdomein installeren. De publieke KSK-sleutel voor dit domein wordt vervolgens gerold, zodat de hele update-cyclus doorlopen wordt. Voor de details van het update-mechanisme verwijzen we naar het eerdere artikel over RFC 5011.
Elke week start er een nieuwe testcyclus op een nieuw domein. Deelnemers kunnen zich aanmelden op een mailing list die precies uitlegt wat voor het betreffende domein de huidige status is en hoe je kunt controleren of alles naar behoren verloopt.
Beperkt testen
Je kunt de ICANN testomgeving alleen gebruiken om de werking van het RFC 5011 update-mechanisme in het algemeen te controleren, niet specifiek voor het testen van de aanwezigheid en goede werking van het KSK-2017 trust anchor. Of zoals ICANN het zelf formuleert in zijn '2017 KSK Rollover External Test Plan': It allows operators of validating resolvers to test whether their systems are likely to work during the KSK rollover if they are using RFC 5011.
.
Op dit moment — vier weken voor de feitelijke roll-over — is het echter van cruciaal belang om specifiek te verifiëren dat de publieke KSK-2017 sleutel inderdaad als trust anchor in de resolver aanwezig is. Een Domeinnaam daadwerkelijk valideren tegen de nieuwe root KSK is echter nog niet mogelijk. Om de UDP-pakketgrootte beperkt te houden, en op die manier fragmentatie van de netwerkpakketten te voorkomen, is in het ontwerp van de roll-over gekozen voor enkelvoudige ondertekening. Dat betekent dat tot de feitelijke roll-over op 11 oktober de root ZSK niet met de nieuwe KSK ondertekend is en er nog geen enkele chain of trust over KSK-2017 kan worden opgebouwd.
Check trust anchors
Veel belangrijker dan de goede werking van het RFC 5011 update-mechanisme (een middel) is de aanwezigheid van het KSK-2017 trust anchor (het doel). Hieronder laten we voor de meest gebruikte resolvers zien hoe de actuele trust anchors getoond kunnen worden.
Maar het is verstandig om eerst te controleren of de betreffende resolver überhaupt valideert. Dat kan met dit commando (vervang <ADRES> door de naam of het adres van de server):
dig @ADRES dnssec-failed.org a +dnssec
Voor een validerende resolver moet deze opdracht de status SERVFAIL opleveren; zoals de domeinnaam al aangeeft is de DNSSEC chain of trust expres niet gesloten (bogus). Een niet-validerende server controleert de aanwezigheid van digitale handtekeningen überhaupt niet en zal de status NOERROR teruggeven.
BIND named
BIND named, de meeste gebruikte DNS -server, slaat zijn trust anchors (vanaf versie 9.7.0) op in de managed key database (in het bestand managed-keys.bind, of per view vanaf versie 9.8.0). De inhoud daarvan kun je opvragen met het volgende commando (vanaf versie 9.11.0):
rndc managed-keys status
Voor oudere versies levert het script contrib/scripts/check5011.pl vergelijkbare functionaliteit.
Zie je het KSK-2017 trust anchor met keyid 20326 er niet tussen staan (met de status 'trusted'), dan vind je hier uitgebreide informatie over de root KSK roll-over van ISC, de ontwikkelaar van BIND named.
Unbound
De validerende resolver Unbound slaat zijn trust anchors op in de 'auto-trust-anchor-file' (/etc/unbound/root.key). Daar moet ook het KSK-2017 trust anchor met keyid 20326 tussen staan (met de status 2/VALID).
PowerDNS Recursor
De ontwikkelaars van de PowerDNS Recursor 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. Vanaf versie 4.0.5 is dat ook voor de KSK-2017 sleutel (met keyid 20326) het geval. Voor oudere versies kun je het nieuwe trust anchor toevoegen via de Lua-interface of het 'rec_control add-ta' commando.
Met dit commando kun je opvragen welke trust anchors de Recursor op dit moment gebruikt:
rec_control get-tas
Knot DNS Resolver
De trust anchors van de Knot DNS Resolver worden bewaard in de 'trust_anchors.file' (root.keys). Dit bestand moet de volgende twee sleutel-strings bevatten:
0101030803010001A80020A95566BA42E886BB804CDA84E47EF56DB 0101030803010001ACFFB409BCC939F831F7A1E5EC88F7A59255EC5
Dnsmasq
De Dnsmasq server laadt zijn trust anchors uit het bestand trust-anchors.conf. Vanaf versie 2.77 wordt op deze manier ook het nieuwe KSK-2017 trust anchor met de software meegeleverd. Versies ouder dan 2.76 moeten volgens ontwikkelaar Simon Kelley sowieso niet meer gebruikt worden vanwege bugs in het validatie-gedeelte.
(zie de CHANGELOG voor versie 2.69 voor de implementatie van DNSSEC-validatie in Dnsmasq)
Infoblox
Alle Infoblox appliances vereisen de handmatige installatie van het nieuwe KSK-2017 trust anchor. Infoblox Nederland geeft aan zijn klanten hierover actief te informeren.
Windows DNS Server
Op het Windows-platform is DNSSEC pas volledig geïmplementeerd vanaf Windows Server 2012. De trust anchors voor de Windows DNS Server worden bewaard in het bestand %windir%System32DNSTrustAnchors.dns.
De huidige trust anchors kan je in de PowerShell opvragen met het volgende commando:
Get-DnsServerTrustAnchor -Name .
De TrustAnchorData moet ook de nieuwe sleutel met keyid 20326 (en TrustAnchorState Valid) bevatten.
Probleemloze roll-over
De geverifieerde beschikbaarheid van een actief KSK-2017 trust anchor biedt operators van validerende resolvers de grootste kans op een probleemloze roll-over op 11 oktober. Het succesvol uitvoeren van de hierboven beschreven checks is daarom van cruciaal belang. Zoals eerder uitgelegd is er vooraf geen enkele mogelijkheid om een domeinnaam daadwerkelijk tegen de nieuwe root KSK te valideren. Dat maakt deze checks zowel het minimale als het maximale wat operators in aanloop naar de roll-over kunnen doen.
Blijkt uit deze checks dat het nieuwe KSK-2017 trust anchor niet in de resolver beschikbaar/actief is, dan verwijzen we naar de eerder gepubliceerde artikelen over het handmatig en automatisch installeren van het nieuwe trust anchor. Daarnaast zijn er natuurlijk de documentatie van de software (leverancier) zelf en twee hands-on artikelen [1, 1, 2] van ICANN.
Let op: vanwege de Hold-Down periode van minimaal 30 dagen is het inmiddels te kort dag om nog een update via RFC 5011 te starten. Is een validerende resolver op dit moment nog niet voorzien van het KSK-2017 trust anchor, dan is het nu zaak om dat zo snel mogelijk handmatig te doen.
Noemen we ten slotte nog de belangrijkste noodmaatregel als er op 11 oktober onverhoopt toch iets mis mocht blijken te zijn met het nieuwe trust anchor: DNSSEC-validatie tijdelijk uitzetten totdat de problemen op de betreffende resolver opgelost zijn.
