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

Google zet Case Randomization-beveiligingstechologie aan op al zijn Public DNS resolvers

DNSSEC blijft ultieme bescherming tegen 'cache poisoning'-aanvallen

Digitaal hangslot op blauwgekleurd moederbord
  • vrijdag 29 september 2023

Hoewel DNS nog steeds een veilig protocol is, zijn er de afgelopen jaren toch weer nieuwe 'cache poisoning'-aanvallen ontwikkeld. De beste beveiligingsmethode tegen DNS Spoofing is natuurlijk DNSSEC. Maar waar deze beveiligingstechnologie nog niet (volledig) toegepast wordt, is de integriteit van het DNS-verkeer vooral afhankelijk van Source Port Randomization. Daarbij gebruikt de resolver steeds een andere uitgaande UDP-poort voor zijn query’s, wat het voor een aanvaller veel moeilijker ("statistisch onmogelijk") maakt om op een DNS-uitwisseling in te breken.

Vanaf deze zomer past Google Public DNS (8.8.8.8) ook Case Randomization toe op al zijn resolvers. Dat is een aanvullende techniek die nog meer "geheime informatie" toevoegt aan het DNS-verkeer (in dit geval tussen Google's recursieve resolvers en autoritatieve servers) [1, 2].

Source Port Randomization

Source Port Randomization (beschreven in RFC 5452) was destijds het antwoord op de traditionele 'cache poisoning'-aanval. Bij een dergelijke aanval probeert een kwaadwillende valse DNS-informatie in een caching resolver te injecteren door grote hoeveelheden valse antwoorden op die resolver af te vuren. Daarbij maakt hij gebruik van het feit dat binnen DNS-berichten maar 65.536 verschillende Transaction ID's beschikbaar zijn. Deze 16-bits nummers worden door de client (de resolver) en de DNS-server gebruikt om vragen en antwoorden aan elkaar te koppelen. Door de Transaction ID te variëren, was het een kwestie van tijd voordat het valse antwoord met het juiste ID bij de resolver arriveerde net wanneer deze de "bijbehorende" vraag had uitstaan.

Een provisorische oplossing voor dit probleem werd gevonden door de UDP-poort van de resolver steeds te laten variëren. Omdat de aanvaller nu niet meer weet vanaf welke poort een uitgaande vraag afkomstig zal zijn, moet hij nog eens 65 duizendmaal zoveel valse DNS-antwoorden sturen om ook alle mogelijke poorten van de client te bestoken. Daarmee was deze aanval niet langer haalbaar.

Kaminsky-aanvallen en DNSSEC

In 2008 wist Dan Kaminsky de 'cache poisoning'-aanval echter enorm te versnellen door deze te combineren met het slim bevragen van de betreffende resolver. We beschrijven de Kaminsky-aanval uitgebreider in de DNSSEC FAQ; een uitgewerkt voorbeeld vind je hier.

Met de aanpak van Kaminsky werd de 'cache poisoning'-aanval die voorheen vooral theoretisch van aard was ook praktisch haalbaar, waarmee het gebruik van Source Port Randomization absoluut noodzakelijk werd.

Een structurele oplossing voor dit type aanvallen ligt natuurlijk in het gebruik van DNSSEC-validatie. Een validerende resolver zal de valse informatie immers nooit accepteren als deze niet van de juiste digitale handtekening is voorzien.

SAD DNS

Het belang van DNSSEC werd nog eens extra duidelijk met de publicatie van de moderne 'SAD DNS'- en 'SAD DNS 2.0'-aanvallen in respectievelijk 2020 en 2021. Deze aanvallen doen de bescherming van Source Port Randomization teniet door verschillende side-channels te gebruiken om de (momentane) uitgaande UDP-poort van de resolver te achterhalen. Ook deze 2 aanvallen beschrijven we uitgebreider in de DNSSEC FAQ [SAD DNS, SAD DNS 2.0].

De onderzoekers zetten een aantal maatregelen tegen deze nieuwe 'SAD DNS'-aanvallen op een rij, maar noemen (net als Google) DNSSEC als primaire verdediging tegen 'cache poisoning'-aanvallen.

CAse RAndoMizaTioN

Case Randomization of 0x20 Bit Encoding [1] borduurt conceptueel voort op de 'Source Port Randomization'-beschermingsmethode. De techniek dateert uit dezelfde periode, al is dit bij gebrek aan belangstelling destijds nooit een echte RFC geworden (zowel Google als de auteur Paul Vixie suggereren nu om deze Draft nieuw leven in te blazen).

Door in de domeinnaam op willekeurige manier hoofdletters en kleine letters te gebruiken, wordt meer geheime informatie (entropie) in de DNS-uitwisseling ingebracht. Een resolver die het adres van de hostnaam "www.example.nl" wil weten, gebruikt bijvoorbeeld deze naam in zijn query: "wWw.EXamPLE.nL". De autoritatieve nameserver zal in zijn antwoord dezelfde variatie gebruiken, waardoor de client "nog zekerder weet" dat het betreffende antwoord inderdaad van de geadresseerde autoritatieve nameserver afkomstig is. Naast de Transaction ID en de source port moet een aanvaller nu immers ook de spelling van de naam goed hebben om zijn vervalste antwoord door de aangevallen resolver te laten accepteren.

Merk op dat QNAME Minimization (een belangrijk privacyverhogend mechanisme) [1, 2, 3] de winst beperkt die initieel met Case Randomization te behalen is.

Daarnaast is er nog een gerelateerd maar aanzienlijk ingewikkelder mechanisme om DNS-uitwisselingen te beschermen: DNS Cookies, gedefinieerd in RFC 7872.

Support

Ondersteuning van Case Randomization aan de zijde van de nameservers was er altijd al: deze werden impliciet geacht de naam uit de query exact over te nemen in hun antwoord [IETF 72, BIND]. Hoewel dat nog niet altijd goed gaat (reden voor 1.1.1.1/Cloudflare om Case Randomization begin 2019 opt-in te maken), kun je er vanuit gaan dat de toepassing van Case Randomization door een marktbepalende partij als Google hier snel verandering in brengt.

Ondersteuning aan resolverzijde (dat wil zeggen: de mogelijkheid om aangepaste domeinnamen uit te sturen en de gebruikte naam bij binnenkomende berichten te controleren, al dan niet middels een optie) wisselt per softwarepakket [e.g Unbound, Knot en F5 wel, BIND niet].