DNS2Vec: representation learning toepassen op DNS-data
Eerste verkenning bevestigt veelbelovende internetsecuritytoepassingen
Representation learning is een techniek om data bondig en op een computervriendelijke manier te representeren. Het vormt de basis van veel machinelearningsuccessen van de afgelopen 10 jaar, maar is nog onbekend in de DNS-gemeenschap. We startten in 2023 daarom het project DNS2Vec, waarin we onderzoeken in hoeverre de techniek toegevoegde waarde heeft voor het DNS. Deze blog beschrijft een eerste verkenning waarin we representation learning toepassen op resolvers. Alle resultaten laten zien dat onze representaties het querygedrag van resolvers goed beschrijven en dat ze geschikt zijn voor gebruik in machinelearningtaken. Daarom gaan we ons onderzoek naar representation learning in 2024 uitbreiden.
Machine learning en de noodzaak van representaties
SIDN Labs gebruikt regelmatig machinelearningmethodes om .nl nog veiliger en robuuster te maken. Een goed voorbeeld is RegCheck waarbij we machine learning gebruiken om een inschatting te maken van de kans dat een nieuwe domeinnaam gebruikt zal gaan worden voor malafide doeleinden.
Een belangrijke voorwaarde voor het toepassen van machine learning is de aanwezigheid van een informatieve, door computers begrijpbare, beschrijving van het concept waarover een inschatting wordt gemaakt. Voorbeelden van concepten in het DNS zijn “verdachte domeinnaamregistratie” (voor RegCheck) of “resolver die .nl-domeinnamen opvraagt” (om bijvoorbeeld onze .nl-nameservers goed te optimaliseren). Deze beschrijving wordt vaak een representatie genoemd.
2 soorten representaties
Grof gezegd zijn er 2 aanpakken om tot een representatie te komen. De eerste is kennis-gedreven; hierbij wordt een representatie opgebouwd uit meerdere kenmerken die handmatig door een expert worden bepaald. Deze kenmerken dienen informatief te zijn voor het concept waarover een inschatting moet worden gemaakt. Zo is de aanwezigheid van een verdacht woord een informatief kenmerk van het concept “verdachte domeinnaamregistratie”. De kennisgedreven aanpak gebruiken we vaak bij SIDN Labs en is ook binnen de DNS-gemeenschap het meest bekend.
De tweede aanpak is datagedreven en wordt vaak representation learning of feature learning genoemd. Hierbij wordt een algoritme toegepast dat zelf kenmerken uit de data extraheert in plaats van dat een expert dat handmatig doet. De geëxtraheerde kenmerken vormen gezamenlijk een informatieve representatie van een concept, maar zijn abstract en lastig te interpreteren.
Representation learning heeft de afgelopen 10 jaar veel aan populariteit gewonnen, omdat de geëxtraheerde kenmerken concepten vaak beter beschrijven dan kennisgedreven kenmerken en ze gebruikt kunnen worden voor meerdere taken. Representation learning is alleen nog relatief onbekend in de DNS-gemeenschap.
Doel: representation learning toepassen op DNS-data
We verwachten dat representation learning ook kan bijdragen aan effectievere machinelearningtoepassingen met DNS-data en startten daarom in 2023 het project DNS2Vec. Het doel van DNS2Vec is om te verkennen of we representation learning kunnen toepassen op DNS-querydata zodat we data-gedreven representaties van DNS-concepten kunnen extraheren. Ook onderzoeken we of deze representaties geschikt zijn voor het uitvoeren van machinelearningtaken, zoals classificatie en regressie.
We richten ons in deze blog op representaties van recursieve resolvers en we focussen op eenvoudige machinelearningtaken, om efficiënt te valideren of representation learning toegevoegde waarde heeft voor SIDN Labs en de rest van de DNS-gemeenschap. Voorbeelden van DNS2Vec-toepassingen die we voorzien, zijn het optimaliseren van onze .nl-nameservers en het detecteren van afwijkende resolvers en gehackte domeinnamen.
Word2vec: een bewezen representation-learningtechniek
De techniek die we in DNS2Vec gebruiken is Word2vec (vandaar de projectnaam DNS2Vec), een bewezen techniek die onderzoekers van Google ongeveer 10 jaar geleden publiceerden. Word2vec is een techniek om semantische representaties van woorden te extraheren op basis van een grote hoeveelheid tekstuele data. Word2vec was destijds een grote doorbraak, omdat machinelearningmethodes hiermee effectiever kunnen berekenen of 2 woorden een vergelijkbare betekenis hebben.
Vanwege het succes bij tekstuele data hebben meerdere onderzoekers en bedrijven Word2vec proberen toe te passen in andere toepassingsgebieden. Zo gebruikt Spotify de techniek om representaties van muzieknummers te extraheren. Deze representaties gebruikt Spotify vervolgens in hun aanbevelingsysteem en bij het automatisch genereren van afspeellijsten.
Voor een volledige uitleg over Word2vec verwijzen we je graag naar de oorspronkelijke publicatie of deze toegankelijke uitleg. Hieronder beschrijven we beknopt Word2vec’s input en output en hoe we dit vertalen naar onze DNS-querydata die we opslaan in ENTRADA. Daarna richten we ons op de geëxtraheerde representaties en wat we hiermee kunnen.
Van tekstuele data naar DNS-querydata
De input van Word2vec is een grote hoeveelheid zinnen. De output is een representatie die bestaat uit abstracte kenmerken voor ieder uniek woord dat in die zinnen voorkomt. De representaties zijn gestoeld op de aanname dat woorden qua betekenis op elkaar lijken als ze vaak in dezelfde context voorkomen. De representaties van ‘stoel’ en ‘bank’ lijken bijvoorbeeld op elkaar omdat je beide woorden kan gebruiken in de zin ‘ik zit op een …’.
We kunnen Word2vec ook gebruiken om representaties van recursieve resolvers te verkrijgen. In plaats van een ‘normale’ zin opgebouwd uit woorden gebruiken we IP-adressen van recursieve resolvers. We construeren voor iedere domeinnaam een ‘zin’ die bestaat uit de IP-adressen van de recursieve resolvers die die domeinnaam hebben opgevraagd. Analoog aan de oorspronkelijke Word2vec-toepassing is onze aanname dat resolvers op elkaar lijken als ze vaak dezelfde domeinnamen opvragen.
Gebruikte DNS-dataset
Om representaties van recursieve resolvers te verkrijgen passen we Word2vec toe op de DNS-querydata die we verzamelden van 10 tot en met 12 september 2023. We selecteren zowel geslaagde als mislukte DNS-query’s. Domeinnamen en resolvers met minder dan 15 query’s per dag sluiten we uit, omdat we verwachten dat we hiervan geen betrouwbare representaties kunnen genereren. Ook gebruiken we downsampling om de dataset behapbaar te maken en om te voorkomen dat populaire domeinnamen te veel invloed hebben op de representaties. Downsampling passen we alleen toe boven de 1.500 query’s per domeinnaam per dag. Dit betreft 5.4% van de domeinnamen.
Tot slot geven we Word2vec de opdracht om representaties te extraheren die 30 kenmerken bevatten en gebruiken we de standaardinstellingen. In totaal beschouwde Word2vec ruim 10 miljoen unieke domeinnamen en 999.384 unieke resolvers.
Representaties van recursieve resolvers
In de rest van deze blog richtten we ons op de resolverrepresentaties die we met Word2vec extraheerden. Hierbij proberen we te achterhalen of de representaties geschikt zijn voor het uitvoeren van machinelearningtaken, zoals classificatie en regressie. We beginnen met 2 visuele analyses waarbij we kijken of de representaties informatief zijn. Dit wil zeggen dat resolvers met een vergelijkbaar querygedrag ook vergelijkbare representaties hebben, terwijl resolvers die van elkaar verschillen ook verschillende representaties zouden moeten hebben.
Figuur 1 visualiseert de output van Word2vec voor 4 recursieve resolvers. Iedere resolverrepresentatie bestaat uit 30 getallen die samen het querygedrag van een resolver beschrijven. Ieder getal is de waarde van een kenmerk, die Word2vec automatisch extraheert. Zoals we eerder benoemden zijn deze kenmerken abstract en lastig te interpreteren voor mensen, maar ze zouden wel informatief moeten zijn.
Figuur 1: Representaties van 4 recursieve DNS-resolvers. Iedere representatie bestaat uit 30 abstracte kenmerken die het querygedrag van een resolver beschrijven.
De 2 bovenste rijen in figuur 1 tonen 2 resolvers met een bijna identieke representatie. Dit wil zeggen dat Word2vec heeft geëxtraheerd dat deze resolvers verglijkbaar querygedrag vertonen. Deze extractie is correct omdat het 2 resolvers van dezelfde applicatie betreft, namelijk OpenIntel: een applicatie die dagelijks de volledige .nl-zone scant voor het uitvoeren van actieve DNS-metingen. We kunnen dit dus zien als anekdotisch bewijs dat onze representaties informatief zijn.
De derde en vierde rij tonen respectievelijk een DMAP- en Cloudflare-resolver. DMAP is onze crawler die maandelijks alle .nl-websites bezoekt. De Cloudflare-resolver maakt deel uit van de publieke open resolver 1.1.1.1 en vertegenwoordigt eindgebruikers. Deze 2 representaties verschillen sterk van elkaar en van de twee eerdergenoemde representaties. Aangezien we weten dat deze resolvers ook ander querygedrag vertonen, is dit dus extra anekdotisch bewijs dat onze representaties informatief zijn.
Clusteren van Google-resolvers
Voor de tweede visuele analyse richten we ons op de ongeveer 22 duizend resolvers die we observeerden vanuit Google’s Autonomous System. De 30 kenmerken brengen we daarnaast met t-SNE terug tot slechts 2 kenmerken, zodat we de resolvers eenvoudig kunnen plotten. Het resultaat van deze analyse zie je in figuur 2, waarbij iedere punt staat voor een Google-resolver.
Figuur 2: 22k resolvers uit Google’s AS, waarbij we de 30 kenmerken die een resolver representeren met t-SNE hebben teruggebracht tot 2 kenmerken.
Figuur 2 toont 2 categorieën Google-resolvers die we gebruiken. De eerste categorie bevat resolvers die onderdeel uitmaken van Google’s publieke resolver 8.8.8.8. Deze resolvers hebben een groene kleur. Alle overige Google-resolvers hebben een blauwe kleur. Wat opvalt is dat de 8.8.8.8-resolvers voornamelijk in de rechterbovenhoek zitten. Dit betekent dat we met 2 kenmerken al goed onderscheid kunnen maken tussen 2 categorieën Google-resolvers. Wederom aanvullend anekdotisch bewijs dat onze representaties informatief zijn.
Daarnaast is het boeiend om te zien dat er clusters van blauwe en groene puntjes verschijnen. Dit betekent dat Word2vec heeft geëxtraheerd dat er ook binnen de Google resolvers (kleine) verschillen in querygedrag bestaan. We hebben dit voor nu niet verder geanalyseerd, maar een hypothese is we hier te maken met resolvers gestationeerd in een ander land of datacentrum.
Classificeren van resolverlocatie
Figuren 1 en 2 laten zien dat onze resolverrepresentaties informatief zijn. We gaan nu bekijken of ze ook geschikt zijn voor machinelearningtaken. Dit doen we door eerst het land waar een recursieve resolver zich bevindt te classificeren, aan de hand van de representaties die we uit Word2Vec krijgen.
We beperken ons tot resolvers uit de 15 landen van waaruit we de meeste query’s zien op de .nl-nameservers. 70% van deze resolvers wijzen we toe aan de trainingset en 30% gebruiken we om testresultaten te verkrijgen. Vervolgens trainen we een eenvoudige k-nearest neighbors (k-NN) classifier, om het land van een resolver te voorspellen op basis van de 30 kenmerken uit de resolverrepresentaties.
De k-NN voorspelt bij 77% van de resolvers in de testset het correcte land en de F1-score is 60% (macro-average). Dit is een prima resultaat. Zeker als je bedenkt dat k-NN een eenvoudige methode is en we deze niet hebben geoptimaliseerd.
In Figuur 3 tonen we ook de resultaten per land. De rijen staan in dit figuur voor het daadwerkelijke land en de kolommen voor het voorspelde land. Idealiter wordt in alle gevallen het daadwerkelijke land voorspeld. De meeste fouten zijn toe te schrijven aan resolvers die ten onrechte als Duits (DE) of Amerikaans (VS) worden aangewezen.
Figuur 3: Confusion-matrix van de k-NN classifier die het land van een resolver voorspelt.
Al met al zijn we positief over deze resultaten en trekken we de voorlopige conclusie dat onze resolverrepresentaties geschikt zijn voor het uitvoeren van machinelearningtaken.
Voorspellen van aantal query’s
We gaan echter niet over een nacht ijs en willen nog een tweede taak testen, namelijk het voorspellen van het aantal query’s dat een resolver naar onze .nl-nameservers gaat versturen. Dit is bijvoorbeeld belangrijk om onze DNS-infrastructuur goed te dimensioneren.
Hiervoor trainen we een k-NN-regressor. In tegenstelling tot de vorige taak gebruiken we nu wel alle resolvers. De k-NN-regressor behaalt een R2-score van 0.88. De R2-score heeft een waarde tussen 0 en 1 (hoger is beter) en geeft aan hoeveel van de variantie in het aantal queries verklaard wordt door de regressor. Een score van 0.88 is dus een prima eerste resultaat.
Figuur 4 laat de resultaten in meer detail zien. Het goede nieuws is dat de blauwe punten met de groene lijn omhoog meebewegen. Dit betekent dat er een samenhang is tussen de daadwerkelijke waardes en de voorspelde waardes. Het slechte nieuws is dat blauwe punten vaak ver van de groenen lijn afzitten. Dit laat zien dat de k-NN-regressor veel fouten maakt.
In het kader van deze verkenning vinden we de gevonden samenhang belangrijker dan het hoge aantal fouten. De samenhang laat wat ons betreft namelijk zien dat resolverrepresentaties geschikt zijn voor regressietaken, terwijl de fouten waarschijnlijk kunnen worden verholpen door verdere optimalisaties of een complexere methode toe te passen.
Conclusie: representation learning voor het DNS is veelbelovend
In deze verkenning pasten we de bewezen techniek genaamd Word2vec toe op DNS-data om datagedreven representaties te extraheren van recursieve resolvers. We toetsten deze representaties in 2 visuele analyses en 2 machinelearningtaken. De resultaten laten zien dat de representaties het querygedrag van recursieve resolvers goed beschrijven en dat de representaties geschikt zijn voor het uitvoeren van machinelearningtaken.
We breiden ons onderzoek naar representation learning in 2024 daarom uit. Zo gaan we representation learning inzetten als fundament van een concrete machinelearningtoepassing, zoals het detecteren van afwijkende resolvers en gehackte domeinnamen. Ook willen we de representaties verbeteren door Word2vec te optimaliseren en andere methodes te verkennen. Daarnaast gaan we representation learning toepassen voor andere DNS-concepten, zoals domeinnamen. Ten slotte onderzoeken we de mogelijkheid om representaties beschikbaar te stellen aan andere wetenschappers, zodat zij ze kunnen gebruiken in hun onderzoek.
Heb je feedback op ons werk, of ideeën over hoe we representation learning kunnen toepassen binnen het DNS? Laat het ons weten via thymen.wabeke@sidn.nl.
