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

IANA to publish current DNSSEC algorithm recommendations centrally in future

Change should mean clear references and faster updates

Futuristic background with padlock on digital integrated circuit
  • Friday 7 February 2025

Recommendations regarding the cryptographic algorithms used under the DNSSEC protocol are going to be moved from the RFCs to the IANA register. A proposal to that effect will shortly itself be published as an RFC.

The main reason for the change is that it'll make it easier to refer to the most recent recommendations. It'll also speed up the process of updating recommendations.

Until now, recommendations regarding the use, support and implementation of cryptographic DNSSEC algorithms have been published within RFCs. The most recent official recommendations are contained in RFC 8624, which was discussed in some detail in a previous article of ours.

An update to RFC 8624 is being prepared, which will advise the phase-out of all DNSSEC algorithms based on the deprecated SHA-1 hash function.

Central register

The latest proposal (currently still known by its working title 'rfc8624 bis') is to remove such recommendations from the RFCs and include them in the IANA register instead. The recommendations in question are ones like those made in sections 3.1 (DNSKEY algorithms) and 3.2 (DS algorithms) of RFC 8624. Under the proposal, the 2 tables in those sections will be transferred to the IANA register.

At the moment, the DNSSEC tables administered by IANA [DNSKEY, DS] are little more than lists of numbers, names and statuses (the latter for DS algorithms only). Under the proposed arrangement, the recommendations contained in the RFC tables will be added to the tables in the IANA register. Future RFCs (and other documents) can then always refer to the IANA tables as the source of the most recent advice.

Latest (conservative) insights

Any future updates to the recommendations would still be published as RFCs, but also incorporated into the IANA tables. Typically, the recommendations are updated every few years, as existing algorithms become 'deprecated' (i.e. deemed unsuitable because they are outdated or insecure), and as new algorithms are added [1].

After all, the purpose of the recommendations is of course to ensure that domain name registrants and authoritative name server operators make use of the most secure and efficient algorithms (according to the latest, albeit conservative insights), and that validating resolvers also support the algorithms actually in use (for reasons of interoperability). In turn, software-builders need to see to it that deprecated and insecure algorithms are phased out (as soon as market circumstances allow), and that new algorithms are made available to users promptly.

Algorithms used in the .nl zone for DNSSEC security
https://images.ctfassets.net/yj8364fopk6s/2Y7Mz9Zy69mJRHyr3jTau4/f899b0e7291f92a7550c268d613dbcd5/stats.sidnlabs.nl-DNSSECalgoritmes-20250123.png

Formalised form and content

However, the form and content of the tables in the IANA register are quite formally regulated. Under 'rfc8624 bis', the following columns will be added to the existing tables:

DNSKEY algorithms:

  • Use for DNSSEC Signing

  • Use for DNSSEC Validation

  • Implement for DNSSEC Signing

  • Implement for DNSSEC Validation

DS algorithms:

  • Use for DNSSEC Delegation

  • Use for DNSSEC Validation

  • Implement for DNSSEC Delegation

  • Implement for DNSSEC Validation

The first 2 columns are intended for domain name registrants/operators and DNS service providers, respectively. The latter 2 columns are intended for the developers of, respectively, authoritative name servers and validating resolvers.

The recommendations themselves will be allowed to use the values 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY' and 'OPTIONAL'. The formal meanings of those values are defined in RFC 2119.

Current recommendations

The latest, complete tables that under the proposals would be transferred to the IANA register are contained in sections 3 and 4 of 'rfc8624 bis'. The practical implication for domain name registrants/operators is that algorithm 8, algorithm 13 and algorithm 15 can in principle be used for DNSKEYs. However, we recommend that everyone should use algorithm 13, as we ourselves do in the .nl zone.

Only algorithm 2 is still recommended for DS use. However, .nl domain name registrants/operators don't have to concern themselves with that because we only require a DNSKEY record to be provided, not a DS record. We have always generated DS records ourselves using algorithm 2, from the DNSKEY records provided to us.

For more information about the various algorithms and recommendations, see our DNSSEC FAQs.