DNSSEC: Definitie, hoe het werkt en waarom het belangrijk is

Het domeinnaamsysteem DNS fungeert als het telefoonboek van het internet en vertaalt miljarden keren per dag menselijk leesbare namen naar IP-adressen. De DNS-database slaat kritieke DNS-records op, zoals IP-adressen en domein-aliassen, waardoor het een doelwit is voor cyberbedreigingen. Maar deze kritieke infrastructuur werd in de jaren 1980 ontworpen zonder ingebouwde beveiliging. Traditionele DNS-validatie vertrouwde op het matchen van hetzelfde IP-adres voor antwoorden, wat onveilig is omdat IP-adressen kunnen worden gespoofed. DNSSEC bestaat om die fundamentele leemte op te vullen, door cryptografische verificatie toe te voegen aan een systeem dat oorspronkelijk puur op vertrouwen werkte.

DNSSEC in een notendop

Domain Name System Security Extensions, beter bekend als DNSSEC, staat voor DNS Security Extensions en is een set IETF-protocolspecificaties die cryptografische handtekeningen toevoegt aan DNS-gegevens. Met deze handtekeningen kunnen DNS-resolvers controleren of de informatie die ze ontvangen daadwerkelijk afkomstig is van de gezaghebbende bron en of er onderweg niet mee is geknoeid.

Het kernprobleem dat DNSSEC oplost is eenvoudig: zonder DNSSEC kunnen aanvallers valse DNS-responses in de caches van resolvers injecteren. Deze aanval, bekend als DNS cache poisoning, leidt gebruikers om naar kwaadaardige sites zonder dat ze het weten. DNSSEC voorkomt dit door authenticatie van de herkomst van gegevens mogelijk te maken en de integriteit van DNS-records te garanderen door middel van digitale handtekeningen, het gebruik van cryptografie met openbare sleutels en zorgvuldig beheer van de sleutels van DNS-zones om te voorkomen dat men zich voordoet als iemand en er met gegevens wordt geknoeid.

De Internet Engineering Task Force (IETF) heeft DNSSEC begin jaren 2000 gestandaardiseerd via een reeks RFC’s, waaronder RFC 4033, 4034 en 4035. De belangrijkste mijlpaal bij de implementatie kwam in juli 2010 toen ICANN de DNS-rootzone ondertekende, waarmee een wereldwijd vertrouwensanker werd ingesteld dat DNSSEC wereldwijd in de praktijk mogelijk maakte.

Het is essentieel om te begrijpen wat DNSSEC wel en niet doet. DNSSEC verifieert DNS-gegevens en bevestigtdat A-, AAAA-, MX- en TXT-records echt en ongewijzigd zijn. DNS-query’s en antwoorden worden echter niet gecodeerd. Uw DNS-verkeer blijft zichtbaar voor iedereen die het kan waarnemen. Voor encryptie zijn aanvullende protocollen nodig zoals DNS over TLS of DNS over HTTPS.

DNSSEC voorkomt ook niet alle aanvallen op DNS-infrastructuur. Volumetrische DDoS-aanvallen kunnen DNS-servers nog steeds overweldigen, ongeacht de ondertekening. En DNSSEC kan niet voorkomen dat gebruikers legitiem geregistreerde phishingdomeinen bezoeken die er toevallig overtuigend uitzien.

Het implementeren van DNSSEC kan complex zijn vanwege de noodzaak voor sleutelbeheer en het opzetten van een vertrouwensketen. Een succesvolle implementatie van DNSSEC vereist dat de bovenliggende zone en alle zones in de keten ook ondertekend zijn.

De meeste topleveldomeinen ondersteunen DNSSEC. Volgens gegevens van ICANN zijn er meer dan 1400 TLD’s ondertekend. Het gebruik van domeinen op het tweede niveau vertelt echter een ander verhaal. Slechts ongeveer 1-2% van de .com-zones heeft DNSSEC ingeschakeld, terwijl landcode-TLD’s zoals .nl (Nederland) en .se (Zweden) meer dan 90% ondertekeningspercentages hebben als gevolg van verplicht beleid.

Waarom zou u zich zorgen maken? Omdat zonder DNSSEC elke DNS-query die uw organisatie uitvoert, kwetsbaar is voor stille manipulatie. Een aanvaller die de cache van je resolver vergiftigt, kan je medewerkers omleiden naar sites waar gegevens worden gehackt of de e-mailaflevering onderscheppen – en dat allemaal zonder dat er duidelijke waarschuwingen worden gegeven.

Hoe DNS en DNSSEC bij elkaar passen

Laten we, voordat we dieper ingaan op DNSSEC, kort samenvatten hoe het domeinnaamsysteem vandaag de dag werkt. Wanneer u een URL in uw browser typt, neemt de stub-resolver van uw computer contact op met een recursieve DNS-resolver – vaakgeleverd door uw internetprovider, bedrijfsnetwerk of een openbare service zoals 8.8.8.8 van Google of 1.1.1.1 van Cloudflare. De DNS-oplosser verwerkt DNS-query’s door de keten van servers te volgen om het juiste IP-adres op te halen, waardoor een efficiënte en nauwkeurige resolutie wordt gegarandeerd.

Neem het oplossen van www.example.com. De recursieve DNS-oplosser vraagt eerst een van de 13 logische root DNS-naamservers om informatie over .com. De rootserver antwoordt met een verwijzing naar de TLD-servers voor .com die worden beheerd door Verisign. De resolver vraagt vervolgens de .com-servers naar example.com en krijgt een andere verwijzing naar de gezaghebbende naamserver van example.com. Ten slotte ondervraagt de resolver die gezaghebbende server en krijgt hij de feitelijke A-record met het IP-adres voor www.example.com.

Binnen dit hiërarchische systeem werkenverschillende DNS-componenten, zoals resource records, gezaghebbende naamservers en zone-ondertekensleutels,samen om elke DNS-zone te beheren, controleren en beveiligen.

Dit elegante, hiërarchische systeem werd al in 1987 gedefinieerd in RFC 1034 en 1035. Het probleem? Het klassieke DNS-protocol is ontworpen zonder sterke authenticatie. Reacties werden voornamelijk gevalideerd door IP-adressen van bronnen en 16-bits transactie-ID’ste matchen – eensysteem dat aanvallers leerden uit te buiten.

De Kaminsky kwetsbaarheid uit 2008 toonde aan hoe kwetsbaar dit ontwerp was. Beveiligingsonderzoeker Dan Kaminsky toonde aan dat aanvallers met grote waarschijnlijkheid valse antwoorden in resolvercaches konden injecteren door raden te laten vloeien tijdens een enkel queryvenster. Deze onthulling leidde tot noodpatches in de hele branche en versnelde de wereldwijde implementatie van DNSSEC aanzienlijk.

DNSSEC wordt geïntegreerd als een uitbreidingslaag die om bestaande DNS heenloopt zonder het kernmodel voor query’s en reacties te wijzigen. Niet-ondertekende zones blijven normaal werken voor niet-validerende resolvers. Validerende resolvers voeren gewoon extra cryptografische controles uit op ondertekende zones. Deze achterwaartse compatibiliteit was cruciaal voor een stapsgewijze toepassing in de DNS-naamruimte.

Kernconcepten van DNSSEC en recordtypen

DNSSEC introduceert verschillende nieuwe DNS resource record-types die samenwerken om een verifieerbare vertrouwensketen te creëren. Inzicht in deze records en hun relaties is essentieel voor iedereen die met ondertekende zones werkt.

De basiseenheid in DNSSEC is de resource record set, of RRSet. Dit is een groepering van DNS-records die dezelfde naam, hetzelfde type en dezelfde klasse hebben. In plaats van afzonderlijke records te ondertekenen, ondertekent DNSSEC volledige RRSets. Deze aanpak zorgt voor atomaire integriteit-je kunt niet knoeien met één record in een set zonder de handtekening van alle records ongeldig te maken.

De RRSIG-record bevat een digitale handtekening voor een RRSet. Elke broncodehandtekening wordt gemaakt met de privésleutel van de zone en bevat metagegevens zoals de naam van de ondertekenaar, de geldigheidsperiode en het gebruikte algoritme. Resolvers verifiëren deze handtekeningen door een hash van de RRSet-gegevens opnieuw te berekenen en deze te vergelijken met de cryptografische handtekening.

Het DNSKEY record publiceert de publieke sleutel die gebruikt wordt om handtekeningen te verifiëren. Deze records verschijnen aan de top van de zone (zoals example.com.) en bevatten vlaggen die de rol van de sleutel aangeven. Een vlagwaarde van 256 duidt op een zoneondertekensleutel, terwijl 257 op een sleutelondertekensleutel duidt.

De DS-record, of delegation signer record, zorgt voor de koppeling tussen ouder- en kindzone. Deze wordt opgeslagen in de ouderzone en bevat een cryptografische hash van de openbare sleutel van de kindzone. De DS-record voor example.com wordt bijvoorbeeld opgeslagen in de .com-zone, waardoor resolvers kunnen controleren of de DNSKEY-record van example.com authentiek is. De openbare sleutel van elke zone wordt ondertekend door de privésleutel van de ouderzone, wat essentieel is voor het tot stand brengen van de vertrouwensketen in DNSSEC. Dit proces zorgt ervoor dat het vertrouwen wordt doorgegeven van de ouder- naar de kindzone, waardoor een veilige en controleerbare hiërarchie wordt gevormd.

NSEC- en NSEC3-records maken geauthenticeerde bestaansweigering mogelijk. Wanneer een DNS-query vraagt om een naam die niet bestaat, bewijzen deze records dat de naam echt niet bestaat, waardoor aanvallers niet kunnen beweren dat niet-bestaande namen echt zijn. NSEC ketent bestaande namen in gesorteerde volgorde, terwijl NSEC3 cryptografisch gehashte recordnamen gebruikt om eenvoudige opsomming van zone-inhoud te voorkomen.

CDS- en CDNSKEY-records ondersteunen geautomatiseerd sleutelbeheer. Hiermee kunnen kindzones bijgewerkte DS- of DNSKEY-informatie doorgeven aan ouderzones, waardoor de handmatige coördinatie die traditioneel nodig is met registrars wordt verminderd.

De scheiding tussen Zone Signing Key (ZSK) en Key Signing Key (KSK) verdient speciale aandacht. De ZSK ondertekent reguliere zonegegevens (A, AAAA, MX-records), terwijl de KSK alleen de DNSKEY RRSet zelf ondertekent. Dankzij deze scheiding kunnen operators de ZSK vaak draaien terwijl de stabielere KSK en het bijbehorende DS-record in de bovenliggende zone ongewijzigd blijven.

Naamsysteem Beveiligingsuitbreidingen

Name System Security Extensions (NSSE) vertegenwoordigen een uitgebreide verzameling protocollen en standaarden die zijn ontworpen om de beveiliging van het domeinnaamsysteem (DNS) te versterken. De kern van NSSE is DNSSEC, dat digitale handtekeningen en openbare-sleutelcryptografie gebruikt om DNS-gegevens te verifiëren en de integriteit ervan te garanderen. Het belangrijkste doel van deze systeembeveiligingsuitbreidingen is de verdediging tegen bedreigingen zoals DNS-spoofing en DNS-cache-poisoning-aanvallendie DNS-gegevens kunnen manipuleren en gebruikers naar frauduleuze sites kunnen leiden.

Door gebruik te maken van extensies voor de beveiliging van het naamsysteem, kunnen domeineigenaars ervoor zorgen dat de DNS-gegevens die aan hun domeinen zijn gekoppeld zowel authentiek als ongewijzigd zijn terwijl ze over het internet reizen. Dit wordt bereikt door het gebruik van openbare sleutelinfrastructuur, waarbij elke ondertekende zone een openbare sleutel publiceert die resolvers gebruiken om digitale handtekeningen op DNS-records te verifiëren. Als gevolg hiervan kunnen gebruikers en toepassingen erop vertrouwen dat de informatie die ze ontvangen van het domeinnaamsysteem legitiem is, wat helpt om het vertrouwen van de gebruiker te behouden en bescherming te bieden tegen een breed scala aan cyberbedreigingen.

Hoe DNSSEC-validatie van begin tot eind werkt

DNSSEC-validatie volgt het DNS-omzettingspad, waarbij de verificatie wordt opgebouwd vanaf een bekend startpunt dat een vertrouwensanker wordt genoemd. Voor de meeste resolvers is dit anker de KSK van de rootzone, die wordt gedistribueerd via IANA en software-updates van resolvers. Wanneer een validerende recursieve resolver een query voor een ondertekend domein verwerkt, voert deze cryptografische verificatie uit op elke stap van de DNS-hiërarchie. De resolver vertrouwt de root DNSKEY al. Met behulp van die sleutel wordt de RRSIG van de rootzone geverifieerd, die de DS-record voor het TLD (zoals .com) dekt. Vervolgens wordt de DNSKEY van .com opgehaald en wordt gecontroleerd of deze overeenkomt met de hash van de DS. Dit proces gaat verder tot aan het doeldomein.

Neem het opvragen van www.example.com in een volledig ondertekende omgeving. De resolver verifieert:

• De DNSKEY van de root (vertrouwd anker) ondertekent de DS-record van .com
• De DNSKEY van .com komt overeen met de DS hash en ondertekent het DS-record van example.com
• De DNSKEY van example.com komt overeen met zijn DS en ondertekent de A-record voor www

Dit creëert een ononderbroken vertrouwensketen van de root naar het aangevraagde DNS-record. Elke mismatch – een ongeldige handtekening, verlopen RRSIG of DS/DNSKEY hashfout – verbreekt de keten.

Je kunt validatiefouten waarnemen met testdomeinen zoals dnssec-failed.org, opzettelijk verkeerd geconfigureerd door ICANN. Validerende resolvers retourneren SERVFAIL voor dit domein, waardoor de toegang volledig wordt geblokkeerd. Voor gebruikers achter niet-validerende resolvers (nog steeds ongeveer 70% wereldwijd), wordt het domein normaal omgezet, wat het gat in de huidige implementatie aantoont.

DNSSEC verandert niets aan toepassingsprotocollen zoals HTTP of SMTP. Het zorgt er alleen voor dat het IP-adres en andere DNS-gegevens die applicaties ontvangen authentiek en ongewijzigd zijn. De browser maakt nog steeds op normale wijze een HTTPS-verbinding; DNSSEC garandeert alleen dat de DNS-queryantwoorden naar de legitieme server wijzen.

Voor geauthenticeerde bestaansweigering bewijzen NSEC- of NSEC3-records dat een opgevraagde naam of een opgevraagd type niet bestaat. De resolver ontvangt een cryptografisch ondertekend bewijs waaruit blijkt welke namen wel in de zone bestaan, zodat hij het gat kan bevestigen waarin de gezochte naam zou verschijnen.

DNSSEC bronrecords in de praktijk

Laten we de belangrijkste DNSSEC-gerelateerde DNS-recordtypes in meer praktisch detail bekijken.

RRSIG-records worden gegenereerd met de privésleutel van de zone, meestal de ZSK voor gewone records. Elke handtekening specificeert het ondertekeningsalgoritme (zoals ECDSAP256SHA256), het aantal labels in de ondertekende naam, de oorspronkelijke TTL en ingangs-/vervaltijdstempels. Deze tijdstempels zijn kritisch: resolvers verwerpen handtekeningen die buiten hun geldigheidsvenster vallen, meestal ingesteld op 30 dagen. Zonebeheerders moeten records opzeggen voordat ze verlopen om validatiefouten te voorkomen.

DNSKEY-records verschijnen aan de top van de zone en kunnen meerdere sleutels bevatten tijdens rollover-perioden. Het vlagveld onderscheidt sleutelrollen: 257 geeft een KSK aan met de SEP-bit (Secure Entry Point) ingesteld, terwijl 256 een ZSK aangeeft. De sleuteltag, een 16-bits identificatie die wordt berekend op basis van de sleutelgegevens, helpt resolvers om DNSKEY-records snel te matchen met overeenkomstige DS-records.

DS-records in de ouderzone bevatten een hash van de KSK van de kindzone. Een typische DS-record bevat de sleuteltag, het algoritmenummer, het digesttype (meestal SHA-256) en de digest zelf. Tijdens DNSSEC-validatie halen resolvers de DNSKEY van het kind op, berekenen de hash en vergelijken deze. Een mismatch levert een BOGUS-status op, waardoor de validatie mislukt.

NSEC-records lopen door de namen van de zone in canoniek gesorteerde volgorde. Elke NSEC verwijst naar de volgende bestaande naam en vermeldt de recordtypes die bij die naam aanwezig zijn. Dit bewijst dat de zone niet bestaat, maar stelt de inhoud bloot aan “zone walking” – aanvallers kunnen elke naam opsommen door de keten te volgen.

NSEC3 pakt zone walking aan door namen te hashen met een salt en iteratietelling voordat ze worden geketend. Hoewel dit triviale opsomming voorkomt, kunnen vastberaden aanvallers offline nog steeds voorspelbare namen kraken. De opt-out vlag staat niet-ondertekende delegaties toe binnen anders ondertekende zones, handig voor grote zones met veel niet-ondertekende subdomeinen.

CDS- en CDNSKEY-records zijn een afspiegeling van de DS- en DNSKEY-records, maar worden in de kindzone zelf gepubliceerd. Beheerders van moederzones kunnen deze records opvragen om automatisch ondertekenaarrecords van delegaties bij te werken, waardoor sleutelrolllovers en initiële DNSSEC-implementatie worden gestroomlijnd.

DNS-records groeperen

Een fundamenteel aspect van de implementatie van DNSSEC is het groeperen van DNS-records in Resource Record Sets (RRSets). Een RRSet is een verzameling DNS-records met dezelfde naam en hetzelfde type binnen een zone. In plaats van elke afzonderlijke record te ondertekenen, ondertekent DNSSEC de volledige RRSet met een enkele RRSIG-record. Deze aanpak stroomlijnt het proces van ondertekenen en valideren van DNS-gegevens, waardoor het efficiënter wordt voor zowel domeineigenaren als validerende resolvers.

Het groeperen van DNS-records in RRSets vereenvoudigt niet alleen de implementatie van DNSSEC, maar verbetert ook de beheerbaarheid van de DNS-infrastructuur. Wanneer een record in een RRSet wordt gewijzigd, wordt de hele set opnieuw ondertekend, waardoor de integriteit en authenticiteit van alle gerelateerde DNS-gegevens behouden blijven. Voor domeineigenaren betekent dit minder complexiteit bij het beheren van handtekeningen en een robuustere verdediging tegen geknoei of ongeautoriseerde wijzigingen aan hun DNS-records. Uiteindelijk is het groeperen van DNS-records een best practice die de schaalbaarheid en veiligheid van de moderne DNS-infrastructuur ondersteunt.

Zone Ondertekencode, Ondertekenmodi en Sleutelbeheer

DDNSSEC sleutelbeheer concentreert zich op twee verschillende rollen. De zone ondertekeningssleutel (ZSK) zorgt voor het dagelijkse ondertekenen van zonegegevens-A, AAAA, MX, TXT en andere reguliere records. De sleutelondertekeningsleutel (KSK) heeft een beperktere maar kritieke functie: hij ondertekent alleen de DNSKEY RRSet, waarmee de vertrouwde link naar de DS-record van de ouderzone wordt gemaakt.

Operators scheiden deze rollen om goede redenen. De privésleutel van de ZSK wordt vaak gebruikt en loopt een hoger risico. Door deze sleutel elke 30-90 dagen te roteren, wordt potentiële schade door een compromittering beperkt. De KSK wordt zelden gewijzigd – jaarlijksof minder – omdatvoor elke rotatie het DS-record in de bovenliggende zone moet worden bijgewerkt.

Er zijn drie hoofdondertekeningsmodi voor DNSSEC-implementatie:

• Offline ondertekenen: De zone wordt ondertekend op een air-gapped machine of HSM, waarna het ondertekende zonebestand naar gezaghebbende servers wordt verzonden. Het beste voor statische zones waar de beveiliging zwaarder weegt dan het operationele gemak.
• Gecentraliseerde online ondertekening: Een speciale ondertekeningsdienst ontvangt niet-ondertekende updates en ondertekent ze voordat ze naar gezaghebbende DNS-servers worden gedistribueerd. Evenwicht tussen beveiliging en ondersteuning voor dynamische updates.
• On-the-fly ondertekening: Autoritaire servers genereren DNSSEC-handtekeningen in realtime wanneer DNS-verzoeken binnenkomen. Geschikt voor zeer dynamische zones, maar verhoogt het risico op blootstelling aan sleutels als servers worden gecompromitteerd.

Sleutelrollover vereist een zorgvuldige timing om te voorkomen dat de vertrouwensketen wordt verbroken. De standaardbenadering publiceert nieuwe sleutels vooraf: voeg de nieuwe sleutel toe aan de DNSKEY RRSet, wacht tot caches verlopen zijn (meestal twee TTL-perioden) en verwijder dan de oude sleutel. Voor KSK-rollovers moet de nieuwe DS ook door de bovenliggende zone propageren voordat de oude KSK wordt verwijderd.

De 2018 root KSK rollover illustreerde de inzet. Ondanks uitgebreide voorbereidingen slaagde ongeveer 0,3% van de resolvers er niet in hun vertrouwensankers bij te werken, waardoor ze tijdelijke SERVFAIL-reacties kregen. Voor een enkele zone lijken dergelijke fouten misschien onbeduidend, maarze halen een domein effectief offline voor getroffen gebruikers.

Delegatie Ondertekenaar

De DS-record (Delegation Signer) is een hoeksteen van de vertrouwensketen van DNSSEC en koppelt de beveiliging van een kindzone aan de ouderzone binnen de DNS-hiërarchie. Het DS-record bevat een cryptografisch gehashte versie van de Key Signing Key (KSK) van de kindzone en wordt gepubliceerd in de ouderzone. Hierdoor kunnen recursieve resolvers controleren of de DNSKEY-record die door de kindzone wordt weergegeven, authentiek is en of er niet mee geknoeid is.

Door deze verbinding tot stand te brengen, stelt het DS-record domeineigenaars in staat om het vertrouwen uit te breiden van de moederzone naar hun eigen DNS-gegevens, zodat elke stap in het resolutieproces wordt gevalideerd. Dit mechanisme is essentieel voor het behoud van de integriteit van de gehele DNS-infrastructuur, omdat het voorkomt dat aanvallers op elk punt in de keten frauduleuze DNS-gegevens kunnen injecteren. Voor domeineigenaren is het correct configureren van delegatie-signer records een kritieke stap in het implementeren van DNSSEC en het beveiligen van hun domeinen tegen DNS-gebaseerde aanvallen.

Voordelen en beperkingen van DNSSEC

De belangrijkste waarde van DNSSEC is de verdediging tegen DNS cache poisoning en DNS spoofing-aanvallen. Door de authenticiteit van reacties cryptografisch te bewijzen, wordt voorkomen dat aanvallers gebruikers stilletjes omleiden naar phishingsites of e-mail onderscheppen via valse MX-records. Het Kaminsky-kwetsbaarheden van 2008 toonde aan hoe verwoestend dergelijke aanvallen kunnen zijn; DNSSEC maakt ze fundamenteel ineffectief tegen ondertekende zones.

Naast basisbeveiliging maakt DNSSEC geavanceerde beveiligingstoepassingen mogelijk. Met DANE (DNS-Based Authentication of Named Entities) kunnen domeineigenaars TLS-certificaatinformatie rechtstreeks in DNS publiceren met behulp van TLSA-records. Hiermee kunnen certificaten voor SMTP-servers of webservices worden geverifieerd zonder uitsluitend op traditionele certificaatautoriteiten te vertrouwen. Dergelijke toepassingen vereisen geverifieerde DNS-gegevens, precies wat DNSSEC biedt.

De beperkingen zijn even belangrijk om te begrijpen:

• Geen vertrouwelijkheid: DNSSEC verifieert maar versleutelt niet. DNS-query’s en DNS-queryreacties blijven zichtbaar voor waarnemers. Voor encryptie is DNS over TLS of DNS over HTTPS nodig.
• Geen DDoS-bescherming: DNSSEC kan volumetrische aanvallen op DNS-infrastructuur niet tegenhouden. Het is zelfs zo dat grotere ondertekende reacties versterkingsaanvallen kunnen verergeren.
• Geen bescherming tegen legitiem ogende bedreigingen: DNSSEC kan typosquatting niet voorkomen of gebruikers die vertrouwen op misleidende domeinnamen die legitiem zijn geregistreerd en correct zijn ondertekend.

Overwegingen met betrekking tot prestaties zijn onder andere aanzienlijk grotere DNS-responses: handtekeningenvoegen ruwweg 500 bytes per RRSet toe . Dit veroorzaakt soms TCP fallback ( waardoor latentie wordt toegevoegd) en verhoogt het bandbreedtegebruik. Open resolvers met DNSSEC kunnen reflectieaanvallen versterken met factoren van 50x of meer in vergelijking met gewone DNS.

Ondanks deze nadelen raden beveiligingsorganisaties zoals ICANN en NIST DNSSEC aan voor hoogwaardige domeinen. De overhead is reëel, maar voor publiekgerichte services waar DNS-spoofing serieuze aanvallen mogelijk zou kunnen maken, rechtvaardigt de bescherming de complexiteit.

Risico’s, uitdagingen en waarom de adoptie nog steeds ongelijk is

DNSSEC introduceert operationele risico’s die veel van de aarzelende adoptie verklaren. Misconfiguraties, verlopen handtekeningen, DS/DNSKEY mismatches of ongeldige handtekeningsketens veroorzaken validatiefouten. Voor de ruwweg 30% van de gebruikers achter validerende resolvers werkt een verkeerd geconfigureerde zone gewoon niet meer. Er is geen sierlijke degradatie; query’s retourneren SERVFAIL.

Verschillende barrières vertragen de implementatie van DNSSEC:

• Coördinatie tussen meerdere partijen: Ondertekening vereist afstemming tussen domeineigenaars, registrars en DNS-hostingproviders. DS-records moeten door registrarsystemen stromen om de bovenliggende zone te bereiken.
• Lacunes in expertise: Veel organisaties hebben geen ervaring met DNSSEC. Angst voor het veroorzaken van uitval door verkeerde configuratie weerhoudt hen ervan te beginnen.
• Verouderde infrastructuur: Sommige bedrijfsomgevingen bevatten resolvers of apparaten die DNSSEC-validatie niet volledig ondersteunen, waardoor compatibiliteitsproblemen ontstaan.

Adoptiestatistieken laten een ongelijke vooruitgang zien. De root DNS-zone is sinds 2010 ondertekend en meer dan 1400 TLD’s ondersteunen DNSSEC. De toepassing op het tweede niveau varieert echter enorm. De .nl-zone is voor meer dan 95% ondertekend, dankzij stimuleringsmaatregelen van registers en verplicht beleid. .comdaarentegen zit rond de 1,5%-miljoenendomeinen blijven onondertekend.

Aan de kant van de resolvers blijkt uit metingen van APNIC dat ongeveer 30% van de DNS-oplossers wereldwijd DNSSEC-validatie uitvoert, tegenover ongeveer 10% in 2018. Er wordt nog steeds vooruitgang geboekt, maar de meeste eindgebruikers ontvangen nog steeds niet-gevalideerde DNS-reacties.

DNSSEC bevat ook veiligheidsoverwegingen die verder gaan dan validatiefouten. Grote ondertekende reacties maken gezaghebbende servers aantrekkelijk voor DNS-versterkingsaanvallen. Operators moeten responslimieten implementeren en best practices volgen voor de configuratie van resolvers om te voorkomen dat ze ongewild een aanvalsinfrastructuur worden.

Grote organisaties blijven pleiten voor een bredere toepassing. ICANN publiceert implementatiehandleidingen en nationale cyberbeveiligingsinstanties raden DNSSEC steeds vaker aan voor overheidsdomeinen en domeinen met kritieke infrastructuur. Prognoses suggereren dat het gebruik van het tweede niveau tegen 2030 50% kan bereiken, aangezien automatisering via CDS/CDNSKEY de operationele wrijving vermindert.

Operaties in de echte wereld: DNS rootzone ondertekeningsceremonie en vertrouwensankers

De DNS-rootzone neemt een unieke positie in binnen de DNSSEC-architectuur. Omdat er geen ouderzone is die een DS-record kan leveren, moet de KSK van de root out-of-band worden vertrouwd als het ultieme vertrouwensanker. Het is enorm belangrijk om dit goed te doen: elkeDNSSEC-vertrouwensketen vindt hier zijn oorsprong.

ICANN houdt vier tot zes keer per jaar rootondertekeningsceremonies in beveiligde faciliteiten in de VS en Europa. Deze ceremonies omvatten buitengewone procedurele controles: Hardware Security Modules (HSM’s) slaan de privésleutel van de root op, die alleen toegankelijk is wanneer meerdere crypto-functionarissen tegelijkertijd smartcards en pincodes gebruiken. Fysieke beveiligingen omvatten verzegelde tassen, bewaakte kluizen en volledige videodocumentatie.

De eerste ondertekening van rootzones in juli 2010 markeerde de overgang van DNSSEC van theorie naar wereldwijde implementatie in de praktijk. De KSK-rollover van 2018 – waarbij de oorspronkelijke KSK uit 2010 werd vervangen door KSK-2016 – testte het vermogen van het systeem om het fundamentele vertrouwensanker bij te werken. Ondanks uitgebreide voorlichting ondervond ongeveer 0,2% van de oplossers problemen als gevolg van verouderde software of configuratie. Toekomstige rolllovers zijn gepland voor medio 2020.

Recursieve resolvers verkrijgen het vertrouwensanker van de root via softwaredistributies of geautomatiseerde updateprotocollen die door IANA worden onderhouden. Moderne resolversoftware bevat meestal actuele ankers en mechanismen om updates op te halen, zodat de vertrouwensketen intact blijft als sleutels veranderen.

Deze ceremonies lijken misschien ingewikkeld, maar ze bieden een gerechtvaardigde zekerheid. De integriteit van de rootzone vormt de basis van DNSSEC wereldwijd en het gedocumenteerde, controleerbare proces bouwt het vertrouwen op dat deze kritieke infrastructuur met de juiste striktheid werkt.

DNSSEC implementeren op uw domeinen

Klaar om DNSSEC in te schakelen voor uw domeinen? Het proces omvat verschillende fasen, van verificatie tot doorlopend onderhoud.

Vereisten om te bevestigen:

• Uw TLD ondersteunt DNSSEC (controleer de implementatiehulpmiddelen van ICANN)
• Uw registratiehouder accepteert DS-records
• Uw DNS-hostingprovider ondersteunt zone-ondertekening en DNSKEY-beheer

Veel beheerde DNS-providers zoals Cloudflare en AWS Route 53 handelen het ondertekenen automatisch af. Voor zones in eigen beheer hebt u ondertekeningstools nodig die compatibel zijn met uw autoratieve serversoftware.

Typische implementatiestappen:

1. ZSK- en KSK-paren genereren (of providergestuurd ondertekenen inschakelen)
2. De DNS-zone ondertekenen en DNSSEC-handtekeningen lokaal verifiëren
3. DNSKEY-records publiceren (en optioneel CDS/CDNSKEY voor geautomatiseerd DS-beheer)
4. DS-records indienen via de interface van uw registrar
5. Geef propagatietijd en controleer dan de volledige keten

Validatie is net zo belangrijk. Als uw organisatie recursieve resolvers gebruikt, schakel dan DNSSEC-validatie in (bijvoorbeeld dnssec-validation yes in BIND). Test tegen bekende domeinen: goed ondertekende sites zouden de AD (Authenticated Data) vlag moeten teruggeven, terwijl dnssec-failed.org SERVFAIL zou moeten opleveren.

Operationele best practices:

• Controleer de vervaldatum van handtekeningen: RRSIG’s gaan meestal 30 dagen mee. Automatiseer het aftreden ruim voor de vervaldatum.
• Test belangrijke rollovers: Oefen de rollover-procedure in een staging-omgeving voor de productie.
• Waarschuwingen implementeren: Configureer bewaking voor DNSSEC-validatiefouten bij uw resolvers.
• Procedures documenteren: Duidelijke runbooks voorkomen paniek tijdens incidenten of geplande rollovers.

De exacte interfaces verschillen per registrar en provider, dus concentreer u op het begrijpen van de onderliggende taken in plaats van het onthouden van specifieke knopklikken. Het doel is om DNSSEC te implementeren zonder onderbrekingen te veroorzaken – met zorgvuldigevoorbereiding en tests is dit haalbaar.

Beste praktijken voor DNSSEC

Voor een succesvolle implementatie van DNSSEC is meer nodig dan alleen het inschakelen van handtekeningen: er is voortdurende aandacht voor detail en naleving van de beste praktijken in de branche nodig. Domeineigenaars moeten prioriteit geven aan regelmatige sleutelrotatie om het risico op compromittering van sleutels te minimaliseren en ervoor zorgen dat alle privésleutels veilig worden opgeslagen, idealiter met behulp van hardwarebeveiligingsmodules of andere beschermde omgevingen.

Voortdurend toezicht op DNSSEC-validatie is essentieel; dit omvat het bijhouden van vervaldatums voor handtekeningen en het afmelden van records voordat deze verlopen. Het is ook belangrijk om te controleren of alle onderdelen van uw DNS-infrastructuur, autoratieve servers, recursieve resolvers en registrarinterfaces, DNSSEC-implementatie en -validatie volledig ondersteunen.

Testen is een andere cruciale stap. Domeineigenaren moeten regelmatig controleren of hun DNS-gegevens correct worden ondertekend en gevalideerd, met behulp van tools en testdomeinen om zowel succesvolle als mislukte validatiescenario’s te simuleren. Door deze best practices te volgen, kunnen domeineigenaren een veerkrachtige DNS-infrastructuur onderhouden, hun gebruikers beschermen tegen DNS-gebaseerde aanvallen en de voortdurende integriteit en betrouwbaarheid van hun domeinnaamsysteem garanderen.

Conclusie en volgende stappen

DNSSEC transformeert het domeinnaamsysteem van een architectuur die alles vertrouwt in een architectuur met cryptografische verificatie via digitale handtekeningen en een hiërarchische vertrouwensketen die kwetsbaarheden aanpakt die al bestaan sinds DNS in de jaren 80 werd ontworpen. De beschermingsmechanismen-RRSIG-handtekeningen, DNSKEY/DS-koppelingen en geauthenticeerde weigering via NSEC/NSEC3 voorkomen DNS-cache-poisoning en DNS-spoofing-aanvallen die gebruikers anders geruisloos zouden kunnen omleiden. Voor bestaande DNS-records die frauduleuze DNS-gegevens bevatten, weigeren validerende resolvers eenvoudigweg de gemanipuleerde DNS-gegevens volledig.

Ondanks de operationele complexiteit is DNSSEC aanzienlijk volwassener geworden sinds de ondertekening van de root in 2010. De brede ondersteuning van TLD’s, de verbeterde automatisering via CDS/CDNSKEY en de toenemende validatiepercentages van resolvers geven allemaal aan dat het momentum is bereikt. Belangrijke beveiligingsorganisaties bevelen DNSSEC aan voor domeinen waar spoofing ernstige schade kan veroorzaken.

Voor degenen die verantwoordelijk zijn voor de DNS-infrastructuur zijn de volgende praktische stappen:

• Inventariseren welke domeinen en zones momenteel zijn ondertekend
• Plan een gefaseerde implementatie van DNSSEC, te beginnen met kritieke, publiekgerichte services
• Waar mogelijk DNSSEC-validatie inschakelen op interne resolvers
• Procedures voor bewaking en reactie op incidenten voor DNSSEC-fouten opstellen

Andere leermiddelen zijn de belangrijkste DNSSEC RFC’s (4033, 4034, 4035), implementatiehandleidingen van ICANN en regionale netwerkinformatiecentra en testtools zoals DNSSEC Analyzer van Verisign. De weg van inzicht naar actie is duidelijker dan ooit en de beveiligingsvoordelen rechtvaardigen de investering.