DNS-beveiliging · DNSSEC

DNSSEC met de SHA-1-algoritmen 5 en 7: waarom het uw zone niet meer beschermt

Het korte antwoord

RFC 9905 (november 2025) bepaalt dat zones niet meer met RSASHA1 (5) of RSASHA1-NSEC3-SHA1 (7) mogen worden ondertekend, en dat validerende resolvers die handtekeningen als niet-ondersteund moeten behandelen. Uw domein wordt nog steeds opgelost, maar de antwoorden worden niet meer gevalideerd: DNSSEC beschermt u niet meer, zonder dat er ergens een fout verschijnt. De oplossing is een algoritmewissel (rollover), meestal naar 13 (ECDSA P-256).

De algoritmenummers, en wat de RFC's zeggen over ondertekenen met elk ervan

Vind het uwe met dig DNSKEY example.com +short: het derde getal van elk record is het algoritme. In het DS-record bij uw registrar (dig DS example.com +short) is het het tweede getal, en het derde is het digesttype.

NummerNaamGebruik voor ondertekenen
1RSAMD5MUST NOT
3DSAMUST NOT
5RSASHA1MUST NOT (RFC 9905; was NOT RECOMMENDED)
6DSA-NSEC3-SHA1MUST NOT
7RSASHA1-NSEC3-SHA1MUST NOT (RFC 9905; was NOT RECOMMENDED)
8RSASHA256MUST
10RSASHA512NOT RECOMMENDED
13ECDSAP256SHA256MUST
14ECDSAP384SHA384MAY
15ED25519RECOMMENDED
16ED448MAY

SkyQon markeert 1, 3, 5, 6 en 7 als zwak, en ook een DS-record met digesttype 1 (SHA-1), dat evenmin voor delegatie mag worden gebruikt; gebruik digesttype 2 (SHA-256). Bronnen: RFC 8624 §3.1 en §3.3, bijgewerkt door RFC 9905.

Wat er misgaat, en wie het merkt

  • Validerende resolvers controleren uw antwoorden niet meer. RFC 9905 schrijft hun voor RSASHA1 en RSASHA1-NSEC3-SHA1 als niet-ondersteund te behandelen, waardoor uw zone onbeveiligd wordt in plaats van mislukt: antwoorden worden geaccepteerd, en een vervalst antwoord wordt niet meer onderschept. RFC 9905 §2
  • Geen fout, geen storing. Niets stopt met oplossen, dus niemand merkt het. Een monitor die alleen vraagt "staat DNSSEC aan?", blijft groen.
  • Sommige systemen weigeren SHA-1 al. RFC 9905 vermeldt dat de ondersteuning voor het valideren van SHA-1-handtekeningen uit sommige systemen is verwijderd, dus voor hun gebruikers is uw zone vandaag al onbeschermd.
  • DANE gaat mee onderuit. DANE-records voor uw mailservers tellen alleen in een zone die valideert. In een zone die als onbeveiligd wordt behandeld, negeren verzenders ze. RFC 7672 §2.2

Controleer uw DNSSEC-algoritme

De gratis domeincontrole leest uw DS- en DNSKEY-records, vertelt u of de keten vanaf uw registrar valideert, en noemt het algoritme waarmee u ondertekent.

Gratis, zonder account. Wij lezen alleen publieke DNS en wat uw servers laten zien aan iedereen die verbinding maakt.

Zo lost u het op, stap voor stap

  1. Bekijk waarmee u vandaag ondertekent

    Voer dig DNSKEY example.com +short en dig DS example.com +short uit, of de gratis controle. Noteer de algoritmenummers en het digesttype van de DS.

  2. Vraag het eerst aan uw DNS-provider

    De meeste beheerde DNS-providers wisselen het algoritme voor u, op verzoek of met één instelling. Doet de uwe dat, dan is de enige stap die u nog moet zetten misschien de nieuwe DS bij uw registrar.

  3. Onderteken met beide algoritmen

    Voeg nieuwe sleutels met het nieuwe algoritme toe, bijvoorbeeld 13, en onderteken de zone met zowel de oude als de nieuwe sleutels. Publiceer beide sets DNSKEY-records.

  4. Wacht op de caches

    Wacht minstens de DNSKEY-TTL plus de TTL van de handtekeningen, zodat elke resolver beide sets sleutels en handtekeningen heeft gezien.

  5. Vervang de DS bij uw registrar

    Voeg de DS voor de nieuwe sleutel toe met digesttype 2 (SHA-256). Wacht tot de DS-TTL van de bovenliggende zone is verstreken en verwijder dan de oude DS.

  6. Verwijder het oude algoritme

    Zodra de oude DS uit de caches is verdwenen, verwijdert u de oude sleutels en hun handtekeningen. Controleer daarna opnieuw: het resultaat moet het nieuwe algoritme noemen en een keten die valideert.

Veelgemaakte fouten

De sleutels in één stap wisselen

Alleen nieuwe sleutels, terwijl de bovenliggende zone nog de oude DS heeft, breekt de keten. Validerende resolvers weigeren dan helemaal te antwoorden voor uw domein, en dat is een storing.

In het resultaat van SkyQon: de melding “DNSSEC keys are published but our validating resolver did not return AD” wanneer de keten niet valideert.

DNSSEC in de verkeerde volgorde verwijderen

De ondertekening van de zone verwijderen terwijl de DS nog bij de registrar staat, heeft hetzelfde effect: resolvers verwachten handtekeningen en vinden er geen.

In het resultaat van SkyQon: de melding “DS published at the parent but no DNSKEY at the zone apex — broken DNSSEC chain”.

Een DS met digesttype 1 laten staan

Een DS die de SHA-1-digest gebruikt, mag evenmin voor delegatie worden gebruikt. Vervang hem tijdens de algoritmewissel door digesttype 2.

In het resultaat van SkyQon: een bevinding wanneer een DS-record digesttype 1 (SHA-1) gebruikt, ook als er een SHA-256-record naast staat. Die verandert uw score niet en verstuurt geen waarschuwing.

Overstappen naar algoritme 10

RSASHA512 werkt, maar RFC 8624 markeert het als NOT RECOMMENDED voor ondertekenen, en de handtekeningen zijn groot.

In het resultaat van SkyQon: 8 en 10 worden geaccepteerd, met een opmerking dat ECDSA P-256 of Ed25519 de voorkeur heeft voor nieuwe zones. Kies 13 als uw provider het ondersteunt.

Wat SkyQon wel en niet doet

Wat het vindt

Of uw zone ondertekend is, of de keten vanaf uw registrar valideert, welke algoritmenummers uw DS- en DNSKEY-records gebruiken, en of een DS-record de SHA-1-digest gebruikt. 1, 3, 5, 6 en 7 worden als zwak gemarkeerd.

Wat u krijgt

De bevinding in de gratis controle en bij elke scan van een bewaakt domein, met het algoritme bij naam en de stappen voor de algoritmewissel.

Wat het niet is

Wij wijzigen uw sleutels en uw DS-records niet: dat gebeurt bij uw DNS-provider en registrar. De bevinding over de SHA-1-digest verandert uw score niet en verstuurt geen waarschuwing.

DNSSEC en SHA-1: veelgestelde vragen

Is mijn domein offline als het met algoritme 5 of 7 is ondertekend?
Nee. Resolvers die RFC 9905 volgen, behandelen het als niet-ondertekend, dus het wordt nog steeds opgelost. Wat u verliest, is de bescherming tegen vervalste antwoorden die DNSSEC moest bieden.
Naar welk algoritme moet ik overstappen?
13 (ECDSAP256SHA256): de RFC noemt het MUST voor ondertekenen; het is compact en breed ondersteund. 15 (Ed25519) is RECOMMENDED, maar controleer of uw provider en registrar het accepteren. 8 (RSASHA256) is prima als uw provider niets anders aanbiedt.
Wat is het verschil tussen 5 en 7?
Beide zijn RSA met SHA-1. 7 is de variant die met NSEC3 wordt gebruikt, de gehashte vorm van het bewijs dat een naam niet bestaat. RFC 9905 schaft beide af.
NSEC3 hasht namen ook met SHA-1. Is dat ook een probleem?
Dat is een aparte instelling. RFC 9905 gaat over handtekeningalgoritmen; de hash in NSEC3-records is niet wat het verandert.
Hoe lang duurt een algoritmewissel?
Het meeste is wachten op TTL's: de DNSKEY-TTL in uw zone en de DS-TTL bij uw topleveldomein. Reken op een paar dagen, waarvan de meeste wachten.
Kan ik DNSSEC niet gewoon uitzetten?
Dat kan, in de juiste volgorde: verwijder eerst de DS bij de registrar, wacht de TTL ervan af, en verwijder dan de ondertekening. Maar dan heeft de zone helemaal geen bescherming meer, dus een algoritmewissel is de betere oplossing.
Hangt de DANE-controle van SkyQon hiervan af?
Ja. DANE-records tellen alleen in een zone die valideert, dus een zone die als onbeveiligd wordt behandeld, maakt ze nutteloos voor verzenders, ook als de records zelf juist zijn.
Wat verandert RFC 9905 voor DS-records?
Het bepaalt dat RSASHA1 en RSASHA1-NSEC3-SHA1 niet mogen worden gebruikt bij het aanmaken van DS-records, en dat validators zulke DS-records als onbeveiligd moeten behandelen.

Zie welk algoritme uw zone beschermt.

De gratis controle noemt uw DNSSEC-algoritme en vertelt u of de keten valideert. Voeg het domein toe aan het gratis abonnement en elke scan controleert het opnieuw.