ZONEMD beschermt de integriteit van complete zonefiles

Nieuwe beveiligingsmethode eind dit jaar in root zone opgenomen

Digitaal hangslot in blauwgekleurde moederbordachtige digitale omgeving

Het relatief nieuwe ZONEMD-record kan aan een zone worden toegevoegd om de integriteitLink opent in een nieuwe browsertab van de DNS-informatie in de betreffende zone te waarborgen. Daarmee weten ontvangers/gebruikers van een zonefileLink opent in een nieuwe browsertab zeker dat hun kopie correct en compleet is. Het ZONEMD-record zelf wordt op zijn beurt beschermd door middel van een DNSSEC-handtekening, waarmee deze bescherming cryptografisch waterdicht is.

Op dit moment wordt gewerkt aan de toevoeging van een ZONEMD-record aan de root zoneLink opent in een nieuwe browsertab [1Link opent in een nieuwe browsertab, 2Link opent in een nieuwe browsertab]. Deze extra beveiliging is vooral van belang voor beheerders van recursieve resolvers die ook een complete kopie van de root zone lokaal willen cachen.

Maar ook voor ons is het ZONEMD-record potentieel interessant: Om te zorgen dat onze autoritatieve servers op allerlei plaatsen over de wereld beschikbaar zijn, maken we in het algemeen gebruik van peering-overeenkomsten met betrouwbare partners ("collega's") uit de internetinfrastructuurwereld. Maar we onderzoeken ook wat de mogelijkheden zijn om autoritatieve nameservers voor de .nl-zone onder te brengen op relatief goedkope virtuele machines bij commerciële dienstverlenersLink opent in een nieuwe browsertab. Daarbij is vanzelfsprekend cruciaal dat de DNS-informatie altijd te vertrouwen moet zijn, ongeacht eventuele beveiligingsproblemen bij een dienstverlener.

Planning

Volgens de huidige planning zal het ZONEMD-recordLink opent in een nieuwe browsertab [1Link opent in een nieuwe browsertab] op 13 september 2023 aan de root zone worden toegevoegdLink opent in een nieuwe browsertab. In eerste instantie zal het algoritmenummer op een gereserveerde (private) instelling worden gezet, zodat er geen validatie kan plaatsvinden. Op 13 december wordt dan overgeschakeld naar het SHA-384Link opent in een nieuwe browsertab algoritme, waarna afnemers het ZONEMD-record kunnen gebruiken om de integriteit van de zonefile te controleren. De rootserversLink opent in een nieuwe browsertab zelf zullen op zijn vroegst een jaar na deze introductie het ZONEMD-record gaan valideren. Hoewel er geen impactLink opent in een nieuwe browsertab op afnemers/gebruikers wordt verwacht, is het goed te weten dat de root zone file vanaf dit najaar een extra record-type en beveiligingsfeature bevat.

Kopieën van zonefiles

Er zijn verschillende goede redenen waarom een recursieve resolver een complete kopie van de root zone lokaal zou willen cachenLink opent in een nieuwe browsertab. RFC 8806Link opent in een nieuwe browsertab noemt er 2: om vertragingen te voorkomen in geval van netwerkaanvallen en om het afluisteren van verkeer met de rootserversLink opent in een nieuwe browsertab tegen te gaan. Een ondertekend ZONEMD-record garandeert dan de integriteit van de lokale kopie (en impliciet de authenticiteit van de bron).

Vanuit SIDN kunnen we hier nog een derde reden voor de toepassing van ZONEMD aan toevoegen: registry’s die voor hun secondary nameservers (ook) gebruikmaken van virtuele servers bij commerciële aanbieders willen zeker weten dat ook daar de juiste DNS-informatie wordt opgehoest. Het ZONEMD-record zorgt dat alleen de correcte en complete zonefile op die cloudservers wordt ingeladen (ervan uitgaande dat de DNS-software niet gecompromitteerd is).

Onderscheid met TSIG en DNSSEC

Essentieel verschil met de bestaande TSIG-beveiligingLink opent in een nieuwe browsertab voor zone transfers (AXFR) en updates (IXFR)Link opent in een nieuwe browsertab is dat ZONEMD niet het transport maar de integriteit van de zonefile zelf beschermd. Bovendien moet voor TSIG eerst een geheime sleutel uitgewisseld worden tussen de primary en de secondary.

In principe zou je de integriteit van een zonefile ook kunnen verifiëren door alle individuele DNSSEC-handtekeningen af te lopen en te valideren. De originele DNS-records vormen tezamen met de tussenliggende NSEC(3)-records immers een gelinkte keten die de hele name space van de betreffende zone afdekt (denk maar aan zone walking). Maar dat kost veel verwerkingskracht, zeker bij gebruik van een ECDSA-gebaseerd DNSSEC-algoritme. Bovendien omvat DNSSEC toch niet alle records in de zone: non-apex NS-records (delegaties), glue recordsLink opent in een nieuwe browsertab en NSEC(3)-records voor niet-ondertekende delegaties ontbreken (die laatste alleen als het Opt-Out-bit aan staat). Uitgangspunt voor DNSSEC is dat het de integriteit van DNS-responses beschermd, terwijl ZONEMD dat doet voor complete zonefiles.

ZONEMD en DNSSEC

Het ZONEMD-record zelf (gedefinieerd in RFC 8976Link opent in een nieuwe browsertab) steekt relatief eenvoudigLink opent in een nieuwe browsertab in elkaar: Alle informatie in de zone wordt eerst in een gestandaardiseerde alfanumerieke volgordeLink opent in een nieuwe browsertab gezet, waarna de hashwaardeLink opent in een nieuwe browsertab over het geheel wordt berekend. Deze zogenaamde message digest (een statistisch unieke, digitale samenvatting) wordt gepubliceerd in het ZONEMD-record, tezamen met het serienummer van de zonefile en het gebruikte hashalgoritme (SHA-384 of SHA-512Link opent in een nieuwe browsertab).

Merk op dat de berekening van de ZONEMD-hash en de ondertekening met DNSSEC onderling verweven zijn. Het ondertekeningsproces begint met de opname van een placeholder voor het ZONEMD-record. Pas daarna kun je de zone ondertekenen, waarbij nu ook de juiste NSEC(3)-records rondom de ZONEMD RRsetLink opent in een nieuwe browsertab worden gegenereerd. Vervolgens kun je de hashwaarde voor het ZONEMD-record uitrekenen (waarin nu ook de juiste NSEC(3)-records worden meegenomen). De digitale handtekening (in een RRSIG-record) voor de actuele ZONEMD RRset moet dan als laatste worden toegevoegd.

Validatie

Bij de validatie van de ZONEMD-hash aan de ontvangende kant moet eerst de DNSSEC-validatie van het ZONEMD-record uitgevoerd worden. Of DNSSEC wel of niet gebruikt wordt, kun je zien aan de aanwezigheid van een DS-record in de bovenliggende zone (voor de root zone is het DS-record al op een DNSSEC-validerende resolver beschikbaar in de vorm van een trust anchorLink opent in een nieuwe browsertab).

Daarna wordt de hash over de ontvangen zonefile op exact dezelfde wijze uitgerekend als aan de verzendende kant en vergeleken met de hashwaarde in het meegestuurde ZONEMD-record. De zonefile is alleen geldig als de 2 hashwaarden overeenkomen, en alleen dan mag de nieuwe zone door de nameserver ingeladen worden.

Grote zones met veel dynamiek

Het zojuist beschreven proces van sorteren en hashen (aan verzendende zijde) en valideren (ook weer sorteren en hashen, nu aan ontvangende zijde) kost vanzelfsprekend tijd. De root zone bevat zo'n 1.500Link opent in een nieuwe browsertab topleveldomeinenLink opent in een nieuwe browsertab en verandert niet al te vaak, waarmee de ZONEMD-berekening en -validatie goed te doen is.

Dat ligt heel anders voor grote zones met veel dynamiek. Zo bevat de .nl-zone nu 6,3 miljoen domeinnamenLink opent in een nieuwe browsertab en wordt deze elk half uur ververst. We hebben dat half uur ook echt nodig: De Hardware Security Modules (HSM'sLink opent in een nieuwe browsertab) die we in 2021 nieuw hebben aangeschaft waren in principe snel genoeg, maar voor de overstap van DNSSEC-algoritme nummer 8 naar nummer 13 hebben we wel het ondertekenings- en validatieproces moeten optimaliseren. Alleen op die manier konden we de arbeidsintensievere validatie van de meer dan 20 miljoen ECDSA-gebaseerde handtekeningen in de nieuwe .nl-zone binnen die tijd uitvoeren.

ZONEMD lookup

"ZONEMD is voor ons zeker interessant," zegt Stefan Ubbink, DNS-engineer bij SIDN, "maar de omvang en verversingssnelheid van de .nl-zone maken dat we eerst heel goed naar de noodzaak en opbrengsten enerzijds en de nadelen en inspanningen anderzijds moeten kijken. Bovendien hebben we eind vorig jaar het Opt-Out-bit voor de .nl-zone uitgezet, waarmee nu ook alle NSEC(3)-records voor niet-ondertekende delegaties in de zone zijn opgenomen. Met deze uitgebreide bescherming van DNSSEC is een extra beveiliging in de vorm van een ZONEMD-record een stuk minder van belang. Op dit moment zijn er dan ook geen concrete plannen om ZONEMD in de .nl-zone op te nemen. Wel volgen we met belangstelling de ontwikkelingen rondom de root zone."