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

Improvements made to the .nl zone

NSEC3 settings adjusted

Digital padlock against a binary code background

On 29 November we made a number of important improvements to the .nl zone, including the application of new NSEC3 settings. Defined in RFC 5155, NSEC3 was developed partly to address the 'zone walking' security issue associated with NSEC. NSEC3 features a so-called 'opt-out bit', which a resolver can use to improve caching efficiency and it also prevents unimpeded modification of the zone by any malicious party, if they managed to get the zone.

NSEC3

Aggressive cache use increases speed and efficiency of validating resolvers

NSEC3 is part of DNSSEC, and provides for the use of digitally signed records to confirm that a requested name does not exist. Opt-out should only be used by large zones with relatively few signatures. Since the .nl zone is a large zone with numerous signatures (~58%), we have decided to disable the opt-out.

Errors

When we made the necessary changes in our test environment, a number of errors in OpenDNSSEC came to light. We also found that the name server configurations had to be changed to prevent problems arising from the size of the journal (a local database of changes that have been made). Once every so often, a name server receives a message detailing (minor) changes. The name server records the changes in a journal, enabling it to pass on the information to other name servers.

We went through all the changes several times in our testing and acceptance environment, repeatedly refining them until we had a version that could be used in production without causing problems. Disabling the opt-out bit resulted in the zone file increasing in size from ~3.3GiB to ~4.1GiB (an increase of ~26%), while the duration of the signing process increased by 3 minutes.

Best current practice

The zone changes bring SIDN back into line with the best current practice (BCP) defined in RFC 9276/BCP 236. Failure to comply with BCP could result in resolvers on the internet mistakenly concluding that our zone is not secure, or even completely wrong (error code SERVFAIL). The changes therefore mean that we are well prepared for the future.

Background

As well as disabling the opt-out bit, we modified the salt (as recommended in the RFC/BCP) from "1 0 5 32280ECEE31048D8" to "1 0 0 -". The change means that we have gone from 5 iterations to 0, and from a salt length of 8 bytes (32280ECEE31048D8) to one of 0 bytes (-).

Aggressive cache use

RFC 8198 was published in July 2017 and updated by RFC 9077 in July 2021. The two RFCs deal with the local storage (caching) of DNS responses by a resolver, and 'aggressive' cache use by the resolver. In DNSSEC, an NSEC record is used to specify the non-existent records between certain names. Suppose, for example, that .nl had the following items in the zone:

a.nl IN AAAA 2001:db8:53:49:44:4e:6e:6c
d.nl IN A 192.0.2.1

If a client asked a resolver first for b.nl and then for c.nl, the resolver would be able to respond to the request for c.nl by referring to its cache, since it knows from the NSEC response to the first query that there is nothing between a.nl and d.nl.

Opt-out

NSEC3, which we use for .nl, allows for an opt-out bit to be enabled, implying that records are signed only if there is a DS record in the zone. That has the unfortunate consequence that a resolver can respond on the basis of cached information only if it receives a query that is identical to one that it has already processed. For example, a query about b.nl can be answered from the cache only if the resolver has already responded to an identical query. The reason being that c.nl might exist, but has no DS record in the .nl zone, meaning that it is not mentioned in the NSEC3 response. With the opt-out bit disabled, a resolver can make better use of its cache, in line with RFCs 8198 and 9077.

We currently lack proper insight into aggressive NSEC3 caching, and will therefore be studying the subject in due course.

Article by:

Portrait photo of Stefan Ubbink

Stefan Ubbink

DNS Engineer