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

ZONEMD assures the integrity of complete zone files

New security feature planned for root zone at the end of the year

Digital padlock in blue colored motherboard like digital environment
  • Thursday 20 July 2023

The relatively new ZONEMD record can be added to a zone to assure the integrity of the zone's DNS information. A zone file's recipients/users can then be sure that their copy is correct and complete. The ZONEMD record is in turn secured by a DNSSEC signature, making everything cryptographically watertight.

Preparations are currently being made for the addition of a ZONEMD record to the root zone. This new security feature will be significant mainly for recursive resolver operators that want to cache a complete copy of the root zone locally.

However, the ZONEMD record is potentially of interest to us as well. In order to ensure that our authoritative servers are reachable from different locations around the world, we generally make use of peering agreements with reliable partners ('peers') in the internet infrastructure world. However, we are also looking at the possibility of running authoritative name servers for the .nl zone on relatively cheap virtual machines operated by commercial service providers. With such a set-up, it is of course vital that the DNS information is always reliable, regardless of any security issues a service provider may have.

The current plan is for the ZONEMD record [1] to be added to the root zone on 13 September 2023. The algorithm specified in the record will initially be a private-use algorithm, so that validation is effectively disabled. Then, on 13 December, the transition to the SHA-384 algorithm will be implemented. Once that's done, consumers will be able to use the ZONEMD record to check the integrity of the zone file. The root servers themselves will not start validating the ZONEMD record until at least a year after the introduction. Although no implications are expected for consumers/users, it's good to know that, from this autumn, the root zone file will contain an extra record type and security feature.

Copies of zone files

There are several good reasons why a recursive resolver might want to cache a complete copy of the root zone locally. RFC 8806 identifies 2 of those reasons: to avoid delays in the event of a network attack, and to prevent the interception and monitoring of traffic between the resolver and the root servers. In such circumstances, a signed ZONEMD record assures the integrity of the local copy (and, implicitly, the authenticity of the source).

Here at SIDN, we see a third reason for using ZONEMD: registries whose secondary name servers are (or include) virtual servers leased from commercial providers want to be sure that those servers are delivering the correct DNS information. The ZONEMD record provides that assurance, because it ensures that the zone file loaded on a cloud server is the correct and complete version (providing that the DNS software has not been compromised).

How ZONEMD security differs from TSIG and DNSSEC

The essential difference between ZONEMD and the existing TSIG security for zone transfers (AXFR) and updates (IXFR) is that TSIG assures the integrity of the transport, whereas ZONEMD assures the integrity of the zone file itself. Also, TSIG requires that a private key is first exchanged between the primary and the secondary.

In principle, the integrity of a zone file could be verified by validating each individual DNSSEC signature, since the original DNS records and the intermediate NSEC(3) records together form a continuous chain covering the relevant zone's entire name space (a fact exploited for zone walking). However, that would require considerable processing power, especially if an ECDSA-based DNSSEC algorithm is used. What's more, DNSSEC doesn't quite cover all the records in the zone: non-apex NS records (delegations), glue records and NSEC(3) records for unsigned delegations are omitted (the latter only if the opt-out bit is set to 1). DNSSEC serves to assure the integrity of DNS responses, while ZONEMD assures the integrity of complete zone files.

ZONEMD and DNSSEC

The ZONEMD record itself (defined in RFC 8976) has a relatively simple structure: First, all the information in the zone is placed in a standardised alphanumeric order, then the hash value of the entire body of information is calculated. The resulting 'message digest' (a statistically unique, digital summary) is published in the ZONEMD record, together with the serial number of the zone file and the algorithm used to generate the hash (SHA-384 or SHA-512).

It should be noted that calculation of the ZONEMD hash and DNSSEC signing are interrelated processes. At the start of the signing process, a placeholder for the ZONEMD record has to be inserted. Once that's been done, the zone can be signed, which involves also generating the appropriate NSEC(3) records for the ZONEMD RRset. After that, the hash value for the ZONEMD record can be calculated (with the appropriate NSEC(3) records included). Finally, the digital signature for the current ZONEMD RRset is added (in an RRSIG record).

Validation

When the ZONEMD hash is validated at the receiving end, the first step is DNSSEC validation of the ZONEMD record. The DNSSEC support status is determined by checking for a DS record in the parent zone. (Where the root zone is concerned, the DS record is available from a DNSSEC-validating resolver, in the form of a trust anchor).

After that, the hash of the incoming zone file can be calculated in exactly the same way as at the sending end, and compared with the hash value in the accompanying ZONEMD record. The zone file is valid – and can therefore be loaded by the receiving name server – only if the 2 hash values are the same.

Large, highly dynamic zones

The process described above – where the sender performs sorting and hashing procedures, and the recipient undertakes similar procedures for validation – obviously takes considerable time. Nevertheless, the ZONEMD calculation and validation tasks are not unduly onerous where the root zone is concerned, because it contains only about 1,500 top-level domains and doesn't often change.

With a large, highly dynamic zone, the situation is somewhat different. For example, the .nl zone now contains 6.3 million domain names and is refreshed every half an hour. And we really need that full half hour. Although the Hardware Security Modules (HSMs) we purchased new in 2021 were in principle fast enough to perform the necessary calculations, switching from DNSSEC algorithm 8 to algorithm 13 necessitated optimisation of the signing and validation processes. Otherwise, the 20 million-plus signatures in the new .nl zone couldn't have been validated within the available time, because use of the ECDSA-based algorithm 13 makes validation more labour-intensive.

ZONEMD lookup

"ZONEMD is definitely attractive to us," says SIDN's DNS Engineer Stefan Ubbink. "However, the size of the .nl zone and the short refresh interval mean that we've got to carefully weigh up the need for and benefits of ZONEMD against the drawbacks and the time investment. Also, at the end of last year, we set the opt-out bit for the .nl zone to 0, meaning that the zone now includes NSEC(3) records for all unsigned delegations as well. Because we've extended DNSSEC protection that way, there's less incentive for us to have the extra security provided by a ZONEMD record. So we don't currently have any firm plans to add ZONEMD to the .nl zone. Nevertheless, we'll be watching with interest to see how things go with the root zone."