DNSSEC: DNS-responses authenticeren

In 2008 onthulde onderzoeker Dan Kaminsky een kritieke aanval op DNS-resolvers. De aanval maakte gebruik van het kleine veld van 16 bits voor de transactie-ID in DNS-antwoorden. Door een resolver te overspoelen met vervalste antwoorden met willekeurige transactie-ID's kon een aanvaller statistisch gezien de juiste transactie-ID raden voordat het echte antwoord binnenkwam. Een vergiftigde cache verwijst alle gebruikers van die resolver wekenlang door naar servers die door de aanvaller worden beheerd, totdat de cache verloopt.

DNSSEC (DNS-beveiligingsuitbreidingen) voegt cryptografische authenticatie toe aan DNS-antwoorden. Elke DNS-recordset in een met DNSSEC ondertekende zone gaat vergezeld van een digitale handtekening. Validerende resolvers controleren deze handtekeningen voordat ze records accepteren. Een vervalst of gewijzigd antwoord heeft een ongeldige handtekening en wordt afgewezen. DNSSEC beschermt tegen cachevergiftiging en antwoordvervalsing, maar versleutelt DNS-query's niet.

DNSSEC gebruikt per zone een hiërarchie met twee sleutels. De Zone Signing Key (ZSK) wordt gebruikt voor de dagelijkse ondertekening van afzonderlijke DNS-recordsets. De Key Signing Key (KSK) ondertekent alleen de DNSKEY-recordset, die de openbare sleutels van zowel de ZSK als de KSK bevat. De ZSK kan regelmatig worden vervangen, bijvoorbeeld maandelijks, terwijl de KSK minder vaak verandert, bijvoorbeeld jaarlijks. De hashwaarde van de KSK moet namelijk in de bovenliggende zone worden geregistreerd en het vervangen ervan is operationeel complex.

Elke ondertekende DNS-recordset (RRset genoemd) heeft een bijbehorend RRSIG-record met de cryptografische handtekening over die RRset. Wanneer een resolver een DNS-record opvraagt, bevat het antwoord zowel het record als de bijbehorende RRSIG. De resolver verifieert de RRSIG met de openbare sleutel van de zone. De handtekening omvat de recordinhoud, het type, de klasse en de vervaltijd, waardoor zowel wijziging als het opnieuw afspelen van oude, geldige handtekeningen wordt voorkomen.

De vertrouwensketen in DNSSEC wordt opgebouwd met Delegation Signer-records (DS-records). Wanneer een zone naar een onderliggende zone doorverwijst, publiceert de bovenliggende zone een DS-record met een hashwaarde van de KSK van de onderliggende zone. Een resolver die de bovenliggende zone vertrouwt, kan controleren of de hashwaarde van de KSK van de onderliggende zone overeenkomt met het DS-record. Zo ontstaat vertrouwen in de handtekeningen van de onderliggende zone. Deze keten loopt vanaf de DNS-rootzone via topniveaudomeinen naar afzonderlijke domeinzones.

Elke met DNSSEC ondertekende zone publiceert haar openbare ondertekeningssleutels in DNSKEY-records. Meestal zijn er twee DNSKEY-records: één voor de ZSK en één voor de KSK. De hashwaarde van de openbare sleutel van de KSK wordt als DS-record in de bovenliggende zone geregistreerd, waarmee het vertrouwen in de zone aan haar bovenliggende zone wordt gekoppeld. De hashwaarde van de KSK van de rootzone is hardcoded in validerende resolvers als het uiteindelijke vertrouwensanker, het Root Zone Trust Anchor genoemd.

DNSSEC-validatie begint bij de rootzone, waarvan het vertrouwensanker voor de KSK hardcoded in resolvers staat. De DNSKEY van de rootzone wordt gebruikt om de RRSIG ervan te verifiëren, waarmee de DS-records voor TLD's zoals .com worden geauthenticeerd. De DNSKEY van de .com-zone verifieert de RRSIG van de DS-records voor afzonderlijke domeinen. Deze keten van cryptografische verificatie loopt van de root naar het opgevraagde domein, zodat elke schakel is geauthenticeerd.

Wanneer een DNSSEC-validerende resolver een antwoord ontvangt, voert deze de volledige controle van de vertrouwensketen uit. De resolver haalt DNSKEY-records op, verifieert RRSIG-handtekeningen, volgt DS-records terug naar het vertrouwensanker van de rootzone en controleert de vervaltijden van handtekeningen. Als de validatie mislukt, geeft de resolver een SERVFAIL-fout terug in plaats van de mogelijk vervalste records. De meeste grote openbare resolvers, waaronder Cloudflares 1.1.1.1 en Googles 8.8.8.8, voeren DNSSEC-validatie uit.

De invoering van DNSSEC is ondanks de beveiligingsvoordelen traag verlopen. Het vervangen van sleutels vereist afstemming tussen zonebeheerders en registers van bovenliggende zones. Een fout tijdens het vervangen van de KSK kan de hele zone onbereikbaar maken. Het vervangen van de KSK van de ICANN-rootzone in 2019 vereiste jarenlange voorbereiding. Door handtekeningen neemt de zoneomvang aanzienlijk toe. Beheerders moeten geautomatiseerde sleutelrotatie en monitoring implementeren. Door deze operationele complexiteit zien veel kleinere domeinbeheerders af van DNSSEC.

Een veelvoorkomende misvatting is dat DNSSEC privacy voor DNS-query's biedt. Dat is niet zo. DNSSEC authenticeert alleen antwoorden; query's en antwoorden reizen nog steeds als leesbare UDP-pakketten via poort 53. Iedereen die het netwerk controleert, kan nog steeds elke opgevraagde domeinnaam zien. DNS-over-TLS (DoT) en DNS-over-HTTPS (DoH) bieden privacy voor query's door het DNS-verkeer te versleutelen. DNSSEC en DoH/DoT vullen elkaar aan: het ene biedt authenticiteit en het andere vertrouwelijkheid.

In 2024 was ongeveer 90 procent van de DNS-rootzone en de belangrijkste TLD's met DNSSEC ondertekend. Slechts ongeveer 20 tot 30 procent van de afzonderlijke domeinnamen was echter ondertekend. De ondersteuning voor DNSSEC-validatie door browsers en toepassingen verschilt sterk. Het beveiligingsvoordeel van DNSSEC is het grootst in combinatie met DANE (DNS-gebaseerde authenticatie van benoemde entiteiten). DANE gebruikt DNSSEC om vingerafdrukken van TLS-certificaten te publiceren, zodat clients certificaten kunnen verifiëren zonder uitsluitend op certificaatautoriteiten te vertrouwen.

DNSSEC voegt cryptografische handtekeningen toe aan DNS-antwoorden om cachevergiftiging en antwoordvervalsing te voorkomen. ZSK's ondertekenen recordsets, KSK's ondertekenen DNSKEY-records en DS-records koppelen het vertrouwen tussen bovenliggende en onderliggende zones. De validatie begint bij het hardcoded Root Zone Trust Anchor. DNSSEC versleutelt DNS-verkeer niet; DoH en DoT bieden privacy, terwijl DNSSEC authenticiteit biedt. Operationele complexiteit, waaronder het vervangen van sleutels, heeft de brede invoering vertraagd.