Onze DNS-infrastructuur in beeld
Hoe we ervoor zorgen dat .nl altijd, overal en snel bereikbaar is
Kies jouw kleur
Veel bezocht
Veelgestelde vragen
Via de Whois kun je de huidige houder van een domeinnaam opzoeken. Om de persoonsgegevens in te zien moet je vanwege de privacygevoelige informatie eerst de gebruikersvoorwaarden van de Whois accepteren. Gegevens van privé personen kunnen ook afgeschermd zijn vanwege de AVG (Algemene verordening gegevensbescherming).
Op de pagina domeinnaam zoeken lees je meer over wat een domeinnaam is, de werking van de Whois en de privacy van persoonsgegevens.
Je wilt je domeinnaam verhuizen naar een andere registrar. Vraag dan je verhuistoken op bij je huidige registrar. Lees de verhuisstappen op de pagina domeinnaam verhuizen.
Neem contact op met je registrar. Jouw registrar kan de contactgegevens bij je domeinnaam voor je aanpassen. Wij raden je aan het resultaat te controleren via de Whois. Lees meer over het aanpassen van je gegevens bij contactgegevens wijzigen.
Wij weten niet wat de reden van de opheffing is. Neem contact op met je registrar. Het voordeel van de quarantaine is dat je altijd de mogelijkheid hebt om een opheffing die je niet had bedoeld te herstellen.
Voorbeeld: In de voorwaarden van je registrar staat dat je elk jaar je abonnement moet verlengen. Dat gebeurt dan niet automatisch. Zo kan het gebeuren dat je domeinnaam wordt opgeheven zonder dat je er om gevraagd hebt.
Wanneer je een klacht hebt over of een geschil met je registrar dan zijn er verschillende mogelijkheden om tot een oplossing te komen. Hierover lees je meer op pagina klacht over registrar. SIDN heeft geen formele klachtenprocedure voor het behandelen van een klacht over jouw registrar.
Wil je zelf direct domeinnamen kunnen registreren bij SIDN voor je klanten of voor je eigen organisatie? Dan kun je .nl-registrar worden. Lees meer over de voorwaarden en de manier waarop je je kunt inschrijven als registrar via de pagina registrar worden.
Hoe we ervoor zorgen dat .nl altijd, overal en snel bereikbaar is
Eén van de kerntaken van SIDN is om .nl altijd, overal en snel bereikbaar te maken voor iedereen op het internet. Dat is geen eenvoudige taak, want het internet is voortdurend onderhevig aan verandering en staat continu onder druk van cyberdreigingen. In deze blog beschrijven we hoe ons DNS team de DNS infrastructuur uitrolt en beheert, en de nieuwe dashboards die SIDN Labs ontwikkelde om het monitoren ervan makkelijk te maken.
SIDN zorgt ervoor dat alle .nl-domeinnamen met alle bijbehorende gegevens op een centrale plek geregistreerd staan. Maar dat niet alleen! We zorgen ook voor de publicatie van die informatie in het DNS (domain name system), zodat jouw computer kan opzoeken welke IP-adressen bij welke domeinnaam horen.
Welke IP-adressen bij een domeinnaam horen kan worden opgevraagd bij de authoritative name server van die domeinnaam. En waar je de nameservers van alle .nl-domeinnamen kan vinden kan je dan weer opvragen bij de autoritatieve nameservers van .nl, die wij beheren. Het opvragen van DNS-informatie doet je computer ongemerkt, ‘onder de motorkap’, en gebeurt vaak: we krijgen zo’n 4 miljard DNS-query’s voor .nl per dag, van over de hele wereld vandaan.
Zonder de autoritatieve nameservers van .nl zou niemand antwoord krijgen op DNS-query’s voor domeinnamen die eindigen op .nl. Daardoor zouden alle .nl-websites praktisch onbereikbaar zijn. Het is daarom uitermate belangrijk dat de .nl-nameservers altijd bereikbaar zijn. Het is ook van belang dat onze nameservers snel bereikbaar zijn, overal ter wereld vandaan; we willen niet dat het laden van een .nl-website door een trage nameserver extra lang duurt.
Om dit te bereiken nemen we een aantal stappen.
Ten eerste maken we gebruik van IP-anycast, een techniek waarmee we dezelfde dienst, in ons geval een .nl-nameserver, op meerdere plekken ter wereld via hetzelfde IP-adres beschikbaar maken. Dat betekent dat we zowel in Amsterdam, als in New York (en op een hoop andere plekken) een .nl-nameserver hebben draaien die allemaal benaderbaar zijn op het IP-adres “194.0.28.53”.
Op het internet worden datapakketjes van router naar router getransporteerd tot ze op hun eindbestemming zijn. Routers weten ongeveer welke route de pakketjes moeten nemen om zo snel mogelijk op het bestemmings-IP-adres te komen. Met IP-anycast voegen we simpelweg meer bestemmingspunten toe aan het internet, waardoor gebruikers naar de voor hun snelste bestemming gerouteerd worden. Dat ziet eruit als in figuur 1.
Figuur 1: .nl-nameservers wereldwijd uitgerold met IP-anycast.
Het voordeel van IP-anycast is drieledig. Ten eerste kan een serverlocatie probleemloos uitvallen, omdat gebruikers dan ongemerkt naar een andere (werkende) bestemming worden gerouteerd. Ten tweede levert het een voordeel op in de snelheid van de dienst: gebruikers in Australië hoeven niet meer gerouteerd te worden naar een server in Nederland, maar komen uit in Sydney, wat een enorme snelheidswinst oplevert, tot wel zo’n 30x sneller. Tot slot is IP-anycast beter bestand tegen DDoS-aanvallen. Malafide verkeer van over de hele wereld wordt verspreid over de verschillende servers; dit maakt de kans dat één enkele server wordt overbelast een heel stuk kleiner.
Daarnaast doen we het niet alleen. Naast het bereikbaar maken van .nl op onze eigen anycastinfrastructuur draaien ook onze collega-registry’s CIRA (beheerder van het Canadese .ca-domein) en NIC.AT (van het Oostenrijkse .at-domein) beiden een kopie van de .nl-nameservers. Wij sturen ze elk half uur een update van de .nl-zonefile die zij, net als wij, publiceren op nameservers in hun beheer. Daardoor blijft .nl bereikbaar als wij, of één van hen, een grote fout maakt met betrekking tot de nameservers waardoor een deel onbereikbaar wordt; of als er een doelwit wordt van een cyberaanval. Zoals zij ons helpen met deze taak helpen wij onze Deense collega’s door het hosten van de .dk-zonefile op servers in ons beheer.
Samen met onze Canadese en Oostenrijkse collega’s zorgen we ervoor dat .nl altijd, overal en snel beschikbaar is op meer dan 80 servers verspreid over de hele wereld.
Er zijn diverse manieren om te zorgen dat de .nl-nameservers zowel snel als weerbaar zijn tegen aanvallen via het internet. Om op de ergste scenario's voorbereid te zijn moeten we flink overdimensioneren in capaciteit.
Om voorbereid te zijn op cyberdreigingen zetten we in op maximale schaalbaarheid en flexibiliteit van onze nameserverinfrastructuur. Verder maken we zoals gezegd gebruik van anycast om deze wereldwijd met lage responstijden te kunnen aanbieden en te voorkomen dat individuele servers te veel internetverkeer voor de kiezen krijgen. Met deze opzet kunnen we zowel regionaal als globaal snel in capaciteit opschalen als dat nodig is. Omdat we gebruik maken van gehuurde hardware kunnen we zowel in de breedte schalen (meer servers per locatie) als in de hoogte (zwaardere servers). En dat wereldwijd! Onder normale omstandigheden is de capaciteit van de nameservers al flink overgedimensioneerd om pieken in aantal DNS-query’s te kunnen opvangen, maar met deze methodiek kunnen we de capaciteit nog eens fors vergroten als dat nodig is.
Om dit alles mogelijk te maken rollen we onze nameservers geautomatiseerd uit op basis van Flatcar Linux. Dit is een Linuxdistributie die is teruggebracht tot het absolute minimum en alleen is bedoeld voor het draaien van processen in containers. De configuratie van de server kun je vooraf vastleggen en na het uitrollen is niets meer aan de configuratie van een draaiende nameserver te veranderen. Dit principe heet “immutable infrastructure”, wat de veiligheid en stabiliteit van de servers verhoogt.
We bouwen en testen alle onderdelen van het platform wekelijks automatisch opnieuw met CI/CD pipelines. In deze fase scannen we ook voor kwetsbaarheden, zowel in code die we zelf geschreven hebben als code uit externe bronnen. We testen ook automatisch of alle containers naar behoren functioneren. Dit zorgt ervoor zodat eventuele fouten vroegtijdig worden gevonden, nog voordat ze problemen kunnen veroorzaken in productie. Zo houden we de serverconfiguratie strak in de hand en kunnen we terug naar een vorige versie als blijkt dat er problemen optreden.
Doordat we het proces van bouwen, testen en uitrollen van nameservers op deze manier hebben geautomatiseerd hebben we er weinig omkijken naar. Dat is niet alleen prettig om snel te kunnen opschakelen als er meer capaciteit nodig is, maar ook om snel verbeteringen en nieuwe functionaliteit gecontroleerd in productie te kunnen brengen. Prototypes kunnen snel worden opgebouwd en weer worden afgebroken. Hierdoor kunnen we veel aandacht besteden aan het continu verbeteren van ons anycastplatform op basis van inzichten die we uit meetdata verkrijgen.
Enkele jaren geleden ontwikkelden we ENTRADA, een tool waarmee we DNS-query-informatie van .nl-nameservers verwerken en opslaan ten behoeve van onderzoeken. ENTRADA heeft ondertussen een enorme DNS-dataset met heel veel informatie opgeleverd waarmee we de werking van de .nl-nameservers goed in kaart kunnen brengen. Zo kunnen we bijvoorbeeld visualiseren hoeveel DNS-query’s elke .nl-nameserverlocatie verwerkt, en hoelang DNS-query’s van over de hele wereld er over doen om beantwoord te worden.
In een samenwerkingsproject tussen SIDN Labs en het DNS-team van SIDN hebben we veel tijd gestoken in het zichtbaar maken van deze metrics voor monitoringdoeleinden. Daarnaast lenen de resulterende grafieken zich goed voor een blog als deze, waarin we onze DNS-infrastructuur uitlichten.
Hieronder tonen we wat grafieken die we ook in onze dagelijkse werkzaamheden raadplegen. Figuur 2 laat het aantal query’s zien dat op de verschillende .nl-nameservers in ons beheer uitkomt.
Figuur 2: Aantal DNS-query's per minuut, per nameserverlocatie.
In de grafiek zien we dat het aantal query’s dat op bepaalde nameservers uitkomt nogal schommelt, terwijl andere serverlocaties een vrij stabiel aantal query’s ontvangen. Ook is hier goed te zien hoe Nederland wakker wordt: DNS-verkeer dat op de server in Amsterdam uitkomt (de groene lijn) neemt naar mate het dag wordt flink toe.
In figuur 3 zoomen we in op de statistieken van een specifieke .nl-nameserver in New York. We kunnen zien van waar op de wereld het verkeer dat op die locatie uitkomt vandaan komt, ook wel de catchment van deze server genoemd. Daarnaast plotten we een aantal statistieken over de latency van query’s naar die server (hoe snel je antwoord krijgt), en het aantal query’s over de tijd heen. Deze grafieken herhalen we voor elke .nl-nameserver in ons beheer, zodat we van elke server kunnen zien hoe deze ervoor staat.
Figuur 3: Ingezoomd op de nameserver in New York; catchment, latency en aantallen query’s.
Tot slot laten we in figuur 4 statistieken zien over query’s die uit een bepaalde regio komen, in dit geval uit Zuid-Amerika. Dit geeft dus een beeld vanuit het oogpunt van de resolvers uit een bepaalde regio, in plaats van vanaf onze nameservers gezien. Op het kaartje tonen we voor elk land in die regio de hoeveelheid query’s (de grootte van het bolletje) en de gemiddelde latency (kleur). Ook in deze weergave tonen we de latency-statistieken en query-aantallen. Deze grafieken herhalen we voor alle continenten en nog een aantal specifiekere regio’s waarin we geïnteresseerd zijn.
Figuur 4: Hoeveelheid en snelheid van DNS-query's uit landen in Zuid-Amerika.
Met de inzichten uit deze visualisaties kunnen we beter beslissingen nemen over het af- of opschalen van onze infrastructuur en kunnen we zien of er iets misgaat, bijvoorbeeld als de latency op een bepaalde plek omhoogschiet.
Naast het visualiseren van passieve meetdata, die we tijdens het normaal functioneren van de dienst automatisch verkrijgen, doen we zelf ook actieve metingen aan het internet. We sturen dan zélf internetpakketjes naar heel veel bestemmingen op het internet om op die manier vanuit onszelf gezien te meten hoe pakketjes gerouteerd worden en hoe lang ze er over doen om bij hun bestemming te komen. Met die actieve meetdata kunnen we onder andere op een slimme, data gedreven manier bepalen op welke locaties we een .nl-nameserver moeten uitrollen om globaal zo snel mogelijk antwoord te kunnen geven op DNS-query’s. Met zo’n optimalisatiealgoritme zijn we hard bezig en daarover schrijven we meer in een toekomstige blogpost.
Artikel door:
Deel dit artikel