Monitoren van anycast-performance met Anteater

Nieuwe opensourcetool helpt DNS-operators met het monitoren en troubleshooten van hun anycast-DNS-infrastructuur.
Artikel door: Giovane Moura en Cristian Hesselman

DNS-operators en de uitdaging van het leveren van snelle reactietijden

DNS-operators streven ernaar om DNS-antwoorden snel bij hun clients te krijgen – laten we zeggen binnen 50 ms en hopelijk sneller. Toch weten ze meestal niet precies welke vertraging de clients ervaren. Hoe komt dat?

Het antwoord op deze vraag is dat DNS-operators geen toegang hebben tot de netwerken van hun clients, waardoor ze vanuit die netwerken geen query’s kunnen versturen om de RTT’s (round-trip times) te meten. Er zijn wel manieren om aan die data te komen, bijvoorbeeld door gebruik te maken van RIPE Atlas (~10.000 meetpunten in clientnetwerken). Dat soort tools beslaan echter lang niet alle netwerken waarvan een grote DNS-operator de clients bedient.

Dus wat zijn de alternatieven? Je zou Verfploeter kunnen inzetten, maar daarvoor zijn actieve metingen vanuit het anycast-netwerk zelf nodig. Dit is ingewikkeld, omdat veel operationsteams geen volledige toegang tot hun nameservers hebben, vooral als ze die huren van derden. Daar komt nog bij dat Verfploeter geen IPv6 ondersteunt, wat betekent dat de RTT’s van DNS-query’s/antwoorden die over IPv6 worden verzonden niet in de metingen worden opgenomen.

We vroegen ons daarom af of we een andere aanpak konden bedenken die:

• geen extra metingen vereist;
• IPv6 ondersteunt; en
• RTT’s van daadwerkelijke clients meet in plaats van clients uit willekeurige netwerken.

Onze aanpak: RTT’s meten met behulp van DNS over TCP

Er bleek nog een andere, enigszins over het hoofd geziene aanpak te bestaan: het eigen verkeer dat een DNS-operator verwerkt en dan in het bijzonder over TCP verzonden DNS-query’s. DNS ondersteunt zowel TCP als UDP, waarbij TCP wordt gebruikt voor grote antwoorden na truncation (of zoneoverdrachten). Aangezien TCP vereist dat er een sessie tot stand wordt gebracht, kunnen we meten wat de RTT van client naar server is tijdens de TCP-handshake (het tijdsverschil tussen het eerste en derde pakket).

Samen met collega’s van het Information Sciences Institute van de University of Southern California (USC/ISI) hebben we een technisch rapport gepubliceerd met een gedetailleerde beschrijving van deze meetmethode. In het rapport tonen we aan dat de aanpak kan worden gehanteerd om de RTT’s van daadwerkelijke clients te meten en leggen we uit hoe de methode kan worden ingezet. (Je kunt ook de videopresentatie tijdens DNS-OARC en de bijbehorende slides bekijken.)

Voor DNS-operators is het grootste voordeel dat RTT-metingen van DNS over TCP zich in de eigen DNS-infrastructuur bevinden. Je hoeft niets extra’s voor de data te doen, alleen nog maar analyseren. En dat is precies wat onze opensourcetool Anteater doet. Je kunt Anteater downloaden op onze GitHub-pagina.

Gebruikmaken van TCP RTT met Anteater

Figuur 1 laat een anycast-server met 5 locaties (A1—A5) zien. Clients, zoals de resolver van een ISP, worden uiteindelijk door BGP naar een van de 5 locaties geleid. Bij SIDN verzamelen we verkeer van onze anycast-locaties en exporteren dat naar ENTRADA, ons opensource DNS-datastreaming warehouse. ENTRADA is een op Hadoop gebaseerde toepassing die lastig te verwerken pcap-bestanden converteert naar een indeling die gemakkelijk kan worden bevraagd met SQL.

Figuur 1: Pijplijn van Anteater.

Anteater haalt data uit ENTRADA, aggregeert deze volgens verschillende criteria (servers, serverlocaties, specifieke autonome systemen) en slaat ze dan op in een PostgreSQL-database. ENTRADA berekent tijdens de TCP-handshake automatisch wat de RTT is en voegt een eigen database toe, wat ons leven een stuk makkelijker maakt. De laatste stap bestaat uit het configureren van een Grafana-dashboard, waarvoor we geautomatiseerde scripts hebben toegevoegd.

Je servers monitoren in (bijna-)realtime

Wat kan Anteater voor jou als DNS-operator betekenen? Allereerst kun je nu, in realtime, de RTT’s zien die je servers aan hun clients leveren. Figuur 2 toont per uur de metingen voor de autoritatieve servers van .nl voor zowel IPv4 als IPv6. Bij SIDN gebruiken we Anteater nu al ruim anderhalf jaar. Zoals je in figuur 2 kunt zien, is de gemiddelde responstijd van onze servers 34 ms.

Figuur 2: Anteater/Grafana-grafiek: RTT per autoritatieve server/IP-versie. We kunnen de RTT ook weergeven per anycast-locatie (elke plek op het internet waarvandaan een server wordt aangekondigd). Figuur 3 laat voor elke anycast-locatie van een van de autoritatieve servers van .nl de RTT in ms zien voor IPv6. In deze afbeelding vertegenwoordigt elke lijn een locatie (AMX = Amsterdam, BER = Berlijn, CGO = Parijs) en is te zien hoe de RTT’s in de loop van de tijd veranderen. Als vuistregel hanteren we dat een locatie met RTT’s van meer dan 100 ms moet worden onderzocht.

Figuur 3: RTT per anycast-locatie, voor IPv6, van een van de autoritatieve servers van .nl.

Opsporen van problemen met specifieke clients

Een situatie die zich vorig jaar voordeed, illustreert de praktische toepassing van de methode. In 2020 ontdekten we dat Google (AS15169) te kampen had met veel vertraging naar een van onze servers. Deze forse vertraging detecteerden we met Anteater, waarna we in staat waren om de hoofdoorzaak van het probleem te achterhalen en het probleem te verhelpen. Het bleek dat Google werd ‘gepolariseerd’ naar deze anycast-server en daardoor slechts een van de 5 beschikbare locaties kon bereiken. Je leest hier meer over in het technische rapport, maar in samenwerking met Google wisten we het probleem op te lossen, waarna de RTT met maar liefst 90 ms afnam, van 100 ms naar 10 ms.

Dit zie je in de afbeelding hieronder: de rode lijn toont de totale gemiddelde RTT van Google naar de server in kwestie, voor alle locaties. In de fase ‘Announced’ was de RTT 100 ms. Nadat we het probleem hadden opgelost, daalde de RTT naar ongeveer 10 ms in de laatste fase (‘Tuning’, waarbij BGP werd gemanipuleerd; zie technisch rapport). Zonder Anteater en DNS-over-TCP-metingen zouden we niet van dit probleem hebben geweten.

Figuur 4: RTT tussen Google (AS15169) en een van de autoritatieve servers van .nl — gemeten met DNS/TCP.

Indirect routelekken detecteren met Anteater

Anteater kan ook worden ingeschakeld om routeringsproblemen indirect te detecteren. Ook dit staat beschreven in ons technische rapport, waarin we laten zien hoe een anycast-locatie van .nl plotseling heel veel verkeer te verwerken kreeg, dat afkomstig was van een groot aantal verschillende, overwegend Europese, netwerken. Zoals te zien is in figuur 5, steeg rond 16.00 uur het aantal resolvers dat de locatie bereikte tot 60.000 per uur, tegenover nog geen 5.000 per uur voor die tijd. De queryfrequentie verdrievoudigde.

Figuur 5: Routelekken en toenames in de queryfrequentie en het aantal resolvers op de locatie Sydney.

We analyseerden de RTT voor deze locatie – die zich bevond in Sydney, Australië – zoals weergegeven in Figuur 6. Zoals je ziet, was de RTT eerst minder dan 50 ms, maar steeg deze na 4 uur ’s middags tot meer dan 200 ms.

Figuur 6: Stijging van RTT’s op anycast-locatie in Sydney.

We namen contact op met de operator, die al met het probleem bezig was en dit kon verhelpen nadat we hadden vastgesteld dat een Tier-1 ISP per vergissing de anycast-prefix voor Sydney had doorgegeven aan al zijn peers over de hele wereld. Omdat de Tier 1 ISP een heel groot bereik heeft, werden veel clients in de EU geleid naar de locatie in Australië, die geografisch gezien op grote afstand ligt en daardoor een hoge RTT heeft. Met Anteater kunnen we instellen dat er Grafana-waarschuwingen worden verzonden wanneer zich iets dergelijks voordoet (bijvoorbeeld ‘notify me when RTT > 100 ms for all sites’).

In dit specifieke geval trok de operator eerst de routeaankondigingen in. Dat is de reden dat we geen query’s zien op de dag erna. Rond 12.00 uur hervatte de operator het aankondigen van de route, waarna de RTT voor de .nl-server in Sydney weer normale waarden liet zien. Aangezien de anycast-service in kwestie wordt beheerd door een derde partij, zou het voor ons lastig zijn om dit soort situaties op te merken zonder Anteater (en ENTRADA DNS/TCP RTT-metingen).

Het laatste dashboard dat we hebben opgenomen in Anteater, is voor het monitoren van de RTT’s naar specifieke autonome systemen. We weten bijvoorbeeld dat een derde van het DNS-verkeer van .nl (en .nz) afkomstig is van 5 grote cloudproviders, waardoor het belangrijk is om te zorgen voor snelle responstijden (<40 ms) naar de betreffende providers. Figuur 7 hieronder toont de RTT-metingen voor verschillende AS’en over IPv4. Zoals je ziet, gelden voor de meeste AS’en RTT’s van minder dan 30 ms, wat als goed wordt beschouwd. Afwijkingen hiervan kunnen te wijten zijn aan netwerkproblemen en daarom hebben we waarschuwingen ingesteld die daarop attenderen.

Figuur 7: RTT’s van grote cloudproviders (Hyper Giants) naar autoritatieve servers van .nl.

Samenvattend

DNS over TCP levert belangrijke informatie die kan worden gebruikt om anycast-netwerken te monitoren en problemen op te lossen, waardoor DNS-operators hun controle over de RTT’s van hun autoritatieve DNS-servers verder kunnen vergroten. Zoals beschreven in deze blog, kan onze opensourcetool Anteater worden ingezet om anycast-DNS-systemen in bijna-realtime te monitoren. We werken bij SIDN al ruim anderhalf jaar met Anteater en we hopen dat andere DNS operators er ook hun voordeel mee kunnen doen om zo de stabiliteit van het hele DNS te verhogen.

Bron: https://www.sidnlabs.nl/nieuws-en-blogs/monitoren-van-anycast-performance-met-anteater