DNSSEC in gewone taal

Module 8: Veiligheid en problemen oplossen · Leestijd: 11 minuten

Leerdoel: Na deze les kun je in gewone taal uitleggen wat DNSSEC beschermt, hoe de vertrouwensketen werkt en waarom het bij een verhuizing kan misgaan.

Kernbegrippen: DNSSEC, handtekening (RRSIG), sleutel (DNSKEY), DS-record, vertrouwensketen, validerende resolver, SERVFAIL

Het probleem: hoe weet je dat een antwoord echt is?

In module 1 zag je dat een resolver een reeks vragen stelt: aan de root, aan de TLD-server en aan de gezaghebbende nameserver. Het antwoord dat terugkomt, wordt geloofd en in de cache gezet. Maar het gewone DNS controleert niet of dat antwoord echt van de juiste nameserver komt. Een aanvaller die een vals antwoord weet te sturen voordat het echte antwoord aankomt, kan een resolver laten geloven dat example.com op 203.0.113.66 woont in plaats van op 192.0.2.10. Dat heet cache poisoning: de cache is "vergiftigd" en iedereen die die resolver gebruikt, komt op de verkeerde server uit.

DNSSEC (DNS Security Extensions) lost dat op door antwoorden te ondertekenen. De resolver kan dan controleren of een antwoord echt is en onderweg niet is veranderd.

Wat DNSSEC wel en niet doet

Dit is het belangrijkste om te onthouden:

Een handtekening werkt als een zegel op een envelop: iedereen kan de brief lezen, maar je ziet meteen of iemand hem heeft opengemaakt.

De drie onderdelen

DNSSEC voegt een paar recordtypes toe. Je hoeft ze niet zelf te maken (dat doet je DNS-beheerder of paneel), maar je komt ze tegen:

• DNSKEY: de publieke sleutel van de zone. Hiermee kan iedereen de handtekeningen controleren.
• RRSIG: de handtekening bij een groep records. Elk A-, MX- of TXT-antwoord krijgt een RRSIG mee. Een handtekening heeft een begin- en einddatum: de zone moet dus regelmatig opnieuw ondertekend worden.
• DS (Delegation Signer): een korte "vingerafdruk" van de sleutel van jouw zone. Die staat niet in je eigen zone, maar bij de ouder: voor example.com dus bij de registry van .nl.

Zo ziet een ondertekend antwoord eruit (ingekort):

$ dig example.com A +dnssec +noall +answer
example.com.  3600  IN  A      192.0.2.10
example.com.  3600  IN  RRSIG  A 13 2 3600 20261119000000 20261029000000 30794 example.com. s7yJ5o...

In de RRSIG zie je onder andere het algoritme (13 = ECDSA P-256 met SHA-256), de einddatum (19 november 2026), de begindatum en het nummer van de sleutel (30794).

De vertrouwensketen

Waarom staat de DS bij de ouder? Omdat een sleutel in je eigen zone niets bewijst: een aanvaller zou ook een eigen sleutel kunnen meesturen. Daarom gaat de controle van boven naar beneden:

1. De resolver vertrouwt de sleutel van de root. Die zit ingebouwd in elke validerende resolver (het trust anchor).
2. De root heeft een DS voor .nl, ondertekend met de rootsleutel. Daarmee weet de resolver welke sleutel .nl hoort te hebben.
3. De .nl-zone heeft een DS voor example.com, ondertekend met de .nl-sleutel.
4. De zone example.com heeft een DNSKEY die past bij die DS, en daarmee zijn alle RRSIG's te controleren.

Elke schakel bewijst de volgende. Breekt één schakel, dan is de hele keten onbetrouwbaar.

Een validerende resolver (de meeste grote publieke resolvers, en steeds meer providers) loopt die keten na. Klopt hij, dan krijg je het antwoord. Klopt hij niet, dan geeft de resolver geen antwoord, maar de foutstatus SERVFAIL. Voor de bezoeker lijkt de site dan gewoon "niet te bestaan", terwijl je records misschien prima zijn.

Je kunt dat zelf zien met een domein dat expres kapot is gemaakt:

$ dig dnssec-failed.org A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

Met +cd ("checking disabled") vraag je de resolver de controle over te slaan. Krijg je dan wel een antwoord, dan weet je zeker dat het aan DNSSEC ligt:

$ dig +cd dnssec-failed.org A @1.1.1.1 +short
96.99.227.255

Een domein zonder DNSSEC (geen DS bij de ouder) geeft geen SERVFAIL: het is dan gewoon niet ondertekend en wordt als "onbeveiligd" doorgelaten.

Waar het misgaat: verhuizen en sleutelwissels

DNSSEC zelf gaat bijna nooit kapot. Het gaat mis als de DS bij de registry niet meer past bij de sleutel in de zone. Dat gebeurt vooral:

• Bij een verhuizing van nameservers of DNS-partij. De nieuwe partij ondertekent met een eigen sleutel, maar bij de registry staat nog de DS van de oude partij. Gevolg: SERVFAIL voor iedereen met een validerende resolver. Dit is de klassieke fout na een verhuizing.
• Bij een sleutelwissel waarbij de nieuwe DS niet (op tijd) naar de registry is gestuurd.
• Als de handtekeningen verlopen, omdat de zone niet meer opnieuw ondertekend wordt.

De veilige volgorde bij een verhuizing is daarom:

1. Haal de DS weg bij de registry (of laat de nieuwe partij een DS aanleveren die je erbij zet).
2. Wacht tot de TTL van de oude DS voorbij is.
3. Wissel de nameservers.
4. Zet DNSSEC aan bij de nieuwe partij en laat de nieuwe DS bij de registry plaatsen.

Veel registrars en panelen regelen dit tegenwoordig automatisch zolang domein en DNS bij dezelfde partij staan. Staan ze bij verschillende partijen, dan moet je de DS zelf overbrengen.

Zelf controleren: DNSViz, Zonemaster en internet.nl

Je hoeft de keten niet met dig na te lopen. Er zijn gratis tools die het voor je doen en de uitkomst laten zien.

DNSViz (https://dnsviz.net/) tekent de hele keten als plaatje. Zo gebruik je het:

1. Typ op de voorpagina de domeinnaam in het zoekvak (alleen de naam, zonder https:// en zonder www) en klik op Go.
2. DNSViz toont de laatste analyse. Is die oud, of heb je net iets gewijzigd, klik dan op Update now. Na een paar seconden zie je het plaatje.
3. Lees het plaatje van boven naar beneden: bovenaan de root (.), daaronder de TLD (bijvoorbeeld nl), onderaan jouw domein. Elke zone is een kader.

Wat je in het plaatje ziet:

De keten volg je zo: DS (bij de ouder) wijst naar de DNSKEY (in jouw zone), en die DNSKEY zet met een RRSIG zijn handtekening onder de records. Dat is precies de keten uit deze les, maar dan getekend.

De kleuren vertellen of het klopt:

• Blauw: veilig (secure). De keten loopt ononderbroken van de root naar dit onderdeel.
• Zwart: niet ondertekend (insecure). Er is geen DS, dus er is niets te controleren. Dat is geen fout, het domein gebruikt gewoon geen DNSSEC.
• Rood: kapot (bogus). Een DS past niet bij een sleutel, of een handtekening klopt niet. Een validerende resolver geeft dan SERVFAIL.
• Paars (bij een handtekening): de handtekening is verlopen of nog niet geldig. De zone wordt niet meer opnieuw ondertekend.
• Geel: een waarschuwing, bijvoorbeeld een nameserver die niet goed antwoordt, of een algoritme dat de tool niet kent.
• Grijs en gestippeld: er wordt naar een sleutel verwezen die er niet is. Zie je een gestippelde DNSKEY onder een DS, dan staat er bij de ouder nog een DS van een oude sleutel: de klassieke fout na een verhuizing.

Naast een onderdeel kan een driehoekje (waarschuwing) of een rond foutteken staan. Ga er met je muis op staan, of kijk in de lijst onder het plaatje: daar staat in woorden wat er mis is.

Probeer het eens met sidn.nl (alles blauw) en met dnssec-failed.org (rood, met een gestippelde sleutel onder de DS).

Andere tools die hetzelfde vanuit een andere hoek bekijken:

• Zonemaster (https://zonemaster.net/): controleert je hele zone zoals een registry dat doet, ook DNSSEC. De uitkomst is een lijst met groen (goed), oranje (waarschuwing) en rood (fout).
• internet.nl (https://internet.nl/): de website- en e-mailtest laten onder andere zien of DNSSEC voor je domein en voor je mailservers in orde is, met groene vinkjes of rode kruizen.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/): loopt de keten stap voor stap af en zet bij elke stap een groen vinkje of een rood kruis. Handig als je één concrete fout zoekt.

Gebruik ze na elke wijziging aan DNSSEC, en zeker vóór en na een verhuizing. Laat de tool rustig opnieuw analyseren: ook deze tools werken met caches en TTL's.

In de praktijk: zo ziet het eruit in een paneel

In Mijn WebOké zet je DNSSEC aan bij een domein onder DNSSEC/DANE; het paneel maakt de sleutels en stuurt de DS naar de registry. In DirectAdmin en bij externe partijen zoals Cloudflare heet het meestal "DNSSEC inschakelen"; Cloudflare toont je dan een DS-record dat je zelf bij je registrar moet invullen. Andere panelen werken vergelijkbaar: er is altijd een stap "sleutels maken" (bij de DNS-partij) en een stap "DS bij de registry" (bij de registrar).

Samenvatting

• DNSSEC ondertekent DNS-antwoorden zodat een resolver kan controleren dat ze echt zijn. Het versleutelt niets.
• DNSKEY is de sleutel, RRSIG de handtekening, DS de vingerafdruk bij de ouder.
• De controle loopt als een keten van de root naar jouw domein. Breekt een schakel, dan geeft een validerende resolver SERVFAIL.
• Bijna alle problemen ontstaan doordat de DS bij de registry niet meer past, vaak na een verhuizing.
• Met dig +cd zie je of een probleem door DNSSEC komt.
• DNSViz tekent de keten: blauw is veilig, zwart is niet ondertekend, rood is kapot. Zonemaster, internet.nl en de Verisign DNSSEC Debugger zijn goede tweede meningen.

Quiz

Opdracht

Zoek uit welke van twee domeinen DNSSEC goed heeft en welke expres kapot is gemaakt: sidn.nl en dnssec-failed.org. Vraag voor beide het DS-record op en het A-record via een validerende resolver (bijvoorbeeld 1.1.1.1 of 9.9.9.9), met dig of een online tool. Vul in: het sleutelnummer (key tag, het eerste getal) van de DS van sidn.nl, en de status die je krijgt voor dnssec-failed.org. Opdrachtcode Z8.1.

Z8.1b (opzoeken met DNSViz). Analyseer nlnetlabs.nl in DNSViz (https://dnsviz.net/, typ de naam in en klik op Go; klik op Update now als de analyse oud is). Lees het plaatje en vul in: (1) de status van nlnetlabs.nl (veilig, niet ondertekend of kapot), (2) het algoritmenummer van de DNSKEY-records (staat in elk ovaal als alg=), (3) hoeveel DNSKEY-ovalen er in de zone van nlnetlabs.nl staan, (4) het sleutelnummer (id=) van de grijs gevulde DNSKEY waar de DS naar wijst, en (5) de status die DNSViz geeft voor dnssec-failed.org. De controle vraagt dezelfde gegevens live op. Opdrachtcode Z8.1b.

O8.1 (oefenzone, volgt later). In de oefenzone komen twee DNSSEC-demozones: één met een goede keten en één die expres kapot is. Je laat ze allebei door DNSViz analyseren en verklaart het verschil. Opdrachtcode O8.1.

Verder lezen

Deze artikelen beschrijven de stappen in de panelen van WebOké; bij andere partijen heten de knoppen anders.

• WebOké handleiding 5.8: DNSSEC en DANE
• Wat is DNSSEC?
• DNSSEC activeren
• Website of e-mail werkt niet na een verhuizing of DNS-wijziging: controleer je domein