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

SAD DNS: nieuwe 'DNS cache poisoning'-aanval ontdekt

DNSSEC als structurele oplossing tegen dit soort kwetsbaarheden

Vorm van een schedel in een rode digitale omgeving
  • woensdag 18 november 2020

De 'DNS cache poisoning'-aanval waarvoor Dan Kaminsky in 2008 een goed werkende exploit vond, is sinds vorige week weer helemaal terug van weggeweest. De 'SAD DNS'-aanval maakt gebruik van een nieuw side-channel om valse DNS-informatie in een caching resolver te injecteren – vandaar ook de naam 'Side channel AttackeD DNS'. Volgens de ontdekkers is een derde van alle caching resolvers kwetsbaar voor deze aanval, net als de meerderheid van de grote publieke DNS-diensten.

Wat te doen?

Beheerders van caching resolvers moeten hun systemen patchen/updaten: de ontdekkers van SAD DNS hebben een patch voor Linux beschikbaar gemaakt, die vanaf versie 5.10 ook in de kernel is opgenomen. Lukt dat patchen op dit moment (nog) niet, dan is het (tijdelijk) blokkeren van uitgaande ICMP-berichten op de betreffende systemen een ‘oplossing voor nu’. Eindgebruikers die een van de grote publieke DNS-diensten (Google Public DNS (8.8.8.8), 1.1.1.1, Quad9 (9.9.9.9) en dergelijke) als resolver ingesteld hebben, kunnen het beste even afwachten. Deze diensten worden zeer waarschijnlijk op korte termijn gerepareerd. Of de resolver die jij gebruikt kwetsbaar is voor SAD DNS, kun je checken via een link op de website saddns.net [PowerDNS Recursor, 1.1.1.1].

DNS cache poisoning

We beschrijven de klassieke 'DNS cache poisoning'-aanval en de Kaminksy-aanval in onze DNSSEC FAQ. SAD DNS maakt misbruik van de 'Rate Limiting'-bescherming voor ICMP-berichten – ingebouwd in alle netwerk-stacks – om de uitgaande UDP-poort van de DNS resolver te achterhalen. Staat die limiet bijvoorbeeld ingesteld op maximaal 1.000 berichten per seconde (zoals bij Linux), dan kan een aanvaller alle 65 duizend UDP-poorten in blokken van duizend stuks testen om te zien in welk blok precies de uitgaande poort van de DNS resolver zich bevindt. Daartoe stuurt hij eerst 1.000 valse DNS-responses vanaf gespoofde IP-adressen naar alle poorten in het betreffende blok. De ICMP-foutmeldingen gaan verloren (vanwege de spoofing van het afzenderadres). Maar als de aanvaller binnen diezelfde ene seconde vervolgens nog een 1.001-ste bericht stuurt vanaf zijn echte IP-adres en daarop toch nog een laatste ICMP-response terugkrijgt, dan weet hij dat de juiste poort binnen die reeks van 1.000 poorten ligt. Anders was die limiet van 1.000 ICMP-foutmeldingen binnen die seconde immers al bereikt geweest. De tweede figuur in dit bericht laat goed zien hoe deze methode werkt. Met het achterhalen van de (momentane) uitgaande UDP-poort van de resolver wordt de Source Port Randomization (de originele oplossing tegen de klassieke 'DNS cache poisoning'-aanval en de Kaminsky-aanval) teniet gedaan. Is deze poort bekend, dan blijven immers alleen de 65 duizend verschillende transaction ID's over om te proberen bij het injecteren van valse DNS-informatie (middels een Kaminsky-achtige aanval). In hun publicatie beschrijven de onderzoekers hoe ze het window waarin een complete aanval moet worden uitgevoerd weten te verlengen van enige tientallen milliseconden tot vele tientallen seconden. Gelukkig is dit nieuwe probleem relatief makkelijk op te lossen. In de patch voor Linux kun je zien hoe er nu een flinke dosis randomness aan die limiet van 1.000 ICMP-berichten is toegevoegd.

DNSSEC: een structurele oplossing

Een meer structurele oplossing zit natuurlijk in het gebruik van DNSSEC-validatie. Een niet-beveiligde resolver neemt de valse informatie immers aan als deze op het juiste moment, op de juiste poort, voorzien van de juiste transaction ID, door de juiste (gespoofde) afzender wordt aangeboden. Een validerende resolver accepteert die valse informatie echter nooit, als deze niet van de juiste digitale handtekening is voorzien.