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

Root zone rollover has implications for DNSSEC operators

  • Thursday 19 January 2017

19 January 2017

In autumn 2017, ICANN initiated the rollover of the (KSK) pair for the root zone. The rollover involves renewing (i.e. replacing) the root zone's cryptographic key pair, which underpins the entire DNSSEC infrastructure.

Renewing the key pair entails significant risk. Although it is very unlikely that anything will go wrong, an error could potentially render all internet domains (including non-signed domains) unreachable for all users and applications that rely on validating resolvers.

The situation is similar at the local level. Validating resolver operators need to first add the new (public) key to the trust anchors on their servers, and subsequently remove the old key from their systems. If an operator fails to act, it won't be possible to validate any digital signatures beneath the top-level domains (TLDs) in the root zone. Then all internet domains will become unreachable for everyone relying on the resolver in question.

RFC 5011 sets out a protocol for automatically installing the new (public) key as a trust anchor. The developers of the most widely used validating resolvers — BIND named, Unbound and OpenDNSSEC — all say that their software supports the protocol. The very dated Infoblox appliances don't support RFC 5011, meaning that Infoblox users face a fresh set of problems.

First rollover

The current operation involves the first rollover of the root key since the original root key was generated, installed and published in 2010. Although the rollover is now in full swing, there has been little publicity and few outward signs of activity, because it is a very carefully controlled and painstaking process.

The operational element of the rollover began properly last autumn, with the generation of a new KSK pair. The entire process will continue until March 2018, when the old key is due to be deleted from the root zone. However, the true duration of the administrative project is much greater. It started with the initial public consultation in 2013, and will not end until the old key pair is destroyed in August 2018.

Timetable

The operational timetable is currently as follows:

  • 27 October 2016: new key pair generated

  • February 2017: new (public) key published on the IANA site

  • 11 July 2017: new (public) key published as DNSKEY record in the root zone

  • 11 October 2017: root zone signed using new key (actual rollover)

  • 11 January 2018: old (public) key withdrawn (digital signatures based on the old key pair cease to be valid)

  • 22 March 2018: old (public) key deleted from the root zone

  • August 2018: last remaining copy of the old key pair destroyed

New key pair

Although the new key pair has already been generated, the pair's public key has not yet been made available. Before being released, the keys have to be internally tested and audited, after which they can be copied to ICANN's second 'digital safe' (HSM). Only then can the public key first be published on the IANA website, and subsequently added to the root zone in the form of a DNSKEY record.

Validating resolver operators still have a little while to wait, therefore, until the new (public) key is actually published. Once it has been published, operators can add the key to their own systems as a trust anchor. That has to be done by 11 October 2017, after which the old key pair won't be used for signing. If an operator fails to act, it won't be possible to validate any digital signatures beneath the top-level domains (TLDs) in the root zone. Then all internet domains will become unreachable for everyone relying on the resolver in question.

Against that background, it is important that operators act now to ensure that the change is implemented in due course — even if the action consists of nothing more than setting a non-dismissible reminder. The rollover is, after all, a one-off event with major ramifications.

Updates

There are three ways of installing the new public key on a validating resolver as a trust anchor. First, there is the manual method. Once it becomes available next month, the key can be fetched from the IANA website and added to the resolver's configuration. At a later date, it will also be necessary to manually delete or disable the old key.

In some cases — e.g. with certain Linux distributions — the updates will be made automatically as part of the normal system updating process. First, the new trust anchor will be installed as part of a package update, and later the old trust anchor will be deleted in a similar way. Needless to say, that does depend on the relevant system update processes being run on a regular basis.

RFC 5011

In addition, a protocol has been developed that enables a validating resolver to autonomously fetch a new (public) key and install it as a trust anchor. RFC 5011 defines how a resolver can carry out a fully automated trust anchor rollover.

First, the new public key (in the form of a DNSKEY record) is obtained from an authoritative server for the root zone. The record has a digital signature anchored to the old, trusted key pair, so the resolver is able to confirm the record's authenticity using the usual DNSSEC functionality. A new flag — a Secure Entry Point (SEP) bit — is set in the DNSKEY record, so that the resolver knows that the key can be installed as a trust anchor.

At a later stage, the old public key can be removed from the list of trust anchors by setting the DNSKEY record's REVOKE flag. In other words, as well as being used to declare compromised key pairs invalid, this existing functionality now serves to clear out expired key pairs.

The RFC also describes various scenarios in detail, explaining how each should be dealt with and setting out the timing requirements for ensuring the reliability of the process.

Because the method depends entirely on a trusted public key being present on the resolver side, it will work only with systems on which a trust anchor is already installed.

Support

The developers of various validating resolvers, including BIND named, Unbound and OpenDNSSEC, have indicated that their products support RFC 5011.

Unfortunately, however, Infoblox appliances do not support the protocol. We have already reported that the Infoblox DNSSEC implementation is seriously outdated, and the lack of RFC 5011 support represents a further problem in that regard. Infoblox appliances are used mainly by large organisations such as government agencies and banks, on the assumption that they represent a turnkey solution.

Recommendations

Even if validating resolver software is claimed to support RFC 5011, we recommend checking that everything is in order. After all, there has never been a root key rollover before, and the risks for end users are considerable. Validating resolver operators are therefore advised to closely monitor and double-check the (automatic) installation of the new (public) key as a trust anchor. Automated installation is possible from 11 June, when the new key is published in the root zone in the form of a DNSKEY record.

However, manual installation of the new trust anchor will be possible from next month. That is when the new (public) key is first published on IANA's website.

Finally, the old trust anchor can be deleted on or after 11 January 2018, but no later than 22 March 2018.