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

Google enables case randomisation security on all its public DNS resolvers

DNSSEC remains the best protection against cache poisoning attacks

Digital padlock on blue colored motherboard
  • Friday 29 September 2023

Although the DNS remains a secure protocol, a series of new cache poisoning attack methods have been developed in recent years. The best protection against DNS spoofing is, of course, DNSSEC. However, in situations where DNSSEC isn't (fully) deployed, the integrity of DNS traffic depends largely on source port randomisation. That involves the resolver sending each query via a different, randomly selected UDP port, making it much harder ('statistically impossible') for an attacker to successfully to hack into a DNS message exchange.

Since summer of this year, Google Public DNS (8.8.8.8) has also enabled case randomisation on all its resolvers. Case randomisation is a supplementary technology that adds further 'secret information' to the DNS traffic flow (in this case, the traffic between Google's recursive resolvers and authoritative servers) [1, 2].

Source port randomisation

Source port randomisation (defined in RFC 5452) was conceived as the answer to the traditional cache poisoning attack, where an attacker tries to inject a caching resolver with false DNS information by bombarding it with false responses. That tactic exploits the fact that only 65,536 unique transaction IDs are available for the identification of DNS messages. The client (resolver) and the DNS server use those 16-bit numbers to associate queries and responses. If a resolver is swamped with false responses with different transaction IDs, it is only a matter of time before one of them happens to have the same ID as a query that the resolver has just sent.

Constantly changing the resolver's UDP port provided an interim solution to the problem. Because an attacker does not know which port an outbound query has come from, 65,000 times as many false DNS responses have to be sent in order to infect all possible ports. Randomisation therefore makes a traditional attack practically impossible.

Kaminsky attacks and DNSSEC

Nevertheless, in 2008, Dan Kaminsky showed that the process of cache poisoning could be greatly accelerated by combining it with a smart approach to querying the resolver. For details of how a 'Kaminsky attack' works, see our DNSSEC FAQ and the illustration provided here.

Kaminsky’s approach made 'cache poisoning' -- previously little more than a theoretical possibility -- a viable attack strategy. Hence, the use of source port randomisation became a necessity.

A more structural answer to this kind of attack is of course to use DNSSEC validation. The reason being that a validating resolver will never accept the false information if it doesn't bear a valid digital signature.

SAD DNS

The importance of DNSSEC was underscored by the publication of two modern attack strategies, SAD DNS and SAD DNS 2.0 in 2020 and 2021. These strategies negate the protection afforded by source port randomisation by using various side channels to identify the outbound UDP port being used by the resolver at a particular moment in time. Again, details are provided in our DNSSEC FAQ [SAD DNS, SAD DNS 2.0].

While pointing out that the new SAD DNS attacks could be countered in various ways, the team that published the methods stressed that DNSSEC was the best defence against cache poisoning, echoing Google's earlier advice.

CAse RAndoMizaTioN

In conceptual terms, case randomisation, also known as 0x20 bit encoding [1], builds on the source port randomisation protection method. The technology dates from the same period, but was not initially formalised as an RFC due to lack of interest. However, Google and author Paul Vixie are now suggesting that the draft should be revisited.

If the letters making up a domain name are written as a random mix of upper and lower case, an additional element of unpredictability ('entropy') can be introduced to the DNS message exchange. So, for example, a resolver seeking the address of the host "www.example.nl" might send a query in which the host name is written as "wWw.EXamPLE.nL". When responding, the authoritative name server will then use the same combination of upper and lower-case letters. That enables the client to be more confident that the response has indeed come from the authoritative name server that was queried, because it is much less likely that an attacker will chance upon not only the correct transaction ID and source port number, but also the correct combination of upper and lower-case letters.

It should be noted, however, that QNAME minimisation (an important privacy enhancement) [1, 2, 3] will limit the benefit attainable through case randomisation.

A final, considerably more complicated way of protecting DNS message exchanges is to use DNS cookies, as defined in RFC 7872.

Support

Server-side support for case randomisation has always been there, insofar as a name server has always been expected to compose a response in which the queried name is reproduced exactly as it is in the query [IETF 72, BIND]. Although that convention isn't always correctly followed (persuading 1.1.1.1/Cloudflare to make case randomisation an opt-in at the start of 2019), it's safe to assume that the adoption of case randomisation by a market leader like Google will soon bring about change.

Resolver-side support (the ability to generate queries containing case-randomised domain names, and to check inbound responses for case matches, possibly by enabling an option) differs from one software package to the next. So, for example, Unbound, Knot and F5 do support the technology, but BIND doesn't.