Update: nieuwe DNSSEC-functionaliteit voor sleutelbeheer
Gepubliceerd op 18-07-2017
Unbound 1.6.4 doet 'key tag signaling'
Met de release van versie 1.6.4 ondersteunt Unbound nu ook 'key tag signaling' RFC 8145). Daarmee laten validerende resolvers aan een server weten welke sleutels zij als trust anchor gebruiken bij het opbouwen van de chain of trust. Op die manier krijgen beheerders van ondertekende domeinen informatie van client-zijde over de voortgang van een key roll-over.
Voor de resolver zijn er twee verschillende manieren (beide optioneel) om deze informatie — in de vorm van een of meerdere Key Tags — naar een (authoritatieve) server te sturen:
- als onderdeel van een gewone DNS -query voor een DNSKEY-record (
dit trust anchor ga ik als basis gebruiken om jouw antwoord te valideren
) - middels een nieuwe EDNS0 'Key Tag' query die als periodieke update naar de authoritatieve server wordt gestuurd
De mogelijkheid om deze informatie van client naar server te sturen is juist nu relevant vanwege de root KSK roll-over. RFC 5011 laat validerende resolvers de nieuwe publieke sleutel automatisch via DNS(SEC) binnenhalen en installeren als trust anchor. Maar er zijn op het moment van de daadwerkelijke roll-over (in oktober van dit jaar) waarschijnlijk nog allerlei resolvers die geen update hebben gehad (automatisch of handmatig). Daarmee worden alle domeinnamen onbereikbaar voor de gebruikers/applicaties van de betreffende resolver.
Tsjechische registry implementeert CDNSKEY/CDS in Knot DNS
CZ.NIC, de registry voor het .cz top-level domein, heeft versie 2.5.0 van de Knot DNS server voorzien van ondersteuning voor ondersteuning voor CDNSKEY/CDS. Daarmee kan de beheerder van een ondertekend domein zijn sleutelmateriaal veel makkelijker updaten bij de bovenliggende zone. Nu moet nog bij elke (KSK) roll-over de nieuwe publieke sleutel in de vorm van een DNSKEY- of DS-record bij de beheerder het parent-domein worden aangemeld — meestal via een web-interface of EPP (out-of-band).
RFC 7344 en 8078 beschrijven een methode waarmee nieuw sleutelmateriaal via de DNS(SEC)-infrastructuur zelf (in-band) naar de bovenliggende zone kan worden getransporteerd. Daartoe worden de actuele publieke KSK-sleutels van een zone ook als CDNSKEY- en CDS-record gepubliceerd. De beheerder van het bovenliggende domein scant regelmatig de authoritatieve servers voor zijn subdomeinen (gedelegeerde domeinen) voor nieuwe sleutel-records. De digitale handtekening onder die records garandeert de authenticiteit ervan, zodat ze veilig in de bovenliggende zone opgenomen kunnen worden.
Omdat deze methode zelf ook gebruik maakt van DNSSEC , werkt zij alleen nadat er al een eerste keer een sleutel-record is overgedragen (waarmee deze schakel in de chain of trust werd gesloten). Dat maakt dit protocol vergelijkbaar met RFC 5011 voor het transport van sleutelmateriaal de andere kant op.
