Stageonderzoek: Edge cases in DNSSEC-validatie met meerdere algoritmen
Onderzoek naar transitievereisten voor PQC DNSSEC
De oorspronkelijke blogpost is Engelstalig. Dit is de Nederlandse vertaling ervan.
Als onderdeel van ons onderzoek naar post-kwantumcryptografie (PQC) voor DNSSEC onderzoeken we PQC-algoritmen als directe vervanging voor klassieke algoritmen. Om een veilige vervanging te faciliteren, zouden we een transitieperiode kunnen overwegen waarin gelijktijdig zowel PQC- als klassieke algoritmen worden gebruikt. We zijn daarom benieuwd hoe resolvers in dat scenario zouden omgaan met de validatie van DNS-records. In deze blog vertellen we over onze inspanningen om de haalbaarheid en impact van zo'n transitieperiode te analyseren door onderzoek te doen naar edge cases in DNSSEC-validatie met meerdere algoritmen.
Voor het analyseren van de haalbaarheid en impact van een transitieperiode waarin PQC- en klassieke algoritmen gelijktijdig worden gebruikt, vergelijken we wat er volgens de RFC's in theorie zou moeten gebeuren met wat er daadwerkelijk in de praktijk plaatsvindt. We beginnen met een korte uitleg over DNSSEC en bespreken daarna hoe DNSSEC-handtekeningen in verschillende gevallen worden gevalideerd en wat de impact van nieuwe algoritmen zou kunnen zijn.
DNSSEC in een notendop
In DNS kan een zone zoals example.nl meerdere resource records (RR's) van verschillende typen bevatten, bijvoorbeeld een AAAA-record dat verwijst naar ::1 en een MX-record dat verwijst naar mail.example.nl. Je kunt ook meerdere records van hetzelfde type hebben. RR's van hetzelfde type worden gegroepeerd in RRsets. Als voor een zone DNSSEC wordt ingeschakeld, worden deze RRsets vervolgens digitaal ondertekend.
Voor het ondertekenen van RRsets hebben we cryptografische sleutels nodig. In DNSSEC worden de publieke sleutels opgeslagen in DNSKEY-records, en de handtekeningen in RRSIG-records. Zones maken vaak gebruik van de gescheiden sleutelconfiguratie waarbij een zone signing key (ZSK) wordt gebruikt om de RRsets binnen een zone te ondertekenen en een key signing key (KSK) om de ZSK te ondertekenen. Deze ZSK wordt vervolgens ondertekend door de bovenliggende zone, waardoor er vanaf de rootzone een vertrouwensketen ontstaat. Een zone kan ook gebruikmaken van een combined signing key (CSK), een sleutel die voor beide doeleinden kan worden gebruikt. Als een validerende resolver een query ontvangt voor een record binnen een DNSSEC-ondertekende zone, worden de beschikbare RRsets, DNSKEY's en RRSIG's van de rootzone, de opgevraagde zone en alle zones daartussen gebruikt om de response te valideren.
Opportunistische validatie voor nieuwe algoritmen
Bij de validatie van een RRSIG moet een validerende resolver de bijbehorende DNSKEY aantreffen in een lijst van beschikbare sleutels. In plaats van gebruik te maken van een identificatieveld met vaste lengte, gebruikt DNSSEC een eenvoudige 16-bits checksum van de sleutel zelf (de DNSKEY RR KEY Tag), gecombineerd met een aantal attributen van de sleutel (algoritme, eigenaar, ondertekenaar, enzovoort) om DNSKEY's te identificeren.
In sommige situaties kan het DNSSEC-validatieproces flexibel zijn. Het is bijvoorbeeld mogelijk dat 2 afzonderlijke sleutels dezelfde identificerende attributen en checksum hebben; een situatie die wordt aangeduid met de term key collision. Een validerende resolver kan verder geen onderscheid maken tussen zulke sleutels en zal daarom alle desbetreffende sleutels moeten proberen totdat de juiste sleutel is gevonden. Als zo'n sleutel niet werkt, is de handtekening niet automatisch ongeldig. De handtekening wordt alleen ongeldig verklaard als geen van de sleutels werkt. Voor sleutels die niet van elkaar worden onderscheiden, hanteert het DNSSEC-validatieproces dus een flexibel selectiebeleid.
Het is mogelijk om een zone te ondertekenen met meerdere, op verschillende algoritmen gebaseerde sleutels tegelijk. In zulke gevallen moet elk record ondertekend worden met ten minste 1 sleutel per algoritme. In 2013 werd het DNSSEC-validatieproces bijgewerkt met expliciete instructies voor validerende resolvers om niet-ondersteunde algoritmen te negeren. Dit betekent een versoepeling van de strenge eisen voor algoritmevalidatie en maakt het mogelijk om nieuw algoritmen opportunistisch te valideren. Dit is goed nieuws voor een mogelijke transitieperiode: resolvers die PQC-algoritmen (nog) niet ondersteunen, kunnen deze gewoon negeren. We willen echter nagaan of resolvers zich wereldwijd daadwerkelijk aan deze bijgewerkte instructies houden en in de praktijk niet-ondersteunde algoritmen naar behoren negeren.
Vóór de RFC uit 2013 werd een response als ongeldig (bogus) beschouwd als er voor 1 algoritme geen werkende sleutel was, zelfs als er wel een werkende sleutel was voor een ander algoritme. Die validatie-eis voor zones die met meerdere algoritmen zijn ondertekend, is behoorlijk streng en staat in scherp contrast met het flexibele selectiebeleid voor sleutels.
Dat leidde tot het volgende probleem: tijdens een transitieperiode waarin zones gelijktijdig met zowel oude als nieuwe algoritmen worden ondertekend, zullen resolvers die het nieuwe algoritme nog niet ondersteunen de response automatisch als bogus beschouwen, zelfs als ze die response kunnen valideren met een ouder algoritme. Niet ideaal voor een transitieperiode, waarin we liever een flexibelere manier hebben om met niet-ondersteunde algoritmen om te gaan.
Het was altijd zo dat het aan lokaal beleid werd overgelaten of van deze gestandaardiseerde validatie-eisen werd afgeweken. Hoewel dat resolvers de mogelijkheid bood om de strenge validatie-eisen voor algoritmen te versoepelen, leidde het ook tot een veelheid aan verschillende, individuele validatie-eisen. Om dat nadeel te verhelpen, werd de DNSSEC-validatie aangepast om een verschuiving van lokale beleidsbeslissingen naar meer uniforme validatie-eisen te bewerkstelligen.
Opzettelijk ongeldig gemaakte handtekeningen
We willen ook analyseren welk effect mislukte handtekeningvalidaties hebben op de validatiebeslissingen die door resolvers worden genomen als meerdere bekende algoritmen tegelijk worden gebruikt. We zijn vooral benieuwd naar de manier waarop resolvers omgaan met specifieke combinaties van geldige en ongeldige handtekeningen. Om dat te onderzoeken gebruiken we 3 verschillende sleutelconfiguraties voor het opzettelijk ongeldig maken van handtekeningen.
De eerste sleutelconfiguratie, 'split', gebruikt 1 KSK en 1 ZSK. Als een zone ongeldig moet worden gemaakt, maken we alleen de handtekeningen van de ZSK ongeldig, terwijl de handtekeningen van de KSK intact blijven. De tweede sleutelconfiguratie, 'combined', gebruikt 1 CSK. In dit geval maken we alle handtekeningen van de CSK ongeldig als een zone ongeldig moet worden gemaakt.
De derde sleutelconfiguratie, 'splitmany', gebruikt 1 KSK en 4 ZSK's. Hierbij worden altijd 3 van de 4 ZSK's opzettelijk ongeldig gemaakt. Als een zone volledig ongeldig moeten worden gemaakt, corrumperen we ook de handtekeningen van de overgebleven ZSK.
Testopstelling
Om te testen hoe goed resolvers zouden omgaan met de transitieperiode in ons scenario, hebben we een nameserver opgezet die autoritatief is voor een groot aantal zones met specifieke combinaties van algoritmen, sleutelconfiguraties en ongeldig gemaakte handtekeningen. Deze nameserver is op vergelijkbare wijze opgezet als de DNS workbench van SIDN Labs en wordt daar in de toekomst mogelijk aan toegevoegd.
Ons werk volgt en bouwt voort op de PQC DNSSEC-veldstudie van deSEC, door te analyseren hoe zones worden gevalideerd als ze zijn ondertekend met meerdere bekende en onbekende algoritmen tegelijk. In onze opstelling gebruiken we het RIPE Atlas-netwerk om 64 verschillende DNS-query's te versturen vanaf 10.000 probes, waarbij we voor elke meting om dezelfde lijst probes vragen. RIPE Atlas kan echter niet garanderen dat elke probe aan alle 64 metingen deelneemt, waardoor het aantal deelnemende probes voor sommige metingen lager ligt.
Voor de meeste deelnemende probes zijn meerdere resolvers geconfigureerd. Bij elke meting instrueren we de probes om bij al hun geconfigureerde resolvers een specifiek domein op te vragen. Bij elke query zetten we de DO-vlag aan, waarmee we de DNS-resolver vragen te antwoorden met DNSSEC-gerelateerde resource records. Omdat RIPE Atlas een query niet opnieuw verstuurt via TCP als responses via UDP worden afgekapt, simuleren we dit gedrag door query's zowel via UDP als TCP uit te voeren.
We gebruiken 3 algoritmen: de klassieke algoritmen 8 (RSA) en 13 (ECDSA), die door DNSSEC-validators verplicht moeten worden geïmplementeerd, en het PQC-algoritme Falcon-512, met handtekeningen die door padding een vaste grootte hebben. Omdat Falcon-512 (nog) geen gestandaardiseerd algoritmenummer heeft en we het niet als privaat algoritme gebruiken, kiezen we voor algoritmenummer 251. Dit is een niet-toegewezen algoritmenummer dat momenteel niet aan nieuwe algoritmen kan worden gekoppeld. Door dit nummer te gebruiken, voorkomen we dat we per ongeluk een algoritmenummer claimen op basis van precedent zonder officiële standaardisatie.
Om de metingen van elkaar te onderscheiden, gebruiken we de volgende domeinnaamstructuur: <algorithm config>.<key config>.pqcdnssec.sidnlabs.nl. De algoritmeconfiguratie geeft aan welke algoritmen worden gebruikt en of hun handtekeningen opzettelijk ongeldig zijn gemaakt. De domeinnaam 8-valid-13-invalid.split.pqcdnssec.sidnlabs.nl geeft bijvoorbeeld aan dat de zone de sleutelconfiguratie 'split' gebruikt en is ondertekend met zowel algoritme 8 als 13, waarbij alle handtekeningen van algoritme 13 opzettelijk ongeldig zijn gemaakt.
De meeste probes zijn geconfigureerd om meerdere resolvers te raadplegen, dus we verwachten meerdere responses per probe. We gaan er ook van uit dat veel probes gebruikmaken van een aantal populaire resolvers, zoals die van Cloudflare of Google, wat betekent dat sommige resolvers oververtegenwoordigd zullen zijn in onze data. Daarom moeten we onze responses filteren op unieke resolvers in plaats van op unieke probes. We onderscheiden unieke resolvers op basis van hun publieke IP-adressen of, in het geval van lokale resolvers, hun private IP-adressen in combinatie met de probe-ID. Voor elke unieke resolver verwachten we een verschillend aantal mogelijk variërende responses te zien. Om voor elke unieke resolver 1 response te verkrijgen, negeren we bepaalde time-outs en loadbalancingfouten en selecteren we de meest voorkomende response.
Door naar de vlaggen in de responses te kijken, kunnen we responses met duidelijke fouten eruit filteren. Omdat we alleen geïnteresseerd zijn in resolvers en niet in nameservers, verwijderen we ook responses waarin de vlag Recursion Available (RA) niet is gezet. Hetzelfde geldt voor responses waarin de vlag Authoritative Answer (AA) is gezet, omdat die ten onrechte claimen autoritatief te zijn voor onze testzones. Als een response de vlag Checking Disabled (CD) bevat of de vlag Recursion Desired (RD) mist, wijst dat erop dat de resolver de query niet heeft verwerkt zoals gevraagd.
Verder filteren we responses op basis van hoe de resolver heeft geantwoord op een typische DNSSEC-ondertekende zone. Resolvers die geen correct antwoord gaven voor 13-valid.split via UDP worden buiten beschouwing gelaten, omdat de implementatie van algoritme 13 (ECDSA) verplicht is in DNSSEC-validators en meestal gebruik wordt gemaakt van de gescheiden sleutelconfiguratie. Op die manier kunnen we Falcon meten en vergelijken met het gangbare algoritme ECDSA.
Vergelijking tussen lokale en publieke resolvers
We ontvingen antwoorden van 11.224 unieke resolvers, waarvan 34,76% publieke resolvers en 65,24% resolvers op lokale netwerken. Van 95,10% van de unieke publieke resolvers kregen we een antwoord via TCP. Dat betekent niet automatisch dat de overige 4,90% geen TCP ondersteunt, aangezien RIPE Atlas niet kan garanderen dat elke geselecteerde probe aan elke meting deelneemt.
Van de unieke lokale resolvers ontvingen we echter van slechts 0,237% een antwoord via TCP. Dat wijst erop dat, enkele uitzonderingen daargelaten, TCP op lokale resolvers mogelijk niet breed wordt ondersteund. Als we dieper graven, zien we regelmatig de foutmelding 'TU_BAD_ADDR: true' terugkomen, en dan alleen bij TCP-query's naar lokale resolvers. Waarschijnlijk is dit het gevolg van een firewall of beleidsinstelling die specifiek is voor RIPE Atlas-probes, iets waarvan eerder melding is gemaakt op de RIPE Atlas-mailinglijst. Daarom geven de resultaten voor lokale servers mogelijk geen accuraat beeld van het gedrag in de praktijk. We filteren de weinige succesvolle TCP-responses van lokale resolvers uit en bewaren de DNS-ondersteuning via TCP door lokale resolvers voorlopig voor toekomstig onderzoek.
Passende responses
Bij het beoordelen of een response 'passend' is, maken we onderscheid tussen validerende en niet-validerende resolvers. Voor niet-validerende resolvers beschouwen we een response als passend als deze het juiste IP-adres bevat, de responsecode NOERROR heeft en de AD-vlag niet is gezet.
Voor validerende resolvers maken we onderscheid op basis van de verwachting of het antwoord als geldig of ongeldig gevalideerd zal worden. Bij query's waarvan we verwachten dat ze gevalideerd zullen worden als ongeldig (bogus), verwachten we dat een validerende resolver antwoordt met een SERVFAIL-response, zonder verdere gegevens. Bij query's waarvan we verwachten dat ze gevalideerd zullen worden als geldig, verwachten we dat een validerende resolver antwoordt met het juiste IP-adres, een gezette AD-vlag en het correcte aantal handtekeningen. Daarnaast staan we toe dat validerende resolvers antwoorden alsof ze niet-validerend zijn.
Figuur 1 laat per protocol, algoritme en sleutelconfiguratie het percentage unieke resolvers zien dat een passende response heeft gegeven.
Figuur 1: (Klik om te vergroten) Percentage unieke resolvers met een passende response. Hoe donkerder de kleur, hoe hoger het percentage. De figuur is opgedeeld in een raster van 3x3 grafieken. Elke rij met subgrafieken toont een sleutelconfiguratie (split, combined en splitmany) en elke kolom toont metingen uitgevoerd via een specifiek protocol (UDP, TCP of UDP met retry via TCP). Elke subgrafiek laat vervolgens per meting zien welk percentage unieke resolvers een passende response gaf.
Als we kijken naar de resultaten voor de sleutelconfiguraties split en combined, zien we dat voor vrijwel alle query's geldt dat het merendeel van de resolvers een passende response retourneerde. Er zijn echter enkele duidelijke uitschieters.
Volgorde lijkt van belang
We zien dat via UDP en TCP de query's naar 8-invalid-13-valid veel minder passende responses opleverden dan die naar 8-valid-13-invalid. Een verklaring voor dit verschil kan zijn dat veel resolvers de handtekeningen mogelijk sorteren op oplopend algoritmenummer.
In theorie zou de volgorde van de handtekeningen niet uit moeten maken; zolang er een geldige handtekening bij zit, zou de response geauthentiseerd moeten worden, ongeacht het aantal ongeldige handtekeningen. Als tegenmaatregel tegen de zogeheten KeyTrap-aanvallen breken sommige validerende resolvers het validatieproces echter af als er te veel ongeldige handtekeningen zijn. Bij sommige resolvers lijkt deze tegenmaatregel zelfs helemaal geen ongeldige handtekeningen toe te staan. Resolvers waarbij dat het geval is, zullen 8-invalid-13-valid onterecht als ongeldig beschouwen, maar 8-valid-13-invalid terecht als geldig.
Het lijkt erop dat de volgorde van de handtekeningen een grote rol speelt. We zien vergelijkbare patronen in de resultaten voor de sleutelconfiguratie splitmany, waar de volgorde van de sleutels en het aantal ongeldige handtekeningen bepalen hoe goed ze gevalideerd worden. Bovendien levert de sleutelconfiguratie splitmany aanzienlijk meer onjuiste antwoorden op via UDP, omdat responses dan vaker worden afgekapt doordat de berichten groter zijn.
Sommige van de resolvers voegden Extended DNS Errors (EDE) toe aan hun antwoorden. Deze worden weergegeven in Figuur 2. We zien dat EDE-code 1, die aangeeft dat de resolver een niet-ondersteund DNSKEY-algoritme tegenkwam, zoals verwacht aanwezig was bij query's naar 251-valid. Bij query's naar 13-valid-251-valid, is deze foutcode nergens te bekennen, maar bij query's naar 13-invalid-251-valid duikt hij weer op. Dat wil zeggen dat de resolvers waarschijnlijk geprobeerd hebben de handtekeningen te valideren in oplopende volgorde van algoritmenummer.
Figuur 2: (Klik om te vergroten) Extended DNS Errors (EDE) in de antwoorden van resolvers. De figuur is opgedeeld in een raster van 3x3 grafieken. Elke rij met subgrafieken toont een sleutelconfiguratie (split, combined en splitmany) en elke kolom toont metingen uitgevoerd via een specifiek protocol (UDP, TCP of UDP met retry via TCP). Elke subgrafiek laat vervolgens per meting zien welke Extended DNS Errors in de antwoorden van de resolvers voorkwamen.
Responsegroottes
Figuur 3 toont per combinatie van protocol, algoritme en sleutelconfiguratie de groottes van de responses afkomstig van unieke resolvers. Elk blokje is 128 bytes breed en ingekleurd op basis van het aantal responses binnen dat groottesegment. De rode lijnen geven ter referentie de responsegroottes weer die door onze eigen nameserver zijn geretourneerd. De grijze lijnen markeren de grens van 1.232 bytes, een voorgestelde maximale UDP-buffergrootte voor DNS om IP-fragmentatie te voorkomen.
Figuur 3: (Klik om te vergroten) Groottes van responses afkomstig van unieke resolvers. De figuur is opgedeeld in een raster van 3x3 grafieken. Elke rij met subgrafieken toont een sleutelconfiguratie (split, combined en splitmany) en elke kolom toont metingen uitgevoerd via een specifiek protocol (UDP, TCP of UDP met retry via TCP). Elke subgrafiek laat vervolgens per meting de groottes zien van de responses die afkomstig waren van unieke resolvers.
Veel meer sleutels
Er zijn omstandigheden waarin het aantal sleutels en handtekeningen in een zone bewust wordt verhoogd. Zo kan een zone bijvoorbeeld een alvast gepubliceerde reservesleutel hebben die bedoeld is voor gebruik in noodsituaties. Bij sleutelrollovers komen vooraf gepubliceerde sleutels ook vaak voor. Tijdens een sleutelrollover met dubbele ondertekening kan een volledige zone zowel met de oude als met de nieuwe sleutel worden ondertekend. In een transitieperiode kunnen we meerdere (geldige) sleutels en handtekeningen tegelijkertijd verwachten voor zowel nieuwe als oude algoritmen.
Om te testen hoe goed resolvers tijdens de transitieperiode omgaan met een toename van het aantal sleutels, creëerden we zones met een reguliere gescheiden sleutelconfiguratie (split) die werden ondertekend met algoritmen 13 en 251, waarna we stapsgewijs het aantal sleutels en handtekeningen verhoogden.
Figuur 4 toont de percentages passende responses en Figuur 5 laat de responsegroottes voor deze zones zien.
Figuur 4: (Klik om te vergroten) De percentages passende responses als onze testzones worden ondertekend met een toenemend aantal sleutels. De 3 subgrafieken tonen metingen die zijn uitgevoerd via een bepaald protocol (UDP, TCP of UDP met retry via TCP).
Figuur 5: (Klik om te vergroten) De responsegroottes als onze testzones worden ondertekend met een toenemend aantal sleutels. De 3 subgrafieken tonen metingen die zijn uitgevoerd via een bepaald protocol (UDP, TCP of UDP met retry via TCP).
Opvallend is dat bij de meeste resolvers de UDP-limieten al worden overschreden zodra er meer dan 1 set sleutels per algoritme wordt gebruikt. De kolom UDP_retry_TCP laat zien dat opnieuw proberen via TCP het percentage passende responses aanzienlijk verhoogt, maar niet voldoende om betrouwbare sleutelrollovers met dubbele ondertekening mogelijk te maken.
De impact van een transitieperiode
Onze resultaten tonen aan dat niet-ondersteunde algoritmen door bijna alle resolvers worden genegeerd. Ook blijkt dat TCP breed wordt ondersteund door publieke resolvers en er nauwelijks problemen met de validatie zijn bij realistische use cases via TCP. Bij lokale resolvers daarentegen lijkt de ondersteuning voor TCP bijzonder laag of zelfs geheel afwezig. Verder onderzoek moet uitwijzen of dit een tekortkoming is die specifiek is voor RIPE Atlas, of dat het inderdaad een tekortkoming is die specifiek is voor veel lokale resolvers (in het verleden is dit zeker een probleem geweest).
Bij sommige resolvers zagen we validatieproblemen als gevolg van strikte limieten binnen KeyTrap-mitigatietactieken. Deze validatieproblemen zijn niet specifiek voor PQC-algoritmen en doen zich alleen voor bij opzettelijk ongeldig gemaakte handtekeningen. Aangezien zulke handtekeningen in de praktijk nauwelijks voorkomen (DNS-testomgevingen, aanvallen), vormen de waargenomen problemen geen ernstig probleem.
Het grootste probleem met PQC-algoritmen is de toename in de grootte van sleutels en handtekeningen. Via UDP worden de meeste dalingen in gepaste responses veroorzaakt door de toegenomen grootte van DNS-berichten. We zagen dat het gebruik van Falcon naast ECDSA redelijk goed werkte als er 1 gescheiden sleutelset per algoritme werd gebruikt. Normale use cases met meerdere sleutels en handtekeningen, zoals sleutelrollovers en reservesleutels, lieten echter veel minder gunstige resultaten zien via UDP, doordat hun berichten de bufferlimieten overschreden. Dit betekent dat een transitie naar PQC-algoritmen via UDP realistisch gezien niet haalbaar is en onderstreept het belang van TCP-ondersteuning bij lokale resolvers die DNSSEC-validatie lokaal uitvoeren.
Veel resolvers lijken sleutels en handtekeningen te sorteren in oplopende volgorde van algoritmenummer, key tag en nog wat andere kenmerken. Daardoor worden handtekeningen met lagere algoritmenummers vaak als eerste gecontroleerd. Aangezien algoritmenummers momenteel in oplopende volgorde worden toegewezen en gestandaardiseerd, zullen nieuwe algoritmen altijd een hoger algoritmenummer hebben en worden ze daardoor meestal als laatste gecontroleerd. De validatie slaagt zodra de eerste geldige handtekening is gevonden, maar kan in sommige gevallen ook direct falen als de eerste validatiepoging mislukt.
Dat betekent in de praktijk dat het gebruik van meerdere algoritmen naast elkaar er meestal toe leidt dat de handtekeningen van nieuwere algoritmen genegeerd worden. De validatie is dan vooral afhankelijk van de handtekeningen van de oudere algoritmen, zelfs als de resolver de nieuwere algoritmen ook kent. Met andere woorden: nieuwere algoritmen worden naast oudere algoritmen niet opportunistisch gebruikt, ook al zou dat kunnen.
Conclusie
Als we kijken naar onze gesimuleerde transitieperiode, verwerken de meeste resolvers onze query's redelijk goed. Niet-ondersteunde algoritmen worden grotendeels genegeerd en de validatie van algoritmen die de resolver niet kent naast bekende algoritmen verschilt niet veel van de validatie van alleen bekende algoritmen. Dat gedrag lijkt echter deels veroorzaakt te worden door de sorteervolgorde, waarbij algoritmen met een hoger nummer, ongeacht of ze worden ondersteund, vaak worden genegeerd ten gunste van algoritmen met een lager nummer. Er valt daarom weinig winst te behalen met een langere transitieperiode dan bij een snelle algoritmerollover, tenzij de werking van DNSSEC-validatie verandert.
We hebben ook gezien dat de grotere berichten die gepaard gaan met het gebruik van PQC-algoritmen kunnen leiden tot een sterke toename van validatieproblemen. Dat toont aan dat PQ-veilige DNSSEC mogelijk een oplossing vereist die verder gaat dan een eenvoudige directe vervanging van klassieke algoritmen.
