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

ICANN replaces secret DNSSEC keys

  • Monday 26 June 2017

Last autumn, ICANN began the rollover of its Key Signing Keys. The rollover involves replacing the cryptographic key pair for the root zone: the basis of the entire DNSSEC infrastructure. The keys have to be changed periodically for security reasons. This'll be the first time that they've been rolled over since DNSSEC was introduced in 2010.

Rollover follows a carefully controlled procedure

ICANN's rollover is now in progress. A strictly defined and carefully controlled procedure has to be followed. That takes quite some time: about two years from start to finish. The rollover will be complete in August 2018. As long as nothing goes wrong, end users won't be aware of any change.

Important role for DNSSEC operators

At the local level, validating resolver operators have an important role to play in the rollover. If you operate a validating resolver, you need to add the new (public) key to your servers and later remove the old key from your system. Otherwise it won't be possible to validate the digital signatures of domain names under any of the top-level domains (TLDs). Then all internet domains will become unreachable for everyone relying on the resolver in question.

What you need to do in the short term

If you're a DNSSEC operator and you'd like to know more about the rollover and your part in it, we can help. Check out our special question and answer resource.

Key signing keys for .nl already replaced

We rolled over the Key Signing Keys for the .nl domain last year. Like the root zone rollover, it was the first since 2010. To assure the reliability of the DNSSEC infrastructure, a strict security protocol had to be followed. The old key pair was phased out of the .nl zone in summer 2016, and we are pleased to report that everything went without a hitch.

FAQ

What is the KSK key pair?

The Key Signing Keys (KSKs) for the root zone are a cryptographic public/private key pair that plays a vital role in the DNSSEC security protocol. The key pair is the trusted starting point for DNSSEC validation, just as the root zone is the absolute starting point for looking up domain names in the DNS hierarchy.

Just as you start at the root zone when you look up a domain name in the DNS hierarchy, you start at the trusted root KSK when validating a DNSSEC signature. From there, you build a chain of digital signatures and public keys – the 'chain of trust' – to ultimately establish the authenticity of the relevant DNS information.

What does the KSK rollover involve?

The rollover is the process that leads to ICANN deleting the existing KSK key pair that serves as the starting point for validation and as the trust anchor for the root zone, and replacing it with a new key pair ('KSK-2017'). This'll be the first such rollover since DNSSEC was introduced in 2010.

How long would a back out or phase extension last?

A back out or phase extension might be indefinite, or until such a time as the underlying problems had been studied and dealt with. ICANN would then implement the solutions in a new KSK rollover process.

 

What impact would a back out or phase extension have?

The aim of a back out or phase extension would be to maintain the stability of the DNS, so the implications for end users would be minimal.

What will the rollover mean for internet users?

As long as nothing goes wrong, end users won't be aware of any change.

Who needs to take account of the KSK rollover?

Internet access providers (IAPs), internet service providers (ISPs), registrars, hosting service providers, network operators and others who run validating resolvers need to have the new public KSK and install it as a trust anchor on their systems and devices.

How do you keep up to date with the KSK rollover process?

  • ICANN is running a big campaign to make sure that everyone who uses the KSK key pair knows that it's changing.

  • A calendar is available on ICANN's website, with details of all the KSK rollover discussions that are taking place. There's also a web page with news and information about the rollover. And you can join a mailing list <link> for e-mail updates. ICANN's Twitter account tweets on the topic as well, under the hashtag #KeyRoll. So there are various ways of keeping abreast of developments.

  • SIDN, the operator of the .nl top-level domain, has developed its own communication plan to help the KSK rollover go smoothly in the Netherlands. These FAQs are part of that plan. Over the next few months, additional information will be made available on the Dutch DNSSEC knowledge platform. And SIDN will be highlighting the rollover in its newsletter and through its social media channels. Various knowledge partners and tie-ins will be involved as well.

  • SIDN has the following publications planned for this spring:

    • Practical advice on manual installation of the new public KSK as a trust anchor

    • A list of popular software packages for validating resolvers, saying whether each of them already supports, is going to support or isn't expected to support RFC 5011

For the autumn, the following publications are planned:

  • Practical advice on performing operational checks on software and systems to see whether RFC 5011 is implemented correctly, meaning that the trust anchor rollover can be handled automatically

  • Information about phasing out and deleting the old KSK key pair

Why does the KSK key pair have to be rolled over?

Generally speaking, it isn't a good idea to keep the same cryptographic keys in use indefinitely. Like passwords, they need to be changed every so often for security reasons.

Replacing your keys on a reactive basis in an emergency could be seriously disruptive. So it makes more sense to replace them proactively as a precaution while everything is still running normally.

When DNSSEC was introduced in 2010, the US telecoms regulator NTIA – which was involved in the first phase of DNSSEC – ruled that the KSK key pair had to be replaced ('rolled over') at regular intervals. The operators of the root zone therefore drew up a plan for rolling over the keys five years after the introduction.

What might go wrong?

It's possible (or even likely) that the new trust anchor won't be installed on all systems and devices that perform DNSSEC validation. Worldwide, there are millions of resolving systems, serving maybe 750 million users. Another possibility is that some software won't be able to handle the update to the file containing the trust anchors. That pitfall is explained on IANA's website. If the problems were widespread, the root zone's operators could decide to roll back the changes in order to restore stability to the DNS system. That's known as the 'back out scenario'. ICANN could also prolong a phase in the rollover process to head off problems with the DNS system. That might be considered if, for example, new information came to light indicating that the next phase was going to trigger problems of one sort or another.

Just how will the KSK rollover work?

  • The KSK rollover process involves eight phases lasting a total of about two years. Each phase is linked to an official key ceremony. The individual phases are described in the timetable below.

  • The KSK key pair is used to digitally sign the root zone's DNSKEY Resource Record Set (RRset). The signatures are attached in the key ceremonies and then become part of the root zone.

  • Before the existing KSK key pair can be withdrawn, the new key pair has to be placed in the root zone alongside the old key pair. After a period when the two key pairs are operating side by side, the old key pair is removed from the root zone.

What is the timetable for the eight phases of the rollover process?

  • Phase A: key generation (October 2016):

    • The KSK-2017 key pair is generated at the first key management location.

  • Phase B: key replication (February 2017):

    • The KSK-2017 key pair is copied to the second key management location. The new KSK key pair is then officially ready for use.

  • Phase C: the primary DNS data is signed using the KSK-2017 key for use in phase D (May 2017):

    • The first requests for signing are performed.

  • Phase D: publication (August 2017):

    • ICANN publishes the public KSK-2017 key in the root zone.

    • The information in the root zone is signed with both the old KSK-2010 and the new KSK-2017 key.

  • Phase E: rollover (November 2017):

    • Only the new KSK-2017 key is still used to sign the root zone.

  • Phase F: withdrawal (February 2018):

    • ICANN deletes the old KSK-2010 key pair from the root zone.

  • Phase G: deletion 1 (May 2018):

    • ICANN deletes the old KSK-2010 key pair from the first key management location.

  • Phase H: deletion 2 (August 2018):

    • ICANN deletes the old KSK-2010 key pair from the second key management location.

What should you do in the short term?

  • Developers who are responsible for software that performs DNSSEC validation need to make sure that their products support RFC 5011. That's a standard for automatically importing the new public KSK from the root zone and installing it as a trust anchor.

  • We'll soon be publishing a list of popular software packages for validating resolvers, saying whether each of them already supports, is going to support or isn't expected to support RFC 5011.

  • For software that doesn't support RFC 5011 and devices on which RFC 5011 is disabled, a file containing the trust anchors is available from the IANA website. The file needs to be imported each time the resolver is started and whenever the KSKs in the root zone's DNSKEY RRset change.

  • Software developers and validating resolver operators can use the operational tests developed by ICANN. The tests let you check whether RFC 5011 is correctly implemented, meaning that the trust anchors will be automatically updated when the rollover goes through.