DNSSEC-installatiehandleiding voor DNScale — Stap voor stap

Deze gids leidt u door het inschakelen van DNSSEC op een DNScale-zone, het publiceren van het DS-record bij uw registrar, het verifiëren van de vertrouwensketen, en het afhandelen van de meest voorkomende faalmodi. Als u eerst de conceptuele achtergrond wilt, lees Wat is DNSSEC? en Hoe DNSSEC werkt.

Voor u begint

Bevestig drie dingen:

1. Uw zone is gedelegeerd aan DNScale. De NS-records bij uw registrar wijzen naar DNScale-nameservers, en dig NS uwdomein @1.1.1.1 retourneert de DNScale-set. Als u nog niet bent gemigreerd, doe dat eerst — zie DNS-delegatie voor DNScale-regio's.
2. Uw TLD ondersteunt DNSSEC. Alle gTLD's (.com, .net, .org enz.) en de meeste ccTLD's (.de, .fr, .nl, .eu, .uk) ondersteunen DNSSEC al jaren. Een handvol oudere of kleinere TLD's niet — controleer het IANA TLD-rapport bij twijfel.
3. Uw registrar ondersteunt DS-publicatie. De meeste grote registrars wel. Als de uwe niet, zult u de domein moeten overdragen naar een DNSSEC-bekwame registrar of accepteren dat DNSSEC niet beschikbaar is voor dat domein.

Stap 1 — DNSSEC inschakelen in DNScale

Vanuit het dashboard

1. Open uw zone in het DNScale-dashboard.
2. Klik op het tabblad Beveiliging (of DNSSEC afhankelijk van de dashboardversie).
3. Klik op DNSSEC inschakelen. DNScale genereert een nieuwe CSK met ECDSA P-256 en begint de zone te ondertekenen. Dit duurt enkele seconden.
4. Het dashboard toont het DS-record dat u bij uw registrar moet publiceren:

example.com.   86400   IN   DS   12345 13 2 7c89aa1f3e7b4d8b...

Let op de vier velden: Key tag (12345), Algoritme (13 = ECDSA P-256), Digesttype (2 = SHA-256), Digest (de hex-string). Verschillende registrar-UI's vragen deze in verschillende combinaties — de meeste vragen alle vier; sommige vragen om de volledige DS-recordstring; enkele berekenen zelf de digest en vragen alleen om de DNSKEY publieke sleutel.

De DNScale-API gebruiken

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/dnssec/enable" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json"

Het antwoord bevat de DS-recordvelden die u bij de registrar nodig heeft:

{
  "enabled": true,
  "ds_records": [
    {
      "key_tag": 12345,
      "algorithm": 13,
      "digest_type": 2,
      "digest": "7c89aa1f3e7b4d8b..."
    }
  ]
}

Met Terraform

resource "dnscale_zone_dnssec" "example" {
  zone_id   = dnscale_zone.example.id
  enabled   = true
}

Na terraform apply legt de resource de DS-recordvelden bloot als outputs die u kunt doorgeven aan een registrar-provider (als uw registrar ook door Terraform wordt beheerd) of vastleggen voor handmatige invoer.

Met DNSControl

D("example.com", DNSCALE,
  AUTODNSSEC_ON,
  // ... uw records
);

De AUTODNSSEC_ON-directive van DNSControl activeert ondertekening aan de DNScale-providerkant. Het DS-record komt beschikbaar in de output van dnscontrol get-zones.

Stap 2 — Het DS-record publiceren bij uw registrar

Dit is de enige handmatige stap die de DNS-leverancier (nog) niet voor u kan doen — zie CDS/CDNSKEY-automatisering hieronder. De exacte UI varieert per registrar; hier de meest voorkomende.

Generiek patroon

De meeste registrar-dashboards hebben een DNSSEC- of Geavanceerde DNS-sectie per domein. Doorgaans:

1. Klik op DS-record toevoegen.
2. Voer de vier velden in: Key tag, Algoritme, Digesttype, Digest.
3. Sla op.

Sommige registrars vragen om de volledige DS-recordstring (bv. 12345 13 2 7c89aa1f...) — plak de hele regel. Andere laten u de DNSKEY publieke sleutel plakken en berekenen zelf de DS — beide werken; gebruik wat de registrar verkiest.

Cloudflare Registrar

Domain → DNS → DNSSEC → Inschakelen → DS-record toevoegen. Plak de vier velden. Cloudflare publiceert de DS binnen minuten op de TLD.

Gandi

Domains → uw domein → DNSSEC → Sleutel toevoegen. Plak de velden; Gandi publiceert doorgaans binnen 30 minuten.

Namecheap

Domain List → Manage → Advanced DNS → DNSSEC → Add Key. Plak de velden en sla op.

OVH

Domein → DNSSEC → Toevoegen → DNSSEC activeren. Plak de velden. OVH verspreidt binnen 30 minuten voor de meeste TLD's.

IONOS / 1&1

Domein → SSL & DNSSEC → DNSSEC → Activeren → Een record toevoegen. Plak de velden. IONOS publiceert doorgaans binnen een uur.

GoDaddy

Domein → DNS → DNSSEC. Sleutel toevoegen. Plak de velden. Publicatietijd varieert; reken op 24–48 uur.

Domein bij een register-only registrar

Sommige ccTLD-registers accepteren DS-records direct via webinterface of EPP. De registrar zou ze normaal doorgeven — zo niet, neem contact op met de support van het register.

Stap 3 — De keten end-to-end verifiëren

Zodra u de DS heeft gepubliceerd, verifieer dat de keten op elke schakel werkt. Het meest betrouwbare enkele commando:

dig +dnssec example.com @1.1.1.1

Zoek twee dingen in het antwoord:

1. De AD-vlag in de header — ;; flags: qr rd ra ad; — bevestigt dat de resolver de keten succesvol heeft gevalideerd.
2. RRSIG-records in de antwoordsectie, gekoppeld aan elk datarecord.

Als de AD-vlag ontbreekt maar RRSIG-records aanwezig zijn, valideert de resolver niet (probeer 8.8.8.8 of 9.9.9.9). Als RRSIG-records ontbreken, heeft ondertekening geen effect gehad — controleer Stap 1 opnieuw.

De DS bij de bovenliggende zone verifiëren

dig DS example.com @a.gtld-servers.net.

Voor .com, bevraag direct de gTLD-servers. Voor andere TLD's, vind de NS van de bovenliggende via dig NS .com @a.root-servers.net. of gebruik dig +trace. Het verwachte antwoord is uw DS-record, exact zoals u het heeft ingediend.

Als de DS niet binnen 48 uur bij de bovenliggende verschijnt, neem contact op met uw registrar — de publicatie is waarschijnlijk mislukt.

Een visualizer gebruiken

Voor een volledig beeld tekent de DNSViz-visualizer de hele keten van root naar uw zone en licht eventuele breuken uit. De Verisign DNSSEC Debugger doet hetzelfde in een andere presentatie.

Stap 4 — Testen vanuit meerdere resolvers

Verschillende resolvers cachen verschillend en rollen updates uit met verschillende snelheden. Na de initiële verificatie, bevraag vanuit ten minste drie:

dig +dnssec example.com @1.1.1.1     # Cloudflare
dig +dnssec example.com @8.8.8.8     # Google
dig +dnssec example.com @9.9.9.9     # Quad9

Als alle drie de AD-vlag tonen, bereikt uw DNSSEC-deployment de publieke resolverflota.

Veelvoorkomende faalmodi en hoe te herstellen

DS bij registrar komt niet overeen met DNSKEY

Symptoom: dig +dnssec uwdomein retourneert SERVFAIL. DNSViz toont een rode link tussen de DS van de bovenliggende en uw DNSKEY.

Oorzaak: Verkeerde digest, verkeerd algoritme of verkeerde key tag ingevoerd bij de registrar.

Oplossing: Haal de juiste DS opnieuw op uit het DNScale-dashboard. Update bij de registrar. Wacht op TLD-verspreiding. Als de registrar-UI uw bewerking niet accepteert, verwijder eerst de slechte DS en voeg opnieuw toe.

Meerdere verouderde DS-records bij de registrar

Symptoom: Validatie werkt onregelmatig — sommige resolvers markeren AD het antwoord, andere SERVFAIL.

Oorzaak: Een eerdere DNSSEC-activering liet oude DS-records achter die niet meer overeenkomen met enige huidige DNSKEY.

Oplossing: Verwijder bij de registrar elke DS die niet in de huidige DNScale DS-recordlijst voorkomt. Houd alleen de DS van de momenteel actieve KSK.

TLD accepteert de DS niet

Symptoom: Registrar-UI weigert de DS of toont deze als "in afwachting" voor onbepaalde tijd.

Oorzaak: De TLD ondersteunt nog geen DNSSEC (zeer zeldzaam in 2026), of er is een vertraging aan de registerkant.

Oplossing: Controleer het IANA TLD-rapport op DNSSEC-ondersteuningsstatus. Indien niet ondersteund, kunt u DNSSEC niet inschakelen voor dat domein; overweeg overdracht naar een TLD die het ondersteunt. Indien ondersteund maar vastzittend, neem contact op met de registrar-support.

Ondertekening uitgeschakeld voordat DS werd verwijderd

Symptoom: Domein retourneert SERVFAIL van validerende resolvers; niet-validerende resolvers blijven normaal oplossen.

Oorzaak: De volgorde van bewerkingen was verkeerd — het DS-record bij de bovenliggende verwijst nu naar een sleutel die niet meer in uw zone bestaat.

Oplossing: Schakel DNSSEC opnieuw in in DNScale (waardoor ondertekening wordt hersteld met dezelfde key tags indien mogelijk), of verwijder de DS bij de registrar. De juiste volgorde voor permanente uitschakeling is: DS verwijderen → 48u wachten → ondertekening uitschakelen.

Voorgecachte negatieve antwoorden blijven hangen

Symptoom: Na het corrigeren van een DNSSEC-misconfiguratie zien sommige gebruikers nog enige tijd SERVFAIL.

Oorzaak: Validerende resolvers cachen validatiefouten (doorgaans tot 5 minuten). Publieke resolvers die RFC 8767 stale-data serving draaien kunnen verouderde fouten langer vasthouden.

Oplossing: Wacht. De gecachte fouten verlopen; niets aan uw kant verandert de timing. Verifiëren vanuit een nieuwe recursieve resolver (dig +dnssec uwdomein @1.0.0.1 in plaats van @1.1.1.1) bevestigt of de onderliggende staat nu goed is.

Optioneel: De DS automatiseren via CDS/CDNSKEY

RFC 7344 en RFC 8078 definiëren CDS- en CDNSKEY-records — child-side records die de bovenliggende vertellen welke DS-records te publiceren. Een registrar die CDS/CDNSKEY-scanning ondersteunt kan DS-wijzigingen automatisch oppikken zonder handmatige invoer.

Ondersteuning is ongelijk:

• ✅ Cloudflare Registrar — volledige CDS-automatisering
• ✅ Gandi — ondersteunt CDS voor sommige TLD's
• ⚠️ Meeste anderen — handmatige DS-beheer nog
• ❌ Enkele legacy-registrars — geen DNSSEC-ondersteuning

DNScale publiceert automatisch CDS- en CDNSKEY-records wanneer DNSSEC is ingeschakeld. Als uw registrar CDS-scanning ondersteunt, is geen handmatige DS-invoer nodig — DS-rotaties tijdens sleutelrollover gebeuren zonder uw betrokkenheid.

Wat hierna gebeurt — Automatische operaties

Zodra DNSSEC is ingeschakeld op een DNScale-zone:

• Handtekeningen verversen continu. RRSIG-records worden voor verloop opnieuw ondertekend; resolvers zien verse handtekeningen op elke query.
• Sleutelrotatie gebeurt volgens schema. ZSK roteert vaker (indien gescheiden van KSK); KSK roteert zelden (elke paar jaar). Met CSK (de standaard) betreffen rotaties de registrar — DNScale stuurt u een melding wanneer registrar-actie nodig is.
• Algoritme-upgrades zijn gecoördineerde rolls. Als de industrie verschuift (bv. naar Ed25519), voert DNScale een algoritme-rotatie uit zonder zonegegevens-downtime.
• DS-record-updates tijdens rotatie: met CDS-automatisering wordt de DS van de bovenliggende geüpdatet zonder uw betrokkenheid; zonder dit stuurt DNScale u een melding dat een nieuwe DS gepubliceerd moet worden.

U zou na de initiële installatie niet meer aan DNSSEC moeten hoeven denken — totdat u besluit te migreren of de UX van de registrar verandert.

Referenties

• RFC 4033/4034/4035 — DNSSEC-kernspecificatie
• RFC 7344 — Automating DNSSEC delegation trust maintenance (CDS/CDNSKEY)
• RFC 8078 — Managing DS records from the parent via CDS/CDNSKEY
• RFC 8901 — Multi-Signer DNSSEC Models (voor multi-provider deployments)
• IANA Root Trust Anchors
• DNSViz visualizer
• Verisign DNSSEC Debugger

Gerelateerde lectuur

• Wat is DNSSEC? — top-of-funnel introductie
• Hoe DNSSEC werkt — KSK/ZSK/DS/DNSKEY-mechaniek
• DNSSEC-sleutelbeheer — operationele rotatieprocedures
• Multi-provider DNS-deployment — een tweede DNS-leverancier veilig toevoegen met DNSSEC
• DNS-delegatie voor DNScale-regio's — uw zone naar DNScale wijzen voordat u DNSSEC inschakelt
• DNS-cache-poisoning — de aanval die DNSSEC verslaat
• NIS2 en DNS-naleving — DNSSEC als regelgevende controle