Stageonderzoek: DNSSEC en PQC: de praktische impact van meer TCP-verkeer in DNS

De cryptografie die momenteel wordt gebruikt, is niet bestand tegen aanvallen met kwantumcomputers. Hoewel praktische kwantumcomputers mogelijk nog jaren op zich laten wachten, leert de ervaring met een eerdere overgang naar een nieuw algoritme dat het ongeveer 10 jaar duurt voordat een nieuw DNSSEC-handtekeningenalgoritme op grote schaal is ingevoerd. Om dat proces te versnellen, helpt het om voorbereid te zijn en te weten welke impact mogelijke vervangende algoritmen kunnen hebben.

Bij veel van de voorgestelde PQC-handtekeningenalgoritmen is de handtekening relatief groot vergeleken met de 64 bytes grote ECDSA-handtekening, die momenteel de standaard is in DNSSEC. Zo heeft Falcon-512, een veelbelovend PQC-alternatief, een handtekening van 666 bytes. DNS-berichten worden standaard verstuurd via UDP en mogen bij voorkeur niet groter zijn dan 1.232 bytes, uitgaande van een MTU van 1.280 bytes. Als in 1 DNS-respons meerdere Falcon-handtekeningen moeten worden opgenomen, overschrijdt het bericht die aanbevolen maximale grootte.

In DNS kan een client zijn UDP-buffergrootte doorgeven via EDNS0. Als een nameserver een respons moet versturen die groter is dan de door een client aangegeven EDNS0-limiet, wordt in plaats daarvan een afgekapte respons verstuurd. Dit houdt in dat het bericht wordt ingekort om binnen de maximale grootte te passen en dat de TC-vlag wordt gezet. Zodra de resolver een respons met deze vlag ontvangt, wordt er een TCP-sessie met de autoritatieve nameserver gestart om de volledige respons binnen te halen.

Momenteel verloopt maar een klein deel, ongeveer 1 à 2%, van het DNS-verkeer naar de .nl-nameserver via TCP. Het is mogelijk dat dit percentage aanzienlijk gaat stijgen als PQC-handtekeningenalgoritmen in DNSSEC worden ingevoerd. Er zou dan een patroon ontstaan waarbij DNSSEC-query's vaak opnieuw moeten worden verstuurd via TCP. De impact van meer TCP-verkeer op de prestaties van autoritatieve nameservers is op dit moment onduidelijk. Tijdens mijn stage heb ik daarom samen met onderzoekers van SIDN Labs geprobeerd deze impact in kaart te brengen.

Meetopzet

Omdat in het PQC-DNSSEC-scenario geprobeerd wordt om grote berichten opnieuw te versturen via TCP, zijn we benieuwd naar de impact van een toename in het aantal TCP-sessies. Om dit te onderzoeken voerden we verschillende metingen uit.

Voor onze metingen was een opzet nodig waarin we query's naar een nameserver konden herhalen. Daarvoor hadden we een herhalingstool nodig die in staat was om de query's op een bepaald tijdstip opnieuw te versturen, met een hoge mate van precisie. Omdat we geen software libraries of tools konden vinden die zowel UDP- als TCP-query's konden herhalen en in een bepaald percentage van de gevallen dezelfde query eerst via UDP en vervolgens via TCP konden versturen, ontwikkelden we met behulp van de DNS-bibliotheek van miekg onze eigen herhalingstool in Go. Met deze tool kunnen we query's naar een nameserver sturen en de bijbehorende responses ontvangen.

Vervolgens hadden we een manier nodig om te simuleren dat een percentage van de berichten werd afgekapt. Dat kan op verschillende manieren, bijvoorbeeld door daadwerkelijk gebruik te maken van lange berichten of door aan de serverzijde een aantal snelheidsbeperkingen in te stellen. We kozen ervoor om de afkapping aan de clientzijde te regelen. In een bepaald percentage van de gevallen negeert de client die de query verstuurt de UDP-respons van de server en wordt de query opnieuw verstuurd via TCP. Dat simuleert het gedragspatroon dat je zou zien als de berichten door de server worden afgekapt en zorgt voor dezelfde belasting op de nameserver. Als we in de volgende alinea's een TCP-percentage noemen, bedoelen we het percentage query's dat eerst via UDP is verstuurd en daarna opnieuw via TCP.

Om de daadwerkelijke impact te meten, herhaalden we een lijst met query's naar een nameserver, waarbij de onderlinge timing van de query's behouden bleef. Tegelijkertijd registreerden we hoeveel geheugen en CPU-tijd de nameserver gebruikte. Om interferentie tussen het proces van het versturen van de query's en het nameserverproces te minimaliseren, draaiden we elk proces op een aparte server. We herhaalden 1 uur aan query's uit de praktijk die oorspronkelijk naar 1 van de .nl-nameservers waren gestuurd. Door gebruik te maken van dit soort querydata wilden we onze tests representatief maken voor de normale activiteiten van een .nl-nameserver. De gebruikte data werden op 1 oktober 2025 tussen 12:00 en 13:00 CEST verzameld op 1 van de .nl-nameservers. De querydata die de nameserver in dat uur ontving, worden gevisualiseerd in figuur 1. Het figuur laat zien hoeveel query's er elke 30 seconden werden verstuurd gedurende het uur dat het experiment besloeg. De query's zijn gegroepeerd in intervallen van 30 seconden, in lijn met de metingen van onze metrics, die eveneens elke 30 seconden plaatsvonden. Deze opzet maakt het eenvoudiger om eventuele correlaties te herkennen tussen de pieken in deze grafiek en de latere grafieken van de gemeten metrics. Voor dit experiment gebruikten we een kopie van de zonefile van dezelfde dag, zodat de server in staat was om op een query te reageren als de echte .nl-nameserver dat ook zou hebben gedaan. Om privacyredenen waren de querydata en de bijbehorende zonefile gepseudonimiseerd ten opzichte van de originele versies, door elke domeinnaam te vervangen door een willekeurige tekenreeks van dezelfde lengte. Alle IP-adressen waren geanonimiseerd.

Figuur 1: Aantal query's dat gedurende de meetperiode elke 30 seconden naar de .nl-nameserver werd verstuurd. Dit is exclusief verzoeken die opnieuw werden verstuurd via TCP.

We voerden de metingen uit met behulp van 2 verschillende machines. Op 1 daarvan draaide de code van onze tool voor het versturen van de query's, die de DNS-verzoeken naar de andere machine moest sturen en de responses ontving. Op de andere machine draaide een autoritatieve nameserver in een Podman-container (versie 4.9.3), die de gepseudonimiseerde zonefile aanbood en was geconfigureerd om te reageren op verzoeken die afkomstig waren van de eerste machine. Beide machines draaiden Ubuntu 24.04.3 LTS en waren volledig gereserveerd voor deze experimenten, wat inhield dat er geen andere software op draaide en er geen andere gebruikers op actief waren. De machines bevonden zich bovendien binnen hetzelfde netwerk, waardoor netwerkvertraging geen factor was. Omdat de nameserver in een Podman-container draaide, gebruikten we de Podman-API om statistieken te verzamelen over de CPU-tijd en het geheugengebruik van de nameserver.

Ons onderzoek bestond uit 12 verschillende experimenten. In de eerste 11 werd tijdens elk experiment een ander percentage van de query's opnieuw verstuurd via TCP. Deze percentages liepen van 0% tot 100%, in incrementele stappen van 10 procentpunten. In het laatste experiment werden alle query's meteen via TCP verstuurd, zodat er niets opnieuw of eerst via UDP werd verstuurd. Alle experimenten binnen het onderzoek werden 10 keer herhaald om een nauwkeurig gemiddelde te verkrijgen. Omdat we ook wilden kijken of er verschillen in gedrag en impact waren tussen autoritatieve servers, voerden we de reeks experimenten uit met 4 verschillende nameserverimplementaties: NSD (versie 4.12.0), Knot (versie 3.5.2), BIND9 (versie 9.20) en PowerDNS (versie 4.9.0 in BIND-modus).

Bij NSD, Knot en BIND legden de standaardinstellingen geen buitensporige beperkingen op aan het aantal TCP-verbindingen. Hun instellingen hielden we zo dicht mogelijk bij de standaardconfiguratie. Bij PowerDNS is de serverinstelling max-tcp-connections standaard ingesteld op 20. Dat betekent dat er maximaal 20 inkomende TCP-verbindingen tegelijk kunnen plaatsvinden. Dat is maar een beperkt aantal, dus we verwachtten dat de nameserver onze query's niet zou kunnen verwerken als we de test zouden uitvoeren zonder deze instelling aan te passen. Dat bleek echter niet het geval: we zagen geen groot verschil tussen onze test met max-tcp-connections ingesteld op 200 en de test met de standaardwaarde. We vermoeden dat dit komt doordat de servers dicht bij elkaar stonden, waardoor elke TCP-verbinding maar heel even duurde. Onder normale omstandigheden zou het nodig kunnen zijn om een hogere waarde in te stellen als je veel verzoeken via TCP verwacht.

Resultaten

Nadat we de tests hadden uitgevoerd, visualiseerden we de resultaten in 2 grafieken, die elk hun eigen inzichten verschaffen. Bij het bespreken van de resultaten gebruiken we deze grafieken als leidraad. Tijdens de tests werd de CPU-tijd van de nameserverprocessen in zowel de userspace als de kernelspace bijgehouden. Hieronder laten we echter alleen de grafieken van de CPU-tijd in de userspace zien, omdat de effecten op de CPU-tijd in de kernelspace vrijwel hetzelfde zijn. Zoals we eerder al vermeldden, registreerden we tijdens het uitvoeren van de experimenten ook het geheugengebruik van het nameserverproces. We zagen geen verandering in het geheugengebruik, wat goed nieuws is gezien de recente stijgingen in de prijs van computergeheugen. Daarom is deze variabele niet relevant voor deze blogpost.

Voordat we overgaan tot het bespreken van onze resultaten, willen we graag nog iets toelichten. Onze metingen zijn uitgevoerd met configuraties die zo dicht mogelijk bij de standaardinstellingen lagen. De configuraties van alle 4 de tools kunnen waarschijnlijk worden geoptimaliseerd om de tools efficiënter te maken dan uit onze metingen naar voren komt. Voor de volledigheid hebben we de code die we voor de experimenten hebben gebruikt, inclusief de configuratiebestanden, online beschikbaar gesteld. De link naar de code is te vinden aan het einde van deze blog.

Figuur 2 laat voor elke nameserverimplementatie die we hebben getest een grafiek zien. In deze grafieken is te zien hoeveel CPU-tijd er tijdens de experimenten per interval van 30 seconden werd gebruikt. Elke grafiek bevat 12 lijnen, waarvan er 11 per interval van 30 seconden weergeven hoeveel CPU-tijd werd gebruikt als een bepaald percentage van de query's opnieuw werd verstuurd via TCP. De rode stippellijn toont de CPU-tijd die werd gebruikt als alle query's uitsluitend via TCP werden verstuurd. Alle lijnen geven het gemiddelde weer van de 10 onafhankelijke metingen die we voor dat experiment uitvoerden. Om te controleren of dit gemiddelde representatief was, hebben we de individuele metingen uitgezet in een grafiek en gekeken hoeveel ze van elkaar verschilden. Met maximaal 1 uitschieter per experiment, was de variantie die we zagen laag genoeg om het gebruik van het gemiddelde te rechtvaardigen.

Figuur 2: CPU-tijd die elke 30 seconden door een nameserver werd gebruikt. Met uitzondering van de rode stippellijn ('Only TCP') vertegenwoordigt elke lijn het gemiddelde van 10 herhalingen van een experiment waarbij een bepaald percentage van de query's opnieuw wordt verstuurd via TCP. Het figuur is onderverdeeld in 4 subgrafieken, die elk het CPU-gebruik van andere nameserver-software tonen.

In alle 4 de subgrafieken van dit figuur zien we hetzelfde verschijnsel: als een groter percentage van de query's opnieuw wordt verstuurd via TCP, leidt dit over het geheel genomen tot een hogere CPU-tijd. Daarnaast zien we op specifieke momenten pieken in het CPU-gebruik. Deze pieken kunnen we verklaren door ook naar figuur 1 te kijken, want op precies die momenten zien we daar een overeenkomstige piek in het aantal verstuurde query's. Als een nameserver een groot aantal query's moet verwerken, is er meer CPU-tijd nodig om al deze query's te beantwoorden, waardoor er pieken ontstaan.

In figuur 2 zien we dat een hoger percentage aan query's die opnieuw worden verstuurd via TCP – kortweg TCP-retries genoemd – invloed heeft op de gebruikte CPU-tijd. De omvang van deze impact verschilt per nameserver-software en omdat de grafieken dezelfde schaal gebruiken, kunnen we deze verschillen goed met elkaar vergelijken. De NSD-nameserver laat de kleinste toename in CPU-gebruik zien. Als we Knot en BIND vergelijken, zien we dat BIND weliswaar begint met een hoger CPU-gebruik als er nog geen TCP-retries plaatsvinden, maar dat de toename ten opzichte van dit startpunt relatief klein blijft. Knot daarentegen vertoont bij elke volgende lijn in de grafiek een aanzienlijke toename in CPU-tijd. PowerDNS combineert de nadelen van BIND en Knot: net als BIND heeft het een hoog startniveau wat betreft CPU-gebruik, en net als Knot een relatief sterke toename van lijn tot lijn.

Bij alle nameservers leidt elke incrementele toename in het percentage TCP-retries tot een hogere CPU-tijd. Bij NSD en Knot lijkt de toename bij elke volgende lijn bovendien steeds ongeveer hetzelfde te zijn. Dat suggereert dat er mogelijk een lineair verband bestaat tussen het percentage TCP-retries en de gebruikte CPU-tijd.

De rode stippellijn in de grafieken, die correspondeert met het experiment waarin we alle query's uitsluitend via TCP verstuurden, geeft het kantelpunt voor de betreffende implementatie aan. Dit kantelpunt is het percentage TCP-retries waarbij het voordeliger is om alles direct via TCP te versturen, in plaats van eerst via UDP en pas als de respons te groot is, nog een keer via TCP. Bij NSD en PowerDNS is dat kantelpunt 70%: bij dat percentage TCP-retries is de benodigde CPU-tijd hoger dan wanneer alles meteen via TCP wordt verstuurd. Bij Knot ligt het kantelpunt hoger, op 90%, en bij BIND ligt het lager, op 50%.

Om het mogelijke lineaire verband dat we in figuur 2 zagen te onderzoeken, maakten we nog een grafiek, weergegeven in figuur 3, waarin de rode stippellijnen zijn weggelaten. Deze grafiek toont het percentage TCP-retries afgezet tegen de gemiddelde CPU-tijd die gedurende de gehele meetperiode voor elk TCP-percentage werd gebruikt. Dit gemiddelde vat dus een volledige lijn uit figuur 2 samen in 1 enkel datapunt. Naast het uitzetten van deze afzonderlijke datapunten, voerden we een standaard lineaire regressie uit, wat resulteerde in de lijnen in figuur 3. De R-kwadraatwaarden die bij de regressie horen, zijn als volgt: NSD heeft een R-kwadraat van 0,9961, Knot zit op 0,9958, BIND op 0,9561 en PowerDNS laat 0,9783 zien. R-kwadraat is een statistische waarde die aangeeft hoe goed een lineair regressiemodel bij de data past en geeft dus de sterkte van het verband tussen ons model en de afhankelijke variabele weer. De waarde ligt tussen 0 en 1, waarbij 1 betekent dat het model elk datapunt perfect beschrijft en een waarde dichter bij 0 duidt op een slechte fit. In ons geval hebben NSD en Knot zeer hoge waarden, rond 0,996, wat wijst op een sterke overeenkomst met de data. BIND en PowerDNS hebben daarentegen lagere waarden, wat duidt op een zwakker verband vergeleken met NSD en Knot, maar laten nog steeds een goede algehele fit zien.

We tekenden de resulterende regressielijn in naast de gemiddelde datapunten. Elk regressiemodel leverde bovendien een lineaire vergelijking op die het gevonden verband beschrijft, en deze vergelijking wordt weergegeven in de bijbehorende grafiek.

Figuur 3: Gemiddeld CPU-gebruik afgezet tegen het percentage query's dat opnieuw werd verstuurd via TCP. De grafiek is onderverdeeld in 4 subgrafieken, die elk het resultaat voor een andere nameserverimplementatie tonen.

In figuur 3 laten zowel NSD als Knot een duidelijk lineair verband zien tussen het aantal TCP-retries en de CPU-tijd die door de nameserver wordt gebruikt, vergelijkbaar met onze bevindingen in figuur 2. Er zijn geen grote uitschieters en de R-kwadraatwaarden zijn hoog. We zien ook dat de lijn van Knot steiler is dan die van NSD. Dit betekent dat het effect van een toename in het aantal TCP-retries op een Knot-nameserver ongeveer 2 keer zo groot is als op een NSD-nameserver.

In het geval van BIND kunnen we daarentegen niet concluderen dat er sprake is van een lineair verband. De met lineaire regressie verkregen lijn sluit niet goed aan bij de daadwerkelijke datapunten in de grafiek, vooral bij de TCP-percentages van 0 tot 20%. Hoewel we dus niet per se een lineair verband zien, zien we wel dat de toename in gebruikte CPU-tijd van 0 tot 100% TCP kleiner is bij BIND dan bij Knot. BIND lijkt deze toename dus beter op te vangen. Vergelijken we BIND met NSD, dan zien we dat de toename in gebruikte CPU-tijd nagenoeg hetzelfde is. NSD heeft echter een lager startniveau, waardoor NSD ook van deze 2 de betere optie lijkt te zijn. De stijging van de lijn van PowerDNS is vergelijkbaar met die van Knot, hoewel het lineaire verband hier, net als bij BIND, minder sterk is. Vooral bij de lagere percentages is de toename in CPU-gebruik relatief klein. Zoals we eerder al vermeldden, zien we dat het CPU-gebruik van PowerDNS het hoogste startniveau heeft. Dat maakt PowerDNS in combinatie met de sterke stijgingsgraad de slechtst presterende nameserverimplementatie in onze metingen.

De resultaten geven aan dat hogere percentages TCP-retries consequent leiden tot een hoger CPU-gebruik, maar voor alle geteste nameserver-implementaties verloopt deze toename geleidelijk en voorspelbaar. Dit geldt met name voor NSD en Knot, waar het verband tussen het percentage TCP-retries en de CPU-tijd sterk lineair is. Dit lineaire gedrag is interessant vanuit operationeel oogpunt, omdat het aantoont dat er geen drastische prestatiedalingen te verwachten zijn als een nameserver veel TCP-verbindingen tegelijk moet verwerken. En hoewel de verschillende nameserver-implementaties uiteenlopende efficiënties laten zien, vertoont geen van hen gedrag dat problemen zou veroorzaken bij hogere TCP-percentages.

Het opzetten van meer TCP-sessies in een PQC-DNSSEC-scenario zou dan ook geen groot probleem moeten zijn. En mocht het percentage TCP-retries ooit boven de 90% uitkomen, dan suggereren onze resultaten dat het beter is om volledig over te schakelen op TCP, ongeacht welke nameserverimplementatie wordt gebruikt.

Kijkend naar de toekomst zijn er verschillende gebieden die zich lenen voor verder onderzoek. Ten eerste suggereren eerdere onderzoeken en tests dat een toename in het aantal query's per seconde via TCP kan leiden tot beperkingen in de kernel. Daarnaast zouden het geheugengebruik en andere kernelmetrics waardevolle inzichten kunnen opleveren. Toekomstig werk zou zich kunnen richten op het effect van meer TCP-verkeer op deze metrics en instellingen.

Ten tweede zou het nuttig zijn om onze metingen te herhalen in een omgeving waarin de server die de query's verstuurt zich op grotere afstand van de autoritatieve nameserver bevindt. Dat zou waarschijnlijk hogere en meer realistische RTT's opleveren, wat de impact van een toename in TCP-verbindingen zou kunnen beïnvloeden. Een mogelijke manier om dit te realiseren is door gebruik te maken van de Linux-tool tc, waarmee Traffic Control in de kernel kan worden geconfigureerd.

Tot slot zouden experimenten met zonefiles die echte PQC-handtekeningrecords bevatten, kunnen laten zien hoe vaak we in het PQC-scenario de berichten daadwerkelijk via TCP moeten versturen en wat dat zou betekenen voor de nameservers. Met deze aanpak zou het interessant zijn om te kijken naar verschillende mogelijke PQC-handtekeningenalgoritmen die wachten op standaardisatie.

Conclusie

Alle autoritatieve nameserver-implementaties die we hebben getest, kunnen een hoger aantal TCP-retries goed aan, al gaat dat wel gepaard met een hoger CPU-gebruik. Zelfs in het slechtste scenario, waarin 100% van de query's opnieuw werd verstuurd via TCP, bleef de extra belasting beheersbaar. Als dat scenario zich zou voordoen, zouden we sowieso volledig overschakelen op TCP, omdat dat in dat geval uiteindelijk efficiënter is.

Wat voor beheerders interessant kan zijn, is dat nameserver-implementaties verschillen in de mate waarin het CPU-gebruik toeneemt als het percentage TCP-retries stijgt. Van de softwareversies en configuraties die wij hebben getest, is NSD over het geheel genomen het meest efficiënt, terwijl BIND beter schaalt dan Knot en PowerDNS.

Heb je feedback of opmerkingen? Dan horen we die graag. Onze experimentele scripts en configuraties zijn op GitHub als open source beschikbaar gesteld.