Cloudflare heeft de ondertekening van DNSSEC-handtekeningen gemaakt met ML-DSA-44 ingeschakeld op haar openbare DNS-dienst 1.1.1.1, een van de gestandaardiseerde post-quantum algoritmen door het National Institute of Standards and Technology (NIST) in de VS. Deze wijziging versleutelt geen DNS-queries en maakt het internet niet resistanter tegen quantumcomputers, maar introduceert een essentiële stap zodat DNSSEC kan blijven controleren op de echtheid van records wanneer de huidige openbare sleutels niet langer veilig zijn.
De kern van Cloudflare’s post-quantum DNS-sleutels in 30 seconden
- De resolver 1.1.1.1 kan nu DNSSEC-handtekeningen met ML-DSA-44 valideren.
- ML-DSA-44 is ontworpen om bestand te zijn tegen bekende aanvallen door toekomstige, krachtigere quantumcomputers.
- Een handtekening neemt 2.420 bytes in beslag, tegenover slechts 64 bytes bij ECDSA P-256.
- Deze grootte overtreft op zichzelf de gebruikelijke UDP-limieten voor DNS en kan nodig maken dat TCP wordt gebruikt.
- Er bestaat nog geen volledige post-quantum DNSSEC-keten van de root tot de domeinen.
Deze verandering heeft ook een belangrijke nuance. Cloudflare gebruikt 1.1.1.1 niet om DNS-responses te ondertekenen die naar gebruikers worden gestuurd, zoals de eenvoudige uitleg van het aankondigingsbericht zou kunnen doen vermoeden. In plaats daarvan heeft de resolver geleerd om de ML-DSA-44-handtekeningen te valideren die gepubliceerd worden door DNS-zones die dit nieuwe algoritme gebruiken.
Dit is een belangrijke technische onderscheid.
In DNSSEC behoren de handtekeningen bij de zone-records en worden ze gegenereerd door het autoritatieve gedeelte. De resolver controleert vervolgens de cryptografische keten om te bevestigen dat de reactie authentiek is en niet is gewijzigd.
Cloudflare heeft onthuld dat haar eerste stap ligt in deze tweede fase: dat 1.1.1.1 het nieuwe algoritme kan valideren. Na verloop van tijd wil het bedrijf ondersteuning toevoegen voor ML-DSA-44-handtekeningen in Cloudflare’s Authoritative DNS en voor de bijbehorende DS-records in Cloudflare Registrar.
DNSSEC verschaft geen encryptie: het bevestigt de echtheid van de antwoorden
Traditioneel is het DNS-systeem zonder cryptografische mechanismen ontworpen voor naamresolutie.
Dat leidde tot bekende aanvallen zoals DNS spoofing en cache poisoning, waarbij een aanvaller valse antwoorden probeert te injecteren zodat een legitieme domein naar een afwijkend IP-adres resolveert.
DNS Security Extensions (DNSSEC) pakt dit probleem aan met digitale handtekeningen.
Een ondertekende zone publiceert DNSKEY-records met de openbare sleutels en RRSIG-records met de bijbehorende handtekeningen. Een DNSSEC-validatorsysteem kan de vertrouwensketen volgen vanaf de geraadpleegde domein tot aan de bovenliggende zones.
Het doel is om de vraag te beantwoorden: Zijn de ontvangen gegevens echt diegene die door de zonebeheerder zijn gepubliceerd?
DNSSEC beantwoordt niet de vraag: Kan iemand zien welke domeinnaan de gebruiker opvraagt?
Voor confidentiality worden mechanismen zoals DNS over HTTPS (DoH) en DNS over TLS (DoT) gebruikt, die communicatie tussen client en resolver versleutelen.
De functies verschillen:
| Technologie | Wat levert het op |
|---|---|
| Traditioneel DNS | Naamresolutie |
| DNSSEC | Authenticiteit en integriteit |
| DNS over HTTPS | Encryptie tussen client en resolver via HTTPS |
| DNS over TLS | Encryptie tussen client en resolver via TLS |
| DNSSEC + ML-DSA-44 | Authenticiteit voorbereid op toekomstige quantumaanvallen |
Daarom is beweren dat “DNS UDP gebruikt en geen cryptografie heeft” een te eenvoudige samenvatting van de huidige stand van DNS. DNS kan namelijk zowel via UDP als TCP werken, naast versleutelde transporten zoals DoH en DoT. DNSSEC biedt al jaren cryptografische authenticatie.
Het nieuwe zit in welke cryptografie DNSSEC gebruikt.
Het quantumprobleem van RSA en ECDSA
De huidige implementaties van DNSSEC kunnen verschillende algoritmes gebruiken, waaronder RSA en ECDSA.
Hun veiligheid is gebaseerd op wiskundige problemen die met klassieke computers zeer kostbaar op te lossen zijn.
Het probleem is dat een grote, effectieve quantumcomputer met Shor’s algoritme deze problemen zou kunnen oplossen, en dus de beveiliging zou breken.
Zo’n quantumcomputer zou systemen kunnen ondermijnen die afhankelijk zijn van de factorisatie van gehele getallen of Discrete Logarithmes, wat RSA en elliptische curve cryptografie aantast.
Die cryptografisch relevante quantumcomputer bestaat momenteel niet.
De overgang wordt voorbereid vóór dat zo’n computer bestaat, omdat het implementeren van nieuwe algoritmes op internet jaren kost.
Cloudflare benadrukt dat DNSSEC een bijkomende moeilijkheid heeft. De vertrouwensketen gaat door verschillende organisaties en niveaus:
Root DNS
│
▼
TLD (.com, .nl, .org...)
│
▼
Domein
│
▼
Getekende DNS-records
│
▼
Validatie-resolverOm een echt post-quantum keten te realiseren, is niet genoeg dat een domein ML-DSA-44 gebruikt. De bovenliggende zone moet de benodigde informatie kunnen publiceren, registrars moeten het accepteren, de records moeten het ondersteunen, resolvers moeten het verifiëren, en uiteindelijk moet ook de DNS root een post-quantum vertrouwensketen hebben.
Cloudflare kondigt dat momenteel nog niet aan.
1.1.1.1 is een van de eerste stappen op dat pad.
ML-DSA-44 brengt een onverwacht probleem: de gigantische handtekeningen
Post-quantum cryptografie heeft een belangrijke trade-off: de omvang van de handtekeningen.
Cloudflare vergelijkt drie configuraties:
| Algorithmus | Openbare sleutel | Ondertekent |
|---|---|---|
| RSA-2048/SHA-256 | 260 bytes | 256 bytes |
| ECDSA P-256 | 64 bytes | 64 bytes |
| ML-DSA-44 | 1.312 bytes | 2.420 bytes |
Een ML-DSA-44-handtekening is bijna 38 keer groter dan een ECDSA P-256-handtekening.
Het voorbeeld van onderzoeker Bill Buchanan laat dit direct zien met dig. Bij het raadplegen van het testdomein valid.mldsa44.dnstest.dev bevat het DNSKEY-record een ML-DSA-44 openbare sleutel van 1.312 bytes.
Een DNSSEC-query naar de Cloudflare-resolver kan bijvoorbeeld met:
dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssecDe respons bevat een RRSIG met algoritme DNSSEC 18, toegewezen aan ML-DSA-44.
En hier ligt het operationele probleem.
Traditioneel gebruikt DNS UDP-pakketten tot 512 bytes. Later werd met EDNS(0) onderhandeld over grotere responses, maar veel systemen gebruiken conservatief 1.232 bytes voor UDP-ladingen om fragmentatieproblemen, vooral bij IPv6, te voorkomen.
RFC 9715 adviseert nu dat DNS-over-UDP niet groter dan 1.400 bytes zou moeten zijn.
Een enkele ML-DSA-44-handtekening neemt 2.420 bytes in beslag.
Dat past niet.
Een DNS-query die eerder via UDP ging, kan nu via TCP eindigen
Dit is direct te zien met dig.
In het testvoorbeeld van Buchanan verschijnt:
;; Truncated, retrying in TCP mode.De server stuurt een afgekapt antwoord dat de resolver opnieuw probeert via TCP.
Dit betekent niet dat DNS via TCP ongebruikelijk of fout is. Het is al decennia een onderdeel van het protocol.
Maar het wordt operatief significant wanneer dit vaker voorkomt.
Met een post-quantum handtekening kunnen onder meer toenemen:
- het verkeer door bepaalde resoluties;
- het aantal queries dat TCP vereist;
- het geheugengebruik voor caching;
- de rekenlast voor verificaties;
- de belasting van autoritatieve servers en resolvers.
DNSKEY-records kunnen nog groter worden, omdat tijdens overgangsperiodes niet meteen de traditionele sleutels worden ingetrokken.
Een zone kan bijvoorbeeld gelijktijdig publicaties hebben zoals:
ECDSA DNSKEY
ML-DSA-44 DNSKEY
ECDSA RRSIG
ML-DSA-44 RRSIGDit houdt de compatibiliteit met oudere resolvers in stand, maar verdrievoudigt de grootte van bepaalde antwoorden.
Tijdens key-rollovers, waarbij meerdere sleutels gelijktijdig worden gebruikt, kunnen de data nog groter worden.
Eendracht met ECDSA en de downgrade-aanval
Het gelijktijdig gebruik van klassieke en post-quantum cryptografie creëert een minder zichtbaar probleem.
Stel dat een zone zowel ECDSA als ML-DSA-44 publiceert.
Een ouder resolversysteem gebruikt ECDSA omdat het niet begrijpt wat ML-DSA-44 is. Een modern systeem kan mogelijk ML-DSA-44 accepteren en valideren.
Ze zullen gedurende jaren naast elkaar bestaan.
Maar als in de toekomst ECDSA zou kunnen worden gebroken door een quantumcomputer, dan kan een aanvaller proberen in de response elementen van ML-DSA-44 te verwijderen en alleen een valse ECDSA-keten te tonen.
Een modern resolver zou dit kunnen interpreteren als dat de zone nog het oude algoritme gebruikt en de post-quantum ondertekening is weggelaten.
Dit wordt een downgrade-aanval.
Cloudflare heeft een specifiek beleid geïntroduceerd om dat te voorkomen.
Wanneer een DS-record, dat een algoritme ondersteunt dat post-quantum is, wordt geïdentificeerd, vereist de resolver dat er minstens één geldige, post-quantum verificatieroute bestaat. Een juiste gewone handtekening wordt dan niet meer als voldoende gezien.
Deze beleidsregel is strenger dan de traditionele DNSSEC-werkwijze.
Het probleem wordt echter opnieuw zichtbaar als hogere lagen van de keten nog afhankelijk blijven van klassieke cryptografie. Daarom moet de volledige keten uiteindelijk tot aan de DNS-root post-quantum-proof worden.
ML-DSA-44 krijgt al algoritmenummer 18 in DNSSEC
ML-DSA is afgeleid van de algoritmengroep eerder bekend als CRYSTALS-Dilithium en door NIST gestandaardiseerd als onderdeel van de overgang naar post-quantum cryptografie.
Voor gebruik in DNSSEC was het nodig om sleutels en handtekeningen te definiëren in DNS-records.
ML-DSA-44 heeft nu het algoritmenummer 18 in DNSSEC, waarmee het klaar is voor interoperabele eerste implementaties.
Parallel daaraan is er werk gaande binnen de Internet Engineering Task Force (IETF). Drafts over het gebruik van ML-DSA in DNSSEC bestaan, evenals voorstellen zoals ML-DSA-MTL, dat ondertekening met Merkle-structuren combineert om alternatieven te bestuderen die passen bij DNS-specifieke eisen.
Deze documenten bevinden zich nog in ontwikkeling en moeten niet worden gezien als definitieve standaarden.
Gebruikers van 1.1.1.1 hoeven niets te veranderen
Voor wie al 1.1.1.1 gebruikt, is deze verandering transparent.
Wanneer een zone de benodigde records publiceert, kan Cloudflare ML-DSA-44 valideren. De conventionele DNSSEC-zones blijven gewoon werken.
Het bedrijf zal daarnaast testdomeinen inzetten om te meten wat er gebeurt wanneer deze veel grotere antwoorden door netwerken, routers, firewalls en echte resolvers worden gestuurd.
Deze stappen zijn net zo belangrijk als de cryptografie zelf.
De overgang naar post-quantum algoritmen in TLS heeft aangetoond dat het vergroten van grote berichten bestaande software en netwerkapparatuur kan blootleggen aan verborgen limieten en aannames. DNS is nog gevoeliger, omdat veel IP-verkeer via UDP verloopt.
Cloudflare schat dat ongeveer 85% van de queries naar 1.1.1.1 via UDP gaan. Deze cijfers betreffen het transport tussen client en Cloudflare’s resolver, niet noodzakelijk het verkeer tussen resolver en autoritatieve servers.
Het bedrijf heeft 2029 als doel gesteld voor volledige post-quantum bescherming. DNSSEC is een van de essentiële stappen in dat traject.
De nieuwe support op 1.1.1.1 betekent niet dat er nu een directe quantumdreiging voor DNS is. In tegenstelling tot versleuteld verkeer, dat nu al kan worden opgeslagen en later wordt ontcijferd, bescherpt DNSSEC authenticiteit, niet vertrouwelijkheid. Het ligt dus niet zo gevoelig voor ‘harvest now, decrypt later’ aanvallen.
Er is tijd, maar de infrastructuur moet nog enorm veranderen.
En het experiment met ML-DSA-44 toont een van de praktische uitdagingen: een ECDSA-ondertekening van 64 bytes vervangen door een post-quantum versie van 2.420 bytes.
In cryptografie kan een algoritme op papier in enkele regels veranderen. Op het internet moeten die 2.356 extra bytes door miljoenen servers, resolvers, firewalls en netwerkapparaten zonder problemen te ondergaan.
Bronnen:
- Cloudflare, 1.1.1.1 ondersteunt nu post-quantum DNSSEC, alle 2.420 bytes ervan, 10/09/2026.
