Kies jouw kleur

Veel bezocht

Veelgestelde vragen

  • Ik zoek de houder van een domeinnaam. Waar vind ik die?

    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.

  • Ik wil mijn domeinnaam verhuizen. Hoe doe ik dat?

    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.

  • Ik wil mijn contact/adresgegevens aanpassen bij mijn .nl-domeinnaam. Hoe doe ik dat?

    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.

  • Waarom staat mijn domeinnaam in quarantaine?

    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.

  • Ik heb een klacht over mijn provider/registrar. Kan ik daarvoor bij SIDN terecht?

    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.

  • Waaraan moet ik voldoen als 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.

Meer veelgestelde vragen

DNS-kwetsbaarheid, configuratiefouten kunnen DDoS veroorzaken

De huidige RFC's dekken het probleem niet volledig

Cybersecurityconcept bestaande uit meerdere blauwe gesloten digitale hangsloten en 1 rood geopend hangslot

De oorspronkelijke blog is in het Engels. Dit is de Nederlandse vertaling.

Auteurs: Giovane C. M. Moura (1,2), Sebastian Castro (3), John Heidemann (4), Wes Hardaker (4) 1: SIDN Labs 2: TU Delft 3: IE Domain Registry 4: USC/ISI

Vorig jaar ontdekten we een DNS-kwetsbaarheid die, in combinatie met een configuratiefout, kan leiden tot enorme pieken in het DNS-verkeer. Sindsdien hebben we dit probleem zorgvuldig onderzocht, een responsible disclosure uitgevoerd, grote operators zoals Google en Cisco geholpen hun diensten te repareren en een Internet Draft voorgelegd aan de IETF DNS Working Group die het probleem moet verhelpen.

Het DNS is een van de kerndiensten van het internet. Elk bezoek aan een webpagina vergt meerdere DNS-query's en -antwoorden. Als het wordt verstoord, belandt het DNS op de voorpagina's van prominente nieuwssites.

Mijn collega's en ik van SIDN Labs, TU Delft, IE Domain Registry en USC/ISI stuitten onlangs op een DNS-kwetsbaarheid die kan worden misbruikt om verkeerspieken te veroorzaken op autoritatieve DNS-servers – de servers die de inhoud kennen van volledige DNS-zones zoals .org en .com. We kwamen dit voor het eerst tegen toen we het verkeer van de Nederlandse .nl-zone en van de autoritatieve servers van het Nieuw-Zeelandse .nz met elkaar vergeleken voor een onderzoek naar internetcentralisatie.

Toen we wat dieper groeven in wat we waarnamen, beseften we dat een bekend probleem eigenlijk veel ernstiger was dan verwacht. De kwetsbaarheid, die we de naam tsuNAME gaven, wordt veroorzaakt door lussen in DNS-zones – zogeheten cyclische afhankelijkheden – en door valse resolvers/clients/forwarders. In deze onderzoekspaper gaan we hier uitgebreid op in.

Belangrijk is dat de bestaande RFC's het probleem niet volledig oplossen. Ze voorkomen weliswaar dat resolvers in een lus terechtkomen, maar niet dat clients en forwarders een lus beginnen, wat er vervolgens voor zorgt dat de resolver de autoritatieve servers overspoelt.

Daarom hebben we een Internet Draft voorgelegd aan de IETF DNS Working Group waarin we beschrijven hoe het probleem kan worden opgelost en CycleHunter ontwikkeld, een tool die dit soort aanvallen kan voorkomen. Daarnaast hebben we een responsible disclosure uitgevoerd, waarbij we samenwerkten met engineers van Google en Cisco die het probleem op hun openbare DNS-servers hebben verholpen.

Hieronder volgt een korte samenvatting van tsuNAME en ons onderzoek tot nu toe.

Wat veroorzaakt de kwetsbaarheid tsuNAME?

Om deze kwetsbaarheid te laten ontstaan, moeten er eerst 2 DNS-records onjuist geconfigureerd worden zodat er een lus ontstaat, bijvoorbeeld zo:

#.com zone
example.com NS cat.example.nl

#.nl zone:
example.nl NS dog.example.com

In dit voorbeeld wordt een DNS-resolver die example.com probeert om te zetten, doorgestuurd naar de autoritatieve .nl-servers om example.nl om te zetten. Daar verneemt de resolver dat dog.example.com de autoritatieve server voor example.nl is. Dat veroorzaakt een lus, waardoor geen enkel domein onder example.com of example.nl kan worden omgezet. Waarom is dat eigenlijk een probleem? Welnu, als een gebruiker de naam opvraagt, volgen hun resolvers de lus, waardoor er amplificatie optreedt en één query meerdere nieuwe query's genereert. Sommige onderdelen van de DNS-resolverinfrastructuur – die bestaat uit clients, resolvers, forwarders en stubs – kunnen zo'n scenario niet echt aan. Dat kan leiden tot een situatie zoals in Figuur 1, dat een voorbeeld laat zien van 2 domeinen in de .nz-zone die eerst nauwelijks verkeer hadden en opeens elk meer dan 100 miljoen query's per dag begonnen te ontvangen.

Dagelijkse zoekopdrachten naar twee domeinen onder de .nz-zone die getroffen zijn door een tsuNAME-incident.

Figuur 1: .nz-incident.

In dat voorbeeld wisten de operators van .nz de lus in hun zone te doorbreken en werd het probleem verholpen. Dat neemt niet weg dat tot die tijd het totale .nz-verkeer met maar liefst 50% toenam (Figuur 2), alleen maar door 2 valse domeinnamen.

Dagelijkse verzoeken aan al het .nz-verkeer tijdens een tsuNAMI-event.

Figuur 2: Dagelijkse query's naar .nz.

Maar wat gebeurt er als een aanvaller veel meer domeinnamen bezit en die met opzet configureert met dit soort lussen? Of als een aanvaller veel verzoeken verstuurt? In zo'n situatie kan er bij meerdere query's amplificatie optreden, misschien wel genoeg om de autoritatieve servers te overweldigen. Dat betekent een nieuwe amplificatiedreiging.

Waar komt die verkeerspiek vandaan?

We vonden 3 onderliggende oorzaken van tsuNAME-pieken:

  1. Oude resolvers (zoals DNS-servers met MS Windows 2008) die in een oneindige lus terechtkomen;

  2. Clients/forwarders die in een oneindige lus terechtkomen – omdat ze niet tevreden zijn met de SERVFAIL-antwoorden die door resolvers worden geretourneerd (Figuur 3);

  3. Een combinatie van beide.

Hoofdoorzaken van tsuNAME-events.

Figuur 3: Onderliggende oorzaken van tsuNAME.

Dit lijkt misschien allemaal nogal voor de hand liggend. Maar, zoals eerder vermeld, is het op IETF-niveau nooit overwogen, zoals de volgende relevante RFC's laten zien:

  • RFC 1034 stelt: “resolvers moeten de hoeveelheid werk begrenzen 'om oneindige lussen te vermijden'";

  • RFC 1035 (§7.2) stelt dat resolvers “per verzoek een teller moeten bijhouden om een limiet te stellen aan het werk voor een enkel verzoek”;

  • RFC 1536 stelt dat lussen kunnen optreden, maar biedt geen nieuwe oplossing.

Zoals je ziet, voorkomen de bestaande RFC's dat alleen resolvers in een lus terechtkomen. Maar wat als de lus ergens anders optreedt?

Stel dat een client in een lus verzeild raakt en na SERVFAIL-antwoorden van de resolver elke seconde nieuwe query's naar de resolver stuurt (Figuur 3). Als de bestaande RFC's worden gevolgd, zou elke nieuwe query een nieuwe reeks query's van de resolvers naar de autoritatieve servers genereren, ook als er limieten zijn ingesteld.

Dat is wat de openbare DNS van Google overkwam in februari 2020. In ons eerdere onderzoek naar internetcentralisatie kwamen we erachter dat Google Public DNS veel meer A/AAAA-query's naar .nz stuurde dan naar .nl. Google volgde de RFC's en toch zorgden lussende clients ervoor dat GDNS grote hoeveelheden query's naar de autoritatieve .nz-servers stuurde.

Zo lossen we het tsuNAME-probleem op

De manier om tsuNAME tegen te gaan, hangt af van je locatie binnen de infrastructuur.

Als je resolvers beheert, is het probleem eenvoudig op te lossen: resolvers moeten lussende records opslaan in de cache, zodat alle nieuwe query's van clients/forwarders en stubs rechtstreeks vanuit de cache kunnen worden beantwoord en de autoritatieve servers worden beschermd. Dat is wat we in deze IETF-draft voorstellen en hoe Google Public DNS het probleem heeft verholpen.

Als je autoritatieve servers beheert, moet je ervoor zorgen dat er in je zonebestanden geen onjuiste configuraties voorkomen. Om daarbij te helpen, hebben we CycleHunter ontwikkeld, een opensourcetool waarmee dit soort lussen in DNS-zones kunnen worden gedetecteerd. We raden operators aan om hun zones regelmatig op lussen te controleren.

Responsible disclosure

We slaagden erin om tsuNAME in verschillende scenario's en vanuit verschillende vantage points – waaronder RIPE Atlas en een sinkhole – te reproduceren. Hier kun je in onze paper meer over lezen. We vonden meer dan 3.600 resolvers in 2.600 autonome systemen die kwetsbaar waren voor tsuNAME.

Daarop besloten we om een responsible disclosure uit te voeren om operators te waarschuwen. Begin 2021 brachten we Google, Cisco en een aantal andere partijen op de hoogte en op 6 mei maakten we de kwetsbaarheid openbaar – nadat we de betreffende partijen voldoende tijd hadden gegeven om hun bugs te repareren, wat hen ook gelukt is.

Na de onthulling werden we benaderd door verschillende TLD-operators die vertelden dat ze in het verleden het slachtoffer waren geweest van tsuNAME-gerelateerde incidenten. Een van hen was zo vriendelijk om een tijdreeks van het verkeer te delen (Figuur 4). De partij in kwestie is een in de EU gevestigde ccTLD-operator, die tijdens een tsuNAME-incident 10 keer zoveel verkeer waarnam:

Het verkeer tijdens een tsuNAME-event bij een in de EU gevestigde ccTLD-operator.

Figuur 4: tsuNAME-incident bij ccTLD-operator in EU.

De verschillende kleuren vertegenwoordigen elk een andere autoritatieve server. Het incident begint rond 19:00 UTC en eindigt de volgende dag om 11:00 UTC, toen de cyclische afhankelijkheden uit de zone werden verwijderd.

Vervolg

We hebben aangetoond dat lussen in DNS-zones nog steeds een probleem vormen, ondanks het feit dat hun bestaan al lang bekend is. Het is een probleem dat door de bestaande RFC's niet grondig genoeg wordt aangepakt. Ook hebben we gedetailleerd onderzoek gedaan naar tsuNAME, een type incident dat door veel operators is waargenomen, maar niet bekend is bij het publiek. We hebben laten zien hoe deze kwetsbaarheid als wapen kan worden gebruikt en wat de onderliggende oorzaken ervan zijn. We zijn bezig met een herziene versie van onze Internet Draft, waarin we de feedback van de community verwerken. Ongeacht wat er met de Internet Draft gebeurt, zijn we blij dat we Google en Cisco hebben kunnen helpen hun openbare DNS-servers tegen de kwetsbaarheid te beschermen en daarmee een kleine bijdrage hebben geleverd aan de veiligheid van het internet.

Meer informatie

Artikel door:

Giovane Moura

Giovane Moura

Data Scientist