Wie klopt daar? Het classificeren van recursieve resolvers bij autoritatieve nameservers

Recursieve resolvers worden vaak over het hoofd gezien waar het hun rol en belang binnen het DNS (Domein Naam Systeem) betreft. Ook wel DNS-recursors genoemd, fungeren ze als schakel tussen clients en DNS-nameservers door het internet af te gaan op zoek naar de antwoorden op queries van clients. Dankzij hun cachevermogen kunnen ze dergelijke zoekopdrachten razendsnel uitvoeren.

Resolvers kunnen allerlei soorten clients bedienen, van eindgebruikers die naar hun favoriete videostreamingsite willen tot scripts die het internet afstruinen voor marketingdoeleinden. Inzicht in welke resolvers de queries van hun belangrijkste cliënten beantwoorden zou beheerders van TLD’s zoals .nl in staat stellen te bepalen hoe ze hun serverinfrastructuur het beste kunnen inrichten om interactie met die resolvers te optimaliseren. Ook zou het handig zijn als we onze classificatiedata konden combineren met andere signalen, zoals RFC 8145, om belangrijke resolvers op te sporen die niet zijn geconfigureerd met de juiste DNSSEC trust anchors. In de aanloop naar de laatste root KSK roll-over zorgde de grote aanwezigheid van dergelijke resolvers namelijk voor problemen.

Net als onze collega's bij .nz werken we bij SIDN Labs aan een project dat zich bezighoudt met de classificatie van recursieve resolvers met als doel ons inzicht in deze materie te vergroten. Het voornaamste verschil tussen ons project en dat van .nz is dat wij verder willen gaan dan enkel ‘echte’ recursieve resolvers te onderscheiden van andere resolvers — d.w.z. resolvers die alleen worden gebruikt door monitoringtools. Onze intentie is om ook verschillende soorten resolvers te classificeren, zoals resolvers van cloudproviders, internetproviders, enzovoort. We zijn pas halverwege ons onderzoek, maar wilden in deze blogpost een aantal van onze bevindingen tot nog toe met jullie delen en zijn benieuwd naar jullie feedback.

Dataset en kenmerkselectie

We willen recursieve resolvers classificeren op basis van querydata die afkomstig zijn van de nameservers van .nl, maar in principe zouden we data van iedere grote autoritatieve nameserver kunnen gebruiken. We verzamelen queries en antwoorden van 2 van onze 4 nameservers en bewaren die in ons op Hadoop gebaseerd warehouse. De kenmerkselectie is heel belangrijk — resolvers volgen verschillende patronen bij het bevragen van .nl-domeinnamen. Om een voorbeeld te noemen: waar 82 procent van de queries die door 20 procent van de resolvers worden verstuurd betrekking hebben op IPv4- of IPv6-adressen (A- of AAAA-records), versturen sommige resolvers bijna uitsluitend queries voor NS-records. Op basis van dit soort verschillen hebben we 22 kenmerken geselecteerd waarvan we denken dat ze van pas komen bij de analyse. Sommige kenmerken, zoals het aandeel van queries naar A-records, zijn helder; andere vergen enige voorbewerking. Een van onze aannames is bijvoorbeeld dat de resolvers van internetproviders goed worden onderhouden en nieuwe standaarden meteen adopteren. Daarom proberen we bijvoorbeeld ook te detecteren of resolvers de privacybevorderende standaard QNAME minimisation ondersteunen. We hebben één dag lang data verzameld met betrekking tot 22 onderscheidende kenmerken van bijna 1,4 miljoen unieke resolvers. Daarnaast hebben we een grondwaarheid opgesteld die bestaat uit AS-nummers (ASN's) voor bekende internetproviders, hostingbedrijven, cloudproviders, enzovoort. Aan de hand van deze grondwaarheid kunnen we de nauwkeurigheid van de clusteralgoritmen bepalen.

Figure 1 — Share of queries asking for the A records of domain names

Figuur 1 — Aandeel van queries die vragen naar de A-records van domeinnamen.

Figuur 1 laat zien hoe resolvers kunnen worden onderscheiden aan de hand van querykenmerken. We zien dat de IP-adressen van TransIP, dat in onze grondwaarheid deel uitmaakt van de categorie ‘hostingbedrijven’, het meest unieke gedrag vertonen, niet alleen met betrekking tot querytype A, maar ook wat betreft een groot aantal andere kenmerken in de dataset. Dankzij dit soort onderscheidend gedrag van hostingbedrijven konden we in de clusterfase een hoge mate van nauwkeurigheid bereiken. We hebben verschillende clusteralgoritmen uitgevoerd en wisten daarmee een groot aantal hostingbedrijven met succes te identificeren. Het is ons echter niet gelukt om duidelijk onderscheid te maken tussen andere soorten resolvers. We vermoeden dat de clustering in sommige gevallen niet goed lukt vanwege ruis in de dataset. Zo hoeft niet elk IP in het AS van een internetprovider een recursieve resolver te zijn die eindgebruikers bedient.

Meer kenmerken evalueren

We hebben nog geen exacte methode gevonden voor de classificatie van recursieve resolvers. Toch kunnen we op basis van onze onderzoekswaarnemingen tot nog toe wel met enig vertrouwen concluderen dat een dergelijke classificatie mogelijk moet zijn. Als volgende stap zijn we van plan om meer kenmerken te evalueren, zodat we de classifier kunnen verbeteren. Jullie opmerkingen en/of suggesties voor hoe we dat het beste kunnen doen, zijn van harte welkom.

Deze blogpost werd ook gepubliceerd op apnic.net.

Metin Açıkalın

Metin Açıkalın

Stagair

metin.acikalin@sidn.nl

Moritz-Muller

Moritz Müller

Research engineer

+31 26 35 255 00

moritz.muller@sidn.nl

  • donderdag 5 juli 2018

    Nieuws

    Succesvol webinar over de ontwikkelingen in de Registar Scorecard

    Thumb-webinar-blue

    Bekijk het webinar en download de presentatie

    Lees meer
  • dinsdag 26 september 2017

    Nieuws

    Een gevecht op 3 fronten

    Thumb-stop-abuse

    Onze strijd tegen internetabuse

    Lees meer
  • woensdag 6 februari 2019

    Nieuws

    Google Chrome waarschuwt gebruikers voor typodomeinnamen

    Chrome+thumb

    Valse url’s herkennen is lastig

    Lees meer

Sorry

De versie van de browser die je gebruikt is verouderd en wordt niet ondersteund.
Upgrade je browser om de website optimaal te gebruiken.