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

Transfer of DNSSEC-enabled domains: IETF method is preferred

New internet standard in development

  • Monday 1 October 2012

Internet hosting provider Oxilion recently hosted a Lunch & Learn meeting at its offices. At the meeting, a number of internal and external DNS specialists talked about the transfer of DNSSEC-enabled domains.

The underlying issue was quickly apparent: the transfer of a signed domain from one DNS operator to another without interrupting its security depends on cooperation between the releasing operator and the receiving operator. Both parties have to cooperate fully, even though the releasing operator is certainly losing the domain in question and may be losing the customer altogether. Although the two operators should in principle be able to exchange information without difficulty, the practical reality is often less straightforward.

Two methods

The transfer of a secure domain needs to fulfil three criteria: the domain has to remain secure throughout the transfer, the domain has to remain fully functional throughout the transfer, and the two DNS operators shouldn't exchange private keys.

To date, two transfer methods have emerged that fulfil those criteria:

1. The IETF method

In the IETF method, invented by SIDN, the old ZSK is added to the new DNS operator's zone ahead of the transfer and signed with a new KSK. Then the new ZSK is added to the old DNS operator's zone and signed with the old KSK. After that, the administrative transfer (registrar change) can go ahead and the new KSK (DS) can be uploaded to SIDN, so that the new zone can be validated. Once the old key set's TTL has expired (a potential show-stopper), a DNS operator change (NS change) can be performed. The TTL of the old NS set (a fixed value) then has to be allowed to expire before the old KSK (DS) can be deleted from SIDN's database. Finally, once the TTL of the old DS records (a fixed value) has also expired, the new ZSK can be deleted from the old zone.

Advantages:

  • The process is clearly defined and can be fully automated.

  • The message containing the new ZSK can be authorised by means of a token.

  • Full support is possible even if the releasing registrar isn't the DNS operator.

  • The system is suitable for implementation by multiple registries/TLDs.

Disadvantages:

  • The system involves a significant number of steps.

  • It's necessary to wait until the TTL of the old KEY set has expired. If the TTL is very long, transfer will be practically impossible without a security interruption.

2. The ICANN method

With this method, the new KSK (DS) is uploaded to SIDN and linked to the domain name in anticipation of the DNS operator change. That is done while the domain is still registered through the old registrar and the old name servers are still in use. Once the DS records' TTL (a fixed value of two hours) has expired, the receiving DNS operator has to import the old zone in its entirety. That could be done via AXFR, with the registry acting as proxy. The advantage of that arrangement is that the DNS operators could easily make arrangements amongst themselves. The drawback is that a lengthy list of ACLs would have to be maintained. Thereafter, the new ZSK is added to the zone and the RRSet is signed with the new KSK. The zone can then be signed with the new ZSK, but the old RRSIGs are retained. After that, the DNS operator change (name server change) can go ahead. Once TTL of the parent NS (a fixed value) has expired, validating name servers will refer to the new zone for validation. Validation of the old records nevertheless remains possible because the old RRSIGs have been retained.

Advantages:

  • The process is relatively straightforward and involves relatively few steps.

  • It isn't necessary to wait to a TTL over which the receiving registry has no control. The length of the waiting time is therefore known in advance and the process can be completed within an acceptable time frame.

Disadvantages:

  • The entire zone has to be transferred from the old DNS operator to the new one. That could be done by opening AXFR, thus enabling automation. However, DNS operators won't necessarily welcome the idea of opening AXFR to the registry or the receiving DNS operator.

  • Timing will be critical, since the old RRSIG records will have fixed validity periods. Once an RRSIG record's validity has expired, the associated domain is liable to be treated as bogus.

  • Throughout the transfer (from the time of the zone transfer), no changes may be made to the old zone without sharing the relevant information with the new DNS operator.

Consensus

After considering the pros and cons of the two methods, the group agreed that the ICANN method was the only workable solution for automation on the basis of AXFR. However, the group didn't believe that that would happen in practice. Furthermore, the IETF method was seen as offering real scope for implementation within SIDN and other registries. The TTL-related issue with the IETF method did not lend itself to a technical solution, but could be addressed by procedural or other means. For example, SIDN could require DNS operators to use acceptable (i.e. reasonably short) TTLs for DNSKEY information in the zone. The group concluded that the IETF method was preferable and advised SIDN to make that method the basis for future developments in this field. However, the group wanted registrars to retain the option of using the ICANN method if both parties to a transfer wanted that.