Chose your color

Frequently visited

Frequently asked questions

  • I am looking for a domain name registrant. Where can I look it up?

    The Whois is an easy-to-use tool for checking the availability of a .nl domain name. If the domain name is already taken, you can see who has registered it.

    On the page looking up a domain name you will find more information about what a domain name is, how the Whois works and how the privacy of personal data is protected. Alternatively, you can go straight to look for a domain name via the Whois.

  • I would like to transfer my domain name to another registrar. What is the procedure?

    To get your domain name transferred, you need the token (unique ID number) for your domain name. Your existing registrar has the token and is obliged to give it to you within five days, if you ask for it. The procedure for changing your registrar is described on the page transferring your domain name.

  • The details registered about me/my company are incorrect or out of date. How can I get them updated?

    To update the contact details associated with your domain name, you need to contact your registrar. Read more about updating contact details.

  • Why is my domain name in quarantine?

    When a domain name is cancelled, we aren't told the reason, so we can't tell you. You'll need to ask your registrar. The advantage of quarantine is that, if a name's cancelled by mistake, you can always get it back.

    One common reason is that the contract between you and your registrar says you've got to renew the registration every year. If you haven't set up automatic renewal and you don't renew manually, the registration will expire.

  • 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.

  • What conditions do I have to meet as a registrar?

    Would you like to be able to register domain names for customers or for your own organisation by dealing directly with SIDN? If so, you can become a .nl registrar. Read more about the conditions and how to apply for registrar status on the page becoming a registrar.

More frequently asked questions

SAD DNS: new DNS cache poisoning technique emerges

DNSSEC remains the structural solution for vulnerabilities of this kind

Skull shape in a red digital environment
  • Wednesday 18 November 2020

Last week saw the return of the DNS cache poisoning attack for which Dan Kaminsky found an effective exploit back in 2008. The SAD DNS attack uses a new side-channel to inject fake DNS information into a caching resolver. Hence the name – Side-channel AttackeD DNS. According to the discoverers, a third of all caching resolvers are vulnerable to the attack, as are the majority of major public DNS services.

What should you do?

Operators of caching resolvers need to patch/update their systems: the discoverers of SAD DNS have made a Linux patch available, which is also included in the kernel from version 5.10. If patching isn't (yet) possible, (temporary) blocking of outbound ICMP messages will protect relevant systems pending a more permanent solution. End users who have their systems set up to use one of the big public DNS services (Google Public DNS (8.8.8.8), 1.1.1.1, Quad9 (9.9.9.9) or the like) as their resolver are advised to do nothing for the time being. Such services are likely to be provided with protection in the near future. You can check whether the resolver you use is vulnerable to SAD DNS by using a link on the saddns.net website [PowerDNS Recursor, 1.1.1.1].

DNS cache poisoning

The classic DNS cache poisoning attack and the Kaminksy attack are described in our DNSSEC FAQs. With SAD DNS, an attacker establishes what a DNS resolver's outbound UDP port is by taking advantage of the protective rate limiting functionality for ICMP messages built into all network stacks. If, for example, the limit is set at 1,000 messages per second (as with Linux), the attacker can test all 65,000 UDP ports in blocks of a thousand to find out which block includes the DNS resolver's outbound port. That involves first sending 1,000 fake DNS responses from spoofed IP addresses, one to each port in the block. The resulting ICMP error messages are lost because the sender's address is spoofed. However, if the attacker sends a 1,001st message from their real IP address within the same second and gets one final ICMP response, they know that the correct port is in that series of 1,000 ports. Otherwise the limit of 1,000 ICMP error messages would have been exceeded for the second in question. The second diagram in this article shows how the tactic works. By establishing what outbound UDP port the resolver is currently using, the attacker negates the original strategy for preventing classic DNS cache poisoning attacks and Kaminsky attacks, namely source port randomisation. Once the port is known, the attacker merely has to try each of the 65,000 different transaction IDs in order to inject fake DNS information (by means of a Kaminsky-style attack). In their publication, the researchers explain how they were able to extend the window for performing a complete attack from a few tens of milliseconds to many tens of seconds. Fortunately, the new problem is relatively easy to fix. The Linux patch introduces a substantial degree of randomness to the limit of 1,000 ICMP messages.

DNSSEC: a structural solution

A more structural solution is of course to use DNSSEC validation. A non-secured resolver will accept false information if it arrives at the right moment, on the right port, and accompanied by the right transaction ID from the right (spoofed) sender. However, a validating resolver would never accept the same false information if it didn't bear a valid digital signature.