Fragmentatie, afkapping en time-outs: vallen grote DNS-berichten in stukken uit elkaar?
Onze analyse op basis van 164 miljard DNS-query’s
De oorspronkelijke blog is in het Engels. Dit is de Nederlandse vertaling.
Het Domain Name System (DNS) vormt een van de kerndiensten van het internet. Het DNS gebruikt zowel UDP als TCP als transportprotocol en de meeste responses worden verstuurd via UDP, omdat het snel is (1 RTT). UDP is echter niet altijd geschikt om grote DNS-responses af te leveren: pakketten kunnen worden gedropt en gefragmenteerd en daardoor is er een risico dat clients de responses niet ontvangen. Dit kan leiden tot onbereikbaarheid. Om te bepalen hoe ernstig het probleem met grote berichten in het DNS is, analyseerden we 164 miljard DNS-query's/responses die we gedurende 3 volle maanden (juli 2019, juli 2020 en oktober 2020) verzamelden op de autoritatieve servers van .nl, het Nederlandse ccTLD. In deze blog presenteren we de belangrijkste resultaten van een paper die we publiceerden tijdens de Passive and Active Measurements Conference (PAM2021).
DNS-vertragingen
Niemand vindt het leuk om te moeten wachten tot een internetpagina is geladen. Het DNS kan een van de redenen zijn waarom het laden van pagina's traag verloopt. Een pagina kan namelijk pas worden geladen als het DNS de domeinnaam heeft omgezet naar een IP-adres.
Met DNS via UDP (DNS/UDP) gaat dit sneller, omdat het maar één round-trip time (RTT) vergt. Aangezien het ontwerp van UDP geen aflevergaranties biedt, kan het DNS ook worden gebruikt via TCP (DNS/TCP), maar dan vergt het 2 RTT’s om dezelfde responses op te halen (de TCP-handshake kost een extra RTT).
DNS/UDP versus DNS/TCP
DNS/UDP is dus sneller dan DNS/TCP, maar heeft ook een nadeel: het heeft moeite met het verwerken van grote berichten, omdat volgens de oorspronkelijke DNS-specificatie UDP-berichten niet groter mochten zijn dan 512 bytes. Dat was in veel gevallen natuurlijk niet genoeg en daarom werd in 1999 EDNS0 voorgesteld, waarmee het mogelijk werd om UDP-berichten uit te breiden tot 64 kilobytes.
Met EDNS0 kunnen DNS-clients (resolvers) hun UDP-buffer doorgeven aan de autoritatieve servers, die vervolgens bij het versturen van responses die waarde hanteren als bovengrens. Als een respons echter groter was dan de door de client opgegeven EDNS0-buffer, werd deze door de autoritatieve server afgekapt en gemarkeerd (TC bit). De resolver gebruikte dat signaal om daarna de query opnieuw te versturen, maar dan met DNS/TCP.
Geruisloos verwijderd
Het probleem was dat dit allemaal gebeurde op de applicatielaag, die geen weet heeft van de onderliggende netwerklaag. Met andere woorden, bij de bufferonderhandelingen werd geen rekening gehouden met de Maximum Transmission Unit (MTU) van het pad tussen de client en de autoritatieve server – en de gangbare MTU in de kern van het internet is 1.500 bytes. Als DNS-responses groter waren dan de MTU voor het pad, werden die pakketten onderweg simpelweg gefragmenteerd of verwijderd. Daarbij komt nog dat IPv4-fragmentatie zo gebrekkig ontworpen is dat het tegenwoordig wordt beschouwd als fragiel en moet worden vermeden.
In het ergste geval worden responses geruisloos verwijderd en ontvangen clients nooit een DNS-respons, waardoor het hen in feite onmogelijk wordt gemaakt om de gewenste URL te bereiken.
164 miljard query's
Hoewel dit probleem al meerdere malen is onderzocht, gebruikten wij een ander soort meetpunt: 2 autoritatieve anycast-servers van .nl. Zoals te zien is in tabel 1, analyseerden we 164 miljard query's, die we verzamelden met behulp van ENTRADA, onze tool voor het analyseren van DNS-‘big data’.
juli 219 | juli 2020 | oktober 2020 | ||||
|---|---|---|---|---|---|---|
IPv4 | IPv6 | IPv4 | IPv6 | IPv4 | IPv6 | |
Query's/responses | 29,79B | 7,80B | 45,38B | 15,87B | 48,58B | 16,62B |
UDP | 28,68B | 7,54B | 43,75B | 15,01B | 46,94B | 15,87B |
UDP TC off | 27,80B | 7,24B | 42,06B | 13,88B | 45,49B | 14,93B |
UDP TC on | 0,87B | 0,31B | 1,69B | 1,14B | 1,44B | 0,93B |
Ratio (%) | 2,93% | 3,91% | 3,72% | 7,15% | 2,96% | 5,59% |
TCP | 1,11B | 0,25B | 1,36B | 0,85B | 0,36B | 0,20B |
Ratio (%) | 3,72% | 3,32% | 3,59% | 5,37% | 3,17% | 5,09% |
Resolvers | ||||||
UDP TC off | 3,09M | 0,35M | 2,99M | 0,67M | 3,12M | 0,62M |
UDP TC on | 0,61M | 0,08M | 0,85M | 0,12M | 0,87M | 0,13M |
TCP | 0,61M | 0,08M | 0,83M | 0,12M | 0,87M | 0,13M |
ASes | ||||||
UDP TC off | 44,8k | 8,3k | 45,6k | 8,5k | 46,4k | 8,8k |
UDP TC on | 23,3k | 8,3k | 27,6k | 5,4k | 28,2k | 5,6k |
TCP | 23,5k | 4,3k | 27,3k | 5,2k | 27,9k | 5,4k |
Tabel 1: Datasets uit de .nl-zone.
Datasets
We verzamelden data van 2 autoritatieve anycast-servers van .nl (NS1 en NS3, beheerd door 2 verschillende anycast-providers). Deze worden gecombineerd weergegeven in tabel 1. We maakten 3 momentopnames: de eerste in juli 2019, de tweede een jaar later in juli 2020 en de laatste in oktober 2020, een maand na DNS Flag Day 2020.
Op onze meetpunten zien we dat een klein deel van de responses wordt afgekapt: 2,93% tot 7,15%, afhankelijk van het jaar en de IP-versie. Dit is het uitgangspunt van onze analyse.
Bevinding 1: Grote responses zijn zeldzaam
Als eerste analyse berekenden we de distributie van de responsgroottes die onze servers verstuurden. In figuur 1 zien we dat 99,99% van de responses van de .nl-servers kleiner is dan 1.232 bytes (verticale stippellijn), de door DNS Flag Day 2020 voorgestelde grootte. Nou denk je misschien: ja, maar dat geldt alleen voor de .nl-zone. Maar volgens Google Public DNS, de grootste publieke resolverdienst op het internet, is 99,7% van hun verkeer ook kleiner dan 1.232 bytes.
Figuur 1: responsgroottes per server/IP-versie voor juli 2020.
Anders dan we verwachtten, waren de grootste responses voor A- en AAAA-records van de autoritatieve .nl-servers, en niet voor DNSSEC-records. Bovendien verschilde de grootte van de responses per server: NS1 is geconfigureerd voor het terugsturen van minimale responses en NS3 niet. Minimale DNS-responses voorkomen dus in feite dat er extra records worden toegevoegd aan de additional section, waardoor de responsgrootte van het bericht beperkt wordt.
Bevinding 2: Fragmentatie vindt zelden plaats aan de serverzijde
IP-fragmentatie kan voorkomen aan de serverzijde en onderweg, maar alleen met IPv4. IPv6 staat fragmentatie binnen het netwerk niet toe. We analyseerden daarom per server en per IP-versie het aantal door onze servers verstuurde gefragmenteerde responses.
Figuur 2 laat de resultaten zien. Er worden maar heel weinig responses gefragmenteerd: minder dan 10.000 per dag. Ter vergelijking: we zien dagelijks in totaal 1 à 2 miljard query's (zie tabel 1). In de paper laten we een actieve meting met Ripe Atlas zien waarbij we fragmentatie binnen het netwerk meten. We constateerden dat in het veld 4,4% van alle query's via IPv4 wordt gefragmenteerd op netwerkniveau.
Figuur 2: Gefragmenteerde UDP-query's voor autoritatieve .nl-servers.
Bevinding 3: Kleine EDNS0-buffers leiden tot afkapping, grotere voorkomen het niet
In Tabel 1 zagen we al dat 2,93 tot 7,15% van alle UDP-responses wordt afgekapt. Nu gaan we kijken naar hoe dat komt. Figuur 3 toont de Cumulative Distribution Function (CDF) van zowel de responsgroottes als de EDNS0-buffergroottes voor NS1. We zien dat de meeste DNS/UDP-query's worden afgekapt tot waarden onder 512 bytes, ongeacht de IP-versie.
Figuur 3: NS1: CDF van afgekapte DNS/UDP-responses voor .nl: juli 2020.
Ook zien we dat de meeste buffergroottes gelijk zijn aan 512 bytes (linker verticale stippellijn), wat vrij klein is. Als je naar de paarse lijn voor IPv4 kijkt, heeft 13% van de query's die binnenkomen op NS1 gek genoeg geen EDNS0-extensie. We ontdekten dat deze query's afkomstig waren van 2 AS’en die vreemd gedrag vertonen en alleen query's sturen naar NS1 (sticky resolvers).
Dus, wanneer een resolver een afgekapte respons binnenkrijgt, moet dezelfde query opnieuw worden verstuurd, maar dan via DNS/TCP. We constateerden dat dit in 80% van de gevallen gebeurt, zoals te zien is in figuur 4.
Figuur 4: Afgekapte DNS/UDP-responses gevolgd door TCP-query's.
Bevinding 4: Directe overname van aanbeveling DNS Flag Day 2020 was beperkt, maar operators passen zich langzaam aan
Tijdens DNS Flag Day 2020 werd operators van resolverdiensten geadviseerd om hun EDNS0-buffergrootte in te stellen op 1.232 bytes. Dat zou de grote buffers die we in figuur 5 zien verkleinen en fragmentatie en afkapping voorkomen.
We vergeleken daarom de dataset van oktober 2020 met die van juli 2020 om te meten in hoeverre deze aanbeveling was opgevolgd. We namen alle resolvers die in beide datasets voorkwamen en keken hoeveel waren gemigreerd naar een EDNS-buffergrootte van 1.232 bytes.
Van de 1,85 miljoen resolvers (unieke IP-adressen) bleken er ten opzichte van juli 2020 slechts 11.338 te zijn overgestapt op 1.232 bytes, wat suggereert dat Flag Day voor operators geen aanleiding was om hun instellingen onmiddellijk te wijzigen.
We hebben echter ook gekeken naar de dagelijkse distributie over een periode van ongeveer anderhalf jaar, zoals weergegeven in figuur 5. Dan zien we dat eind mei 2021 9% van de resolvers 1.232 bytes aankondigen – 2 keer zoveel als een jaar eerder. De meerderheid hanteert echter nog steeds 4.096 bytes of andere waarden.
Figuur 5: Dagelijkse EDNS-bufferdistributie door resolvers (y-as in log2-schaal).
Samenvatting
Dit onderzoek is een aanvulling op eerdere onderzoeken naar fragmentatie en afkapping in het DNS. Grote responses zijn zeldzaam in het DNS, maar ze bestaan en kunnen worden voorkomen als meer resolvers kleinere buffergroottes hanteren. Fragmentatie aan serverzijde komt zowel met IPv4 als met IPv6 nauwelijks voor, maar fragmentatie binnen het netwerk is nog steeds aanwezig (4,4% voor IPv4, vergelijkbaar met eerdere onderzoeken). DNS Flag Day 2020 had enige impact, maar DNS-operators namen de aanbevelingen slechts langzaam over.
Deze blog is gebaseerd op een peer-reviewed paper.
