Een eigen DNS-anycast voor een toegankelijk .nl-domein
Het verhaal achter de ontwikkeling en beheer van ons eigen DNS-anycastnetwerk
Tot 6 jaar geleden hadden we bij SIDN vooral DNS-unicastservers in eigen beheer, met de focus op Nederland. Hiermee was het tot dan toe het goed geregeld, dachten we. De praktijk wees echter anders uit toen het aantal de DDoS-aanvallen op het DNS toenam. Aanvallen op de root nameservers in 2015 en die op Dyn in 2016 maakte de DNS-wereld duidelijk dat de veilig geachte infrastructuur eigenlijk heel fragiel was. Begin 2017 kregen we een DDoS-aanval op de .nl-nameservers voor de kiezen, die we met moeite hebben kunnen weerstaan.
Dit heeft ertoe geleid dat we nu beschikken over een cluster van anycastnameservers in eigen beheer met een wereldwijde dekking. In deze blogpost leggen we uit hoe dit netwerk tot stand is gekomen.
Veranderende wereld
In 2017 beschikten we over een aantal unicastnameservers in eigen beheer en een groep local-anycastnameservers, die waren gestationeerd in de netwerken van een aantal grote internetproviders. Met deze opstelling konden we het Nederlandse deel van het internet optimaal bedienen. Bovendien waren we goed voorbereid op DDoS-aanvallen, zo dachten we. Als zich een aanval zou voordoen, zouden de (flink uit de kluiten gewassen) unicastnameservers mogelijk in de problemen komen, maar dan hadden we nog altijd de local-anycastnameservers achter de hand. Die zouden de belangrijkste query’s, namelijk die van Nederlandse internetgebruikers, nog steeds kunnen beantwoorden.
Deze situatie bleek fragieler dan gedacht. De unicast-nameservers bleken niet opgewassen tegen de groei in omvang van DDoS-aanvallen. Waar in 2017 een aanval van een paar honderd gigabit per seconde nog groot was, worden deze aanvallen nu veelal in terabits gemeten. Het is dan ook niet verwonderlijk dat een relatief kleine partij als SIDN deze groei niet makkelijk kon bijbenen. Tegelijkertijd stootten ISP’s binnen Nederland datacenters af, gingen ze samenwerken, of namen ze elkaar over. Tot er uiteindelijk nog maar een paar providers in het Nederlandse gebied overbleven.
Deze trend kon je zien als reactie op een andere, namelijk die van de consolidatie van partijen die content op het internet leveren. Deze worden vaak The Big Five genoemd: Alphabet (Google), Amazon, Apple, Meta (Facebook) en Microsoft. Omdat zij belangrijke data leveren die iedereen graag wil benaderen hebben ze sterke troeven in handen om te onderhandelen met providers over schappelijke tarieven voor het aanleggen van verbindingen. Providers zien op hun beurt de datastromen naar hun netwerken steeds harder groeien. Om een sterke onderhandelingspositie in te nemen tegenover grote techbedrijven, consolideren providers en proberen ze een flinke fee te onderhandelen voor doorgifte. DNS-verkeer, hoe belangrijk ook om überhaupt content te kunnen benaderen, raakt in dit spel tussen grote partijen een beetje ondergesneeuwd. Waar contentproviders en providers onderhandelen over 100-gigabitverbindingen wordt DNS-verkeer hooguit gemeten in megabits. Providers hebben dus weinig incentive om (dure) directe koppelingen te leggen met onze local-anycastnameservers. Toen de hardware in 2019 was afgeschreven hebben we deze dan ook niet vernieuwd.
Ondertussen speelt op de achtergrond nog een andere belangrijke trend: we zijn steeds meer gaan internetten op mobiele apparaten. Deze apparaten worden bovendien gefabriceerd door een aantal van diezelfde grote contentproviders die net al aan bod kwamen: Apple en Google. Vanwege hun datahonger zijn deze apparaten vaak zo geconfigureerd dat ze gebruikmaken van resolvers binnen de netwerken van deze partijen. Het is dan ook niet verwonderlijk dat ongeveer 60% van alle query’s op het .nl-domein tegenwoordig uit Noord-Amerika lijkt te komen. Dit komt omdat de IP-adressen waar deze query’s vandaan komen toebehoren aan Amerikaanse partijen, terwijl de servers zich ook best in West-Europa kunnen bevinden. Niettemin werd ons al snel duidelijk dat het belangrijk is om zelf te beschikken over een netwerk van nameservers met globale dekking, om alle query’s vanuit deze megagrote netwerken snel en efficiënt te kunnen beantwoorden. Op basis van metingen van bijvoorbeeld SIDN Labs, was anycast de enige logische keuze. Vooral latency wordt nadelig beïnvloed door het hebben van een unicastserver in de opzet.
De eerste stap naar volledig anycast: snel inkopen
Door de aanvallen op het DNS besloten we in 2017 om als eerste stap in het ‘veranycasten’ van .nl in te zetten op het inkopen van anycastdiensten. We onderhandelen opnieuw met Netnod over hun dienst, die we al vanaf 1999 in gebruik hadden. Hierbij hebben we de dienst niet alleen voor .nl, maar ook voor .amsterdam, .politie en .aw bedongen. Daarnaast sloten we contracten met CIRA en nic.at. Daarnaast gebruikten we ook nog de gratis dienst van ISC (SNS-PB), maar er werd al aangekondigd dat deze dienst snel zou stoppen. Zo hadden we begin 2018 4 DNS-anycastservers voor de door ons beheerde TLD’s in gebruik.
Tweede stap: SIDN weer zelf aan het roer
Eind 2019 realiseerden we ons dat het beter was om voor het behoud en het kunnen uitbreiden van de kennis van het DNS binnen SIDN, om zelf ook een DNS-anycastomgeving te beheren. In 2020 startte SIDN Labs een onderzoek naar de mogelijkheden om op een moderne manier een eigen DNS-anycastplatform uit te rollen. Gedurende dat jaar kwamen veel zaken naar boven waarop wij een eigen operationeel platform konden bouwen. Je leest hier meer over in een eerder verschenen blogpost van SIDN Labs.
We besloten een eigen DNS-anycastplatform te bouwen dat als ns1.dns.nl zou gaan draaien. Hiervoor moest een globaal DNS-anycastnetwerk gebouwd worden, dat snel uit te breiden was. Vanwege de eisen die SIDN stelt aan een .nl-nameserver werd bare metal ingekocht bij Packet (nu Equinix). Deze apparatuur gebruikte SIDN Labs ook in zijn testbed.
Eind 2021 startten we daadwerkelijk met de bouw van het eigen DNS-anycastnetwerk. Ook werd er een DNS-team geformeerd binnen de organisatie, dat het bouwen en later het beheren van het anycastplatform als hoofdtaak had en heeft. Het team werkt volgens het DevOps-principe met tweewekelijkse sprints om snel tot resultaten te komen.
Uitdagingen
We hebben de nodige uitdagingen gekend met dit project. Allereerst organisatorisch, om tot een DevOps-team voor het DNS binnen SIDN te komen. Inmiddels staat er een professioneel zeskoppig team met BGP/DNS-engineers. Daarnaast hadden we ook technische uitdagingen. We wilden het hele traject van bouwen tot uitrollen van anycastnodes volledig automatiseren door de inzet van een CI/CD pipeline. Die kennis moest en passant aangeleerd worden.
GitOps: beheers alle bewegende delen
Een architectuurprincipe is dat code in git (software voor versie beheer) een echte afspiegeling zou moeten zijn van de productieservers:
Bouw, test en uitrollen van een gouden image met een CI/CD pipeline;
Alle wijzigingen hebben een versie/commit;
Mogelijkheid om voor- en achteruit te gaan met releases;
Dwing eenzelfde configuratie en patches af door regelmatig opnieuw uitrollen.
Het op deze manier uitrollen van anycastnodes past perfect bij het DNS. DNS is bijna zonder state, en anycast zorgt voor loadbalancing en fault tolerance. Er is na de uitrol heel weinig configuratiemanagement nodig, en zonedata kunnen automatisch worden opgehaald. Daarnaast moeten PCAP en andere statistieken snel worden overgedragen aan de beheerssystemen.
In de CI/CD pipeline wordt een image gebouwd in 3 stappen, waarbij gestart wordt met een minimaal OS image. Uiteindelijk wordt er een volledig nameserver-image opgeleverd, dat uitgerold kan worden. In de pipeline zijn securityscans en functionele testen opgenomen, om de kwaliteit van het eindproduct te waarborgen. Om te zorgen dat dit image gebruikt kan worden voor de uitrol, wordt het platgeslagen en opgeslagen in de cloud.
(Klik op de afbeelding om deze te vergroten.)
Figuur 1 Overzicht van de CI/CD pipeline voor de uitrol van anycastnode voor .nl.
Om ervaring op te doen met het uitrollen van de systemen is besloten om dit handmatig uit te voeren. De stappen die doorlopen worden bij het uitrollen is het image starten op een bare metal-server. Bij deze uitrol worden continu controles uitgevoerd, die de resultaten terugkoppelen aan de pipeline. Elke stap in de uitrol is zichtbaar in een tijdlijn. Vervolgens worden de diverse zones geladen (.nl, .aw, etc.). Zodra in de tijdlijn wordt gerapporteerd dat alle zones zijn geladen, wordt BGP aangezet. Dan is de node onderdeel geworden van het DNS-anycastplatform. Inmiddels kunnen we nu overal in de wereld binnen 10 minuten een node actief maken met behulp van deze pipeline.
We hebben het DNS-anycastnetwerk voor .nl gelanceerd op 11 april 2022.
Toekomstig werk
We zijn nu een jaar verder waarin we steeds verder hebben gebouwd aan het platform, maar ook aan verbeteringen aan onze DNSSEC-omgeving. Denk hierbij aan de wijzingen aan NSEC3 voor .nl. En op dit moment werken we aan de algoritme rollover van RSA/SHA-256 naar ECDSA Curve P-256. Hierover vertellen we binnenkort meer in een separate blogpost. Voor het DNS-anycastplatform willen we bekijken of we ook echt de juiste software hebben gebruikt in de diverse stappen in de pipeline. Ook gaan we kijken naar de mogelijkheden voor het volledig automatisch uitrollen van nodes nadat een nieuwe image is gebouwd. Ten slotte willen we meer gebruikmaken van statistieken, om de bereikbaarheid van .nl nog verder te verbeteren door op meer locaties in de wereld extra nodes uit te rollen. Daarnaast gaan we binnen CENTR, waarin overwegend Europese registry’s zijn vertegenwoordigd, kijken of we als ccTLD-operators elkaar kunnen helpen door diensten zoals ons anycastnetwerk met elkaar uit te kunnen wisselen.
