Monitoren van anycast-performance met Anteater

Nieuwe opensourcetool helpt DNS-operators met het monitoren en troubleshooten van hun anycast-DNS-infrastructuur.

We hebben Anteater geopensourced, een tool die we ontwikkelden voor DNS-operators om hun DNS-anycast-infrastructuur mee te monitoren. De toegevoegde waarde van Anteater is dat het DNS-operators grip geeft op de vertraging die hun clients ervaren over hun volledige autoritatieve DNS-infrastructuur heen, ongeacht of ze hun DNS-diensten in eigen beheer draaien of uitbesteden. In deze blog vertellen we hoe we in near-realtime de vertraging meten die clients daadwerkelijk ondervinden bij het bevragen van onze autoritatieve server en hoe je deze vertraging kunt monitoren met behulp van ENTRADA en Anteater.

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.

>> Lees het hele artikel op de website van SIDN Labs

Delen:
LinkedIn
Twitter