Overstappen naar een ander algoritme: invloed op ons netwerkverkeer en resolvers

Sinds een paar weken wordt .nl beveiligd met het cryptografische algoritme ECDSA P-256/SHA-256 in plaats van RSA/SHA-256. Hierdoor zijn antwoorden op vragen over .nl-domeinnamen van onze nameservers kleiner geworden. Maar om veilig over te kunnen stappen van RSA/SHA256 naar ECDSA P-256/SHA-256 was het nodig om onze zone enige tijd met beide algoritmen te ondertekenen. Dat betekende dat voor deze periode antwoorden van onze nameservers een stuk groter werden.

De fases van een rollover

De algoritme-rollover was verdeeld in meerdere fases om ervoor te zorgen dat resolvers op elk moment de .nl-zone kunnen valideren. Meer details over de verschillende fases vind je in een eerdere blogpost. Voor ons was de fase waarin de records werden ondertekend zowel met de sleutels van het oude algoritme als de sleutels van het nieuwe algoritme het meest interessant. Deze periode duurde van 5 juli tot 22 juli.

Dat betekende dat de DNSKEY-record 4 sleutels bevatte: 2 ZSK’s (Zone Signing Keys) en 2 KSK’s (Key Signing Keys). Daarnaast kwam er voor elk ondertekend record een extra handtekening bij. In de tabel beneden zie je, hoe groot de antwoorden waren voor vragen voor een niet-bestaande domeinnaam (NXDOMAIN), voor de sleutels van .nl (DNSKEY) en de nameservers (NS) voor, tijdens en na de rollover.

Tabel 1: Grootte van antwoorden op verschillende DNS-query's met de DO-flag voor, tijdens, en na de rollover (bronnen DNSViz: voor, tijdens, na).

Als we naar de tabel kijken, vallen een aantal dingen op: ten eerste is meteen te zien dat overstappen naar ECDSA voor significant kleinere antwoorden heeft gezorgd. Ten tweede, laat de tabel zien, dat de grootte van de antwoorden een klein beetje verschilt, afhankelijk van welke van de 3 nameservers het antwoord geeft. Op de nameservers draait namelijk verschillende open source nameserversoftware, die niet op dezelfde manier DNS-name compression implementeren.

Tot slot is te zien dat vooral antwoorden met responsecode NXDOMAIN tijdens de rollover erg groot waren. Om te bewijzen dat een domeinnaam niet bestaat, maken wij voor .nl gebruik van NSEC3. Daarom bevatten antwoorden met responsecode NXDOMAIN tot 3 extra ‘NSEC3’-records en de SOA-record. Elk record is op zijn beurt ondertekend. Dit betekent dat tijdens de rollover antwoorden op vragen voor niet-bestaande domeinnamen 8 in plaats van 4 handtekeningen hebben bevat.

Pakketgrootte en het DNS

Deze grootte kan invloed hebben op of een pakket via UDP of via TCP wordt verzonden. Resolvers signaleren tijdens de query hoe groot het pakket mag zijn dat ze maximaal via het transportprotocol UDP kunnen ontvangen en ook nameservers communiceren hun limiet met de resolvers. Dit wordt vastgelegd in het DNS-pakket met behulp van de parameter ‘EDNS(0) buffer size’. De kleinste van beide limieten bepaalt hoe groot een pakket, dat via UDP wordt verstuurd, ten hoogste mag zijn. Als een pakket te groot is, vraagt de nameserver de resolver om de query nog een keer te sturen via TCP. De nameserver signaleert dit door in het antwoord de ‘TC-flag’ te zetten.

Sinds de DNS Flag Day 2020 wordt aangeraden om de EDNS(0) buffer size in te stellen op 1.232 byte. Ook is het uiteraard belangrijk dat resolvers en nameservers DNS via TCP ondersteunen.

Onze nameservers ns1.dns.nl en ns4.dns.nl signaleren een EDNS-buffergrootte van 1.232 bytes en ns3.dns.nl signaleert een buffergrootte van 1.400 bytes. Een derde van de query's die wij ontvangen, worden verstuurd door resolvers die een berichtgrootte ondersteunen van maximaal 1.232 bytes. 17,4% van de berichten is afkomstig van resolvers met een EDNS buffer size van 1.400 bytes en 14% is afkomstig van resolvers die zeggen berichten van 4.096 byte groot te kunnen ontvangen. Op stats.sidnlabs.nl zie je die verdeling over de afgelopen 3 jaar. Hier zie je ook dat het aandeel query's met een buffer van 1.232 byte sinds de DNS Flag Day 2020 is toegenomen.

Aangezien de maximale pakketgrootte bepaald wordt door de minimum buffergrootte van resolver en nameserver, is het grootste pakket dat via UDP van onze nameservers wordt verstuurd 1.400 bytes. In de tabel hierboven zien we dat tijdens de rollover antwoorden voor niet-bestaande domeinnamen altijd groter zijn dan de door de nameservers ondersteunde buffergrootte. Antwoorden die NS-records bevatten, zijn in het geval van ns3.dns.nl via IPv6 ook groter dan 1.232 bytes en dus ook te groot voor minimaal een derde van de resolvers.

TCP-verkeer: Wat we hebben verwacht

Op basis van de verwachte pakketgrootte en de ondersteunde buffergrootte konden we daarom een toename aan TCP-verkeer verwachten. Maar met hoeveel?

Voor de rollover hebben we een eerste inschatting gedaan. Hiervoor hebben we berekend hoeveel query's tijdens de rollover te groot zouden zijn om via UDP verstuurd te worden (antwoord met TC-flag). Hiervoor gingen we ervan uit dat alle query's die om niet-bestaande domeinnamen vragen en ook DNSSEC-gerelateerde records als handtekeningen willen ontvangen (gesignaleerd met de DO-flag) een antwoord met de TC-flag zouden krijgen.

Ook namen we aan dat een deel van de antwoorden voor bestaande domeinnamen niet via UDP verstuurd zouden kunnen worden. Hiervoor telden we hoeveel aanvragen niet in een UDP-pakket zouden passen als het antwoord 98 byte (ongeveer de grootte van een extra ECDSA-handtekening) groot zou zijn.

Uit deze schatting bleek dat we tijdens de rollover 5,6 keer meer antwoorden zouden versturen die de TC-flag hebben gezet dan voor de rollover. Hier komt bij dat we uit ons eigen onderzoek weten dat een TC-flag niet automatisch betekent dat we 5,6 keer meer TCP-query's zouden krijgen. Het blijkt namelijk dat minimaal 15% van de antwoorden met TC-flag niet opgevolgd worden door een aanvraag via TCP. Als we hiermee rekening houden zou dat betekenen dat we ongeveer 4,7 keer meer TCP-verkeer kunnen verwachten.

The proof is in the dubbelvla

Nadat de zone ook met het nieuwe algoritme werd ondertekend, bleek dat onze schatting nog iets te conservatief was. In totaal is het aantal TCP-query's van gemiddeld 359 query's per seconde naar 2.421 query's per seconde bijna verzevenvoudigd. Het aandeel TCP-query's van de totale hoeveelheid DNS-verkeer steeg van gemiddeld 0.8% naar 4.9%.

Een groot deel van deze groei werd, zoals verwacht, veroorzaakt door aanvragen voor niet-bestaande domeinnamen. Voor de rollover waren nog rond de helft van de TCP-query's voor niet-bestaande domeinnamen, maar na de rollover groeide het aandeel naar meer dan driekwart.

Figuur 1: UDP- en TCP-verkeer voor- en nadat de .nl-zone ook met ECDSA P256 wordt ondertekend (grijze lijn).

Maar niet alleen via TCP groeide het aandeel aanvragen voor niet-bestaande domeinnamen. Het figuur beneden laat zien dat hun aandeel van de totale hoeveelheid verkeer groeide van 8.5% naar 13%. In totaal zagen we meer dan 1,6 keer zo veel vragen voor niet-bestaande domeinnamen.

Figuur 2: Antwoorden met returncode NXDOMAIN voor- en nadat de .nl-zone ook met ECDSA P256 wordt ondertekend (grijze lijn).

Wie zijn de veroorzakers van de NXDOMAIN-query's?

Zoals boven kort genoemd, zagen we al eerder dat niet alle antwoorden met TC-flag ook een query via TCP als gevolg hebben. Uit onze analyse van deze rollover blijkt dat een deel van de resolvers die op een antwoord met TC-flag niet met een TCP-query reageren het via UDP tevergeefs blijven proberen.

Om te begrijpen welke resolvers dit soort gedrag tonen, graven we dieper in onze data. Elke dag ontvangen we query's van meer dan 1.5 miljoen resolvers. Daarom focussen we voor dit artikel op resolvers die een dag na de rollover meer aanvragen hebben gestuurd dan een dag ervoor. We kiezen de 5.000 resolvers die absoluut gezien de grootste groei hebben en die voor de rollover minimaal 1.000 query's op een dag hebben gestuurd.

Meer dan de helft van deze resolvers hebben na de rollover minimaal 2 keer meer query's gestuurd dan daarvoor, maar voor vragen voor niet-bestaande domeinnamen was de toename nog groter. Bij de helft van de resolvers verviervoudigde het aantal query's voor niet-bestaande domeinnamen en bij een kwart was zelfs sprake van een verachtvoudiging.

In sommigen gevallen was dit gedrag genoeg voor onze nameservers om voor deze resolvers automatisch response-rate-limiting (RLL) in te schakelen. RLL heeft als gevolg dat de TC-flag in het antwoord wordt gezet, of dat zelfs helemaal geen antwoord meer wordt gestuurd. Het aantal query's zonder antwoord groeide dan ook tijdens de rollover van 218 QPS naar 554 QPS.

Gebrek aan TCP-ondersteuning

Wij vermoeden dat resolvers die dezelfde query over UDP blijven sturen TCP niet goed ondersteunen. Echter blijkt uit onze data dat alleen bij een deel van de resolvers dit de reden lijkt te zijn. We zagen bijvoorbeeld dat resolvers, die gebruikt worden voor grootschalige metingen van universiteiten, veel antwoorden met TC-flag hadden ontvangen, maar geen enkele query via TCP hebben gestuurd.

Het is onduidelijk wat de impact van dit soort gedrag op eindgebruikers is. Voor het geval dat een resolver geen antwoord ontvangt, zal hij vermoedelijk na een tijdje de foutmelding SERVFAIL naar de client sturen. Als een client geen andere, werkende, resolver beschikbaar heeft, zou de client geen antwoord op zijn vraag krijgen. Tijdens de rollover hebben we echter geen klachten hierover ontvangen.

Wat er na de rollover gebeurde

Na de rollover werd het weer rustiger. Het aantal aanvragen voor niet-bestaande domeinnamen is weer terug op het niveau van voor de rollover. Ook het aantal aanvragen over TCP is, zoals je op het plaatje beneden kan zien, weer gezakt – maar niet onder het niveau van voor de rollover.

Figuur 3: UDP- en TCP-verkeer nadat de .nl-zone alleen nog met ECDSA P256 ondertekend is (grijze lijn).

Hier zien we wel dat het aandeel resolvers dat minimaal een keer op een dag een TCP-query stuurt, gedaald is: rond 11% van de resolvers stuurden voor de rollover weleens een query via TCP. Na de rollover is dit cijfer gezakt naar 5%. Het lijkt er dus op dat een paar resolvers geen gebruik meer hoeven maken van een langzamere TCP-verbinding.

Hiernaast zijn er ook andere effecten meetbaar. De gemiddelde grootte van een antwoord van onze nameservers is namelijk met 18% gedaald van 373 bytes (353 bytes median) naar 306 bytes (290 bytes median). Niet slecht als je bedenkt dat onze nameservers dagelijks 3,6 miljard antwoorden of meer versturen: hierdoor verzenden we dagelijks zo’n 211 GB minder data over het internet.

Conclusie en vooruitblik

Onze nameservers moesten tijdens de rollover significant meer query's via TCP verwerken. Dit heeft, zoals eerder, niet voor problemen gezorgd maar wel wat verrassendere inzichten opgeleverd.

Zo lijken nog steeds wat resolvers niet betrouwbaar DNS via TCP te ondersteunen. En dat terwijl TCP al vanaf dag één een cruciaal onderdeel van het DNS-protocol is. De waarschijnlijk hierdoor veroorzaakte toename van aanvragen voor niet-bestaande domeinnamen is voor onze nameservers maar een kleine kanttekening, maar voor eindgebruikers van deze slecht-geconfigureerde netwerken mogelijk een groter probleem.

Dus als je het nog steeds niet hebt gedaan: controleer of je resolvers TCP ondersteunen, en voor de rest: veel plezier met de kleinere antwoorden van .nl.