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

Nieuwe SAD DNS 'cache poisoning'-aanval op Domain Name System gepubliceerd

Linux en veelgebruikte DNS-software kwetsbaar

Vorm van een schedel in een blauwe digitale omgeving
  • maandag 13 december 2021

Precies een jaar na de publicatie van de eerste 'SAD DNS'-aanval op het Domain Name System (DNS) komt dezelfde onderzoeksgroep met een nieuwe 'cache poisoning'-aanval. Deze methode werkt conceptueel hetzelfde als de vorige: de onderzoekers hebben een nieuw side channel ontdekt om efficiënt valse DNS-informatie in een caching resolver te injecteren. Vandaar dat deze aanvalsmethode nu de naam SAD DNS 2.0 heeft meegekregen. Volgens de onderzoekers zijn vooral Linux-systemen kwetsbaar voor deze aanval, net als veelgebruikte DNS-software als BIND, Unbound en dnsmasq (allemaal op Linux). Van de grote publieke DNS-diensten bleek de helft kwetsbaar, waaronder OpenDNS (van Cisco) and Quad9 (9.9.9.9). Hoewel de onderzoekers een aantal maatregelen tegen deze nieuwe 'SAD DNS'-variant op een rij zetten, noemen ze DNSSEC als primaire verdediging tegen 'cache poisoning'-aanvallen. Maar dan moeten we deze beveiligingstechnologie wel met zijn allen gaan gebruiken.

DNS cache poisoning

Net als de eerste 'SAD DNS'-aanval bouwt ook SAD DNS 2.0 voort op de Kaminksy-aanval, in 2008 gepubliceerd door de (onlangs overleden) veiligheidsonderzoeker Dan Kaminksy. Bij een dergelijke aanval worden op slimme manier zowel DNS-queries als gespoofde valse DNS-antwoorden naar een caching resolver gestuurd, met als doel om die valse DNS-informatie in de betreffende resolver te injecteren. Een dergelijke 'DNS cache poisoning'-aanval wordt tegengegaan door middel van Source Port Randomization (gedefinieerd in RFC 5452). Daarbij laat men de uitgaande UDP-poort van de resolver variëren voor elke query, wat het spoofen van valse DNS-antwoorden praktisch onmogelijk maakt.

'Side channel'-aanvallen

De eerste 'SAD DNS'-aanval deed de bescherming van de Source Port Randomization teniet door de momentane (ephemeral) uitgaande UDP-poort te achterhalen. De truc daarbij was om het aantal ICMP-berichten in reactie op gespoofde DNS-responses (indirect) te tellen. Was de uitgaande UDP-poort bekend, dan kon een Kaminsky-achtige aanval ingezet worden. We beschrijven deze aanvalsmethode hier in meer detail. Ook de nieuwe 'SAD DNS'-aanval draait om het achterhalen van de momentane uitgaande UDP-poort van de resolver, maar doet dat via andere side channels (vandaar de naam 'Side channel AttackeD DNS' voor dit type aanvallen). Bij deze laatste variant hebben de onderzoekers verschillende 'side channel'-aanvallen ontwikkeld op basis van 'ICMP frag needed'- en 'ICMP redirect'-berichten. Deze 'ephemeral port scanning'-methode stuurt een serie gespoofde ICMP-berichten op de resolver af en checkt vervolgens of daarbij de ephemeral poort geraakt is. Op Linux leidt een geldig ICMP-bericht tot een aanpassing in de zogenaamde 'next hop exception cache' (onderdeel van de netwerk-stack). En of dat laatste inderdaad heeft plaatsgevonden, kun je bijvoorbeeld weer controleren door een eenvoudig ping-bericht naar de betreffende resolver te sturen. Is de momentane uitgaande UDP-poort achterhaald, dan wordt weer een Kaminsky-achtige aanval ingezet om de DNS transaction ID's te brute-forcen. Daarbij kunnen ook aanvullende technieken worden ingezet om het verzenden en de goede aankomst van het correcte antwoord afkomstig van de echte autoritatieve name server te frustreren, om zo het window voor valse DNS-antwoorden te vergroten. Deze trucs waren al beschreven bij de publicatie van de eerste 'SAD DNS'-aanval.

DNSSEC als structurele oplossing

Uit tests met deze ICMP/UDP-gebaseerde 'side channel'-aanvallen blijkt dat kwetsbare resolvers al binnen een paar minuten van valse DNS-informatie kunnen worden voorzien. Verdere analyse leert dat FreeBSD (en daarmee ook MacOS) niet kwetsbaar is – interessant genoeg omdat de netwerk-stack volgens de onderzoekers niet helemaal volgens de RFC-standaard werkt. Recente Windows-versies blijken gedeeltelijk kwetsbaar. "SAD DNS 2.0 legt opnieuw een zwakte in het DNS bloot die alleen goed op te lossen is met DNSSEC," zegt Berry van Halderen, lead developer bij NLnet Labs. "Het gaat niet om een onvolkomenheid in de software, maar om een zwakte in het DNS-protocol die misbruikt kan worden als DNSSEC niet wordt toegepast." De onderzoekers zetten een aantal maatregelen tegen deze nieuwe 'SAD DNS'-variant op een rij, maar noemen DNSSEC als primaire verdediging tegen 'cache poisoning'-aanvallen. Een niet-beveiligde resolver zal de valse informatie immers aannemen 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 zal die valse informatie echter nooit accepteren als deze niet van de juiste digitale handtekening is voorzien.