Hoe gecentraliseerd wordt het DNS-verkeer?

Kernpunten

• 5 cloudproviders nemen een derde van de DNS-query’s bij 2 ccTLD’s (.nl en .nz) voor hun rekening.

• De providers verschillen onderling – soms aanzienlijk – qua adoptie en gebruik van DNSSEC, IPv6 en TCP.

• Aan de pluskant, centralisatie zorgt ervoor dat wanneer een provider een privacyvriendelijke technologie invoert, een grote gebruikersgroep hiervan profiteert.

Wellicht het meest in de schijnwerpers staan de bedenkingen geuit door regeringen, vooral in de VS, waar veel belangrijke spelers gevestigd zijn. Afgelopen oktober nog beschuldigde het Amerikaanse ministerie van Justitie (DoJ) Google formeel van het onwettelijk beschermen van haar monopolie, na een ministerieel antitrust-onderzoek naar de techreuzen. Ook het Amerikaanse Huis van Afgevaardigden veroordeelt de ‘monopoliepositie van internetgiganten‘. Toezichthouders in de EU proberen op hun beurt al geruime tijd om de macht van de ‘Big Tech’ in te perken. Maar niet alleen regeringen maken zich zorgen. Zo is er ook een IETF draft verschenen over de centralisatie van infrastructuren voor het internet, gevolgd door een publicatie in een wetenschappelijk tijdschrift. Daarnaast heeft de Internet Society een rapport gepubliceerd over de gevolgen van consolidatie voor de technische evolutie en het gebruik van het internet. Het huidige op surveillance gebaseerde bedrijfsmodel van sommige techreuzen roept bovendien ernstige privacybezwaren op. Technisch gezien verhoogt centralisatie het risico op een single point of failure. Toen Dyn, een grote DNS-provider, in 2016 werd getroffen door een massale DDoS-aanval, kon een deel van hun klanten in de VS vooraanstaande websites als Twitter, Netflix, Spotify, Airbnb, Reddit, Etsy, SoundCloud en de New York Times niet bereiken. Beweringen doen over de centralisatie van het internet is één ding, maar deze centralisatie en het effect ervan – vooral technisch gezien – meten is veel moeilijker. Eén methode waarmee mijn collega’s en ik de afgelopen tijd hebben geëxperimenteerd is het analyseren van het DNS-verkeer van cloud- en content-providers om te zien hoe marktdominantie zich verhoudt tot dominantie van het verkeer. We hebben de resultaten gepresenteerd op de ACM IMC 2020 Conference en de RIPE 81-bijeenkomst. De afgelopen 3 jaar hebben we het DNS-verkeer gegenereerd door Amazon, Google, Microsoft, Cloudflare en Facebook van autoritatieve DNS-servers in 3 verschillende zones geanalyseerd: 2 landendomeinen (ccTLD’s) – het Nederlandse .nl (6.000.000 domeinnamen) en het Nieuw-Zeelandse .nz (710.000 domeinnamen) – en B-Root, één van de 13 rootservers. We onderzochten 55,7 miljard query’s (~30 mld. van .nl, 12 mld. van .nz, en 14 mld. van B-Root), via momentopnamen in 2018-2020, zoals afgebeeld in Tabel 1 hieronder. De momentopname voor 2020 (met de duur van 1 week) toont bijvoorbeeld dat .nl 13,75 mld. query’s ontving van 1,99 mln. unieke adressen (resolvers, zowel IPv4 als IPv6), van 41.717 autonome systemen (AS’en).

Tabel 1: Geanalyseerde datasets voor .nl, .nz en B-Root DNS-servers (2018-2020).

Hoeveel verkeer komt er uit de cloud?

Om het percentage verkeer per cloudprovider (CP) te bepalen koppelden we het IP-adres van elke query-bron aan het bijbehorende AS. We telden de resultaten per AS op en gebruikten het AS van de cloud om het percentage verkeer te berekenen.

Tabel 2: Cloud/content providers en hun AS’en.

5 clouds: een derde van het verkeer

De figuur hieronder toont het percentage query’s per CP. Voor Nederland en Nieuw-Zeeland zien we dat de 5 CP’s ongeveer een derde van alle DNS-query’s voor hun rekening nemen. Dat is een opvallende concentratie, vooral gezien het feit dat de clouds samen uit slechts 20 AS’en bestaan, terwijl .nz en .nl wekelijks door zo’n 40.000 AS’en worden bezocht.

https://images.ctfassets.net/yj8364fopk6s/58LKf8syBD66putdjGsPqc/2e6ef82eaf376dd980e83bd37d43e794/Fig1_How_centralized_is_DNS_traffic_becoming.png

Het verkeer naar B-Root is minder geconcentreerd: nog geen 10% van het verkeer komt van deze clouds. Dit kan zijn omdat B-Root veel query’s van op Chromium gebaseerde browsers krijgt.

Vreemd genoeg is Google dominanter in het .nl-verkeer dan in het .nz-verkeer, wat aangeeft dat de marktpenetratie van clouds verschilt naar gelang het vantage point. En Google’s publieke DNS-dienst vertegenwoordigt het gros van de query’s: bijna 90% van alle query’s voor zowel .nz als .nl.

Om welke records vragen cloudproviders?

Het DNS bestaat uit een gedistribueerde database en kan dus worden gebruikt om verschillende soorten records op te slaan. Figuur 2 hieronder toont de populariteit per soort record voor .nl in 2018 en 2020 (de patronen voor .nz en B-Root zijn vergelijkbaar). Uit het diagram kunnen we opmaken dat A-records (IPv4-adressen) het populairst zijn, gevolgd door AAAA (IPv6-adressen).

Bij Google zien we ook een flinke stijging in NS-records (records die autoritatieve nameservers opslaan) in 2020. Vanwaar die verandering?

https://images.ctfassets.net/yj8364fopk6s/74UAmAdWusxke6gVNdZ2pC/30b5f20c8296c6db345a90042f572bd6/Fig2_How_centralized_is_DNS_traffic_becoming.png

Analyse van de querynamen wees uit dat Google in december 2019 QNAME Minimisation (RFC 7816) in gebruik heeft genomen. Resolvers die qmin ondersteunen sturen niet meer informatie over domeinnamen naar hun autoritatieve servers dan nodig is, om de privacy van gebruikers te beschermen. En RFC 7816 bepaalt dat er eerst NS-query’s moeten worden verstuurd – wat de toename in het percentage NS-query’s verklaart.

Ter controle analyseerden we Google’s NS-query’s per maand – in Figuur 3 is de verandering duidelijk te zien.

Figuur 3: Google's query’s-distributie per maand voor .nl.

Deze bevinding belicht een voordeel van centralisatie: bij het invoeren van één privacy-/veiligheidsmaatregel worden gelijk een heleboel gebruikers beschermd.

Clouds vergelijken

Aangezien al onze vantage points (.nz, .nl, en B-Root) alle clouds bedienen, kunnen we de verschillende clouds onderling vergelijken wat betreft adoptie van technologie, DNSSEC-gebruik, IPv4 vs. IPv6-verkeer, en UDP- vs. TCP-gebruik.

DNSSEC-ondersteuning

DNSSEC maakt het DNS veiliger en betrouwbaarder. Gezien hun grote omvang zou je verwachten dat de 5 CP’s allemaal even up-to-date zijn met de adoptie van DNSSEC.

We kunnen de adoptie van DNSSEC meten door het percentage DNSKEY-query’s – query’s die vragen naar een DNSKEY (een bepaald soort DNS-record) – te bepalen. Figuur 4 toont de data voor .nl in 2020 (de data voor .nz is vergelijkbaar, zoals vermeld in de paper):

• Microsoft verstuurde 0,02 mln DNSSEC-query’s, op een totaal van 1,1 mld query’s in die periode (0,001%).

• Cloudflare verstuurde er 11 mln., op een totaal van 460 mln. query’s (2,3%).

https://images.ctfassets.net/yj8364fopk6s/2wtpyrOdxfhkGMeEXQf9Ln/66183a6b2106fb131f1115a5da8c597c/Fig4_How_centralized_is_DNS_traffic_becoming.png

Het grote verschil in het percentage DNSSEC-gerelateerde query’s maakt duidelijk hoezeer de CP’s onderling verschillen qua adoptie van technologie. We kunnen er dus niet van uitgaan dat alle CP’s even up-to-date zijn.

IPv6-gebruik

Net als bij DNSSEC kunnen we het IPv6-gebruik onder de CP’s meten. We hadden ongeveer gelijke resultaten verwacht, maar er bleek nogal wat variatie te zijn, zoals te zien is in Tabel 3.

Tabel 3: Queryverdeling per CP voor ccTLD's.

Opnieuw verschilden de patronen tussen de CP’s onderling bij zowel .nz als .nl:

• Goede balans tussen IPv4/IPv6: Google, Facebook, Cloudflare

• Meer IPv6 sinds 2020: Facebook

• Zeer weinig IPv6: Amazon en Microsoft

Uit eerder onderzoek is gebleken dat resolvers bij keus uit meerdere autoritatieve servers meestal meer verkeer naar de resolver met de minste latency sturen. Ze gebruiken echter wel alle autoritatieve servers.

Dus wat zou een verklaring kunnen zijn voor de waargenomen verschillen? Eén mogelijkheid is de omvang van de resolver-infrastructuur. In Tabel 4 zien we dat Amazon en Microsoft veel minder IP-adressen hebben die de autoritatieve servers van .nz and .nl bereiken.

Tabel 4: Amazon en Microsoft DNS-resolvers (week in 2020).

Om te begrijpen waarom Facebook in 2020 meer IPv6-query’s heeft verstuurd, brachten we elk IP-adres van Facebook in kaart door middel van reverse DNS. Hierdoor konden we de IP-adressen koppelen aan namen en locaties (aangezien Facebook luchthavencodes gebruikt in de naamgeving van hun servers ).

Zoals getoond in Figuur 5 vonden we dertien locaties, waarvan locatie 1 merendeel van de query’s verstuurde. Vervolgens analyseerden we de RTT van hun TCP-query’s en constateerden dat de meeste locaties overeenkomen met de voorkeur van de resolvers:

• Locaties 8, 9 en 10 sturen voornamelijk IPv4-query’s omdat de gemiddelde RTT voor IPv4 korter is dan voor IPv6.

• De verdeling voor de overige locaties is meer gebalanceerd, omdat hun RTT’s voor IPv4 en IPv6 dichter bij elkaar liggen.

• We kunnen echter niets zeggen over de RTT van de DNS resolver op locatie 1, omdat deze locatie heel weinig TCP-query’s verstuurt. Helaas voor ons is dit ook de locatie die de meeste query’s verstuurt.

(a) Facebook locatie vs. query’s naar .nl’s server A (w2020)

(b) Percentatie IPv6-query’s en RTT naar .nl’s server A in w2020.

Figuur 5: Locatie van Facebook-resolver en het gebruik van IPv4 en IPv6 bij het opvragen van .nl's Server A (w2020).

UDP/TCP-gebruik

Tot slot bekeken we welk transportprotocol de voorkeur heeft. UDP domineert: door de enkele RTT is de responsetijd sneller – de TCP-handshake vereist een extra RTT.

Tabel 5: Percentage UDP- en TCP-query’s voor .nl en .nz.

Net als bij de andere technologieën zien we onderlinge verschillen tussen de clouds. Facebook stuurt bijvoorbeeld verhoudingsgewijs veel meer TCP-query’s dan de rest. We vroegen ons af waarom. TCP wordt meestal als fallback gebruikt bij grote responses. Als de autoritatieve server het antwoord niet in één UDP-response kan passen, moet hij de response afkorten en moeten de resolvers de server opnieuw bevragen via TCP.

De limiet voor UDP-query’s wordt gedeeltelijk bepaald door de resolvers, die hun EDNS0 buffergrootte kunnen opgeven. Hierdoor weet de autoritatieve server wat de maximale grootte van de UDP-response is die de resolver kan verwerken.

We onderzochten de door Facebook opgegeven EDNS0 buffergrootte en constateerden dat ongeveer een derde daarvan 512 bytes lang waren, wat inderdaad erg klein is. De DNS Flag Day 2020 adviseert bijvoorbeeld een buffergrootte van 1.232 bytes. Dat kan verklaren waarom meer responses worden afgekort en er meer TCP-query’s worden verstuurd.

Figuur 6: CDF van EDNS (0) UDP-berichtgrootte voor .nl (w2020).

Voor meer informatie verwijzen we naar de videopresentaties van ons onderzoekspaper op RIPE 81 en IMC 2020 en de paper zelf.

Met bijdragen van: Sebastian Castro en Wes Hardaker.