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

DNSSEC validation on BIND named

BIND named, the most widely used DNS server software, can function as an (authoritative) name server and/or as a (caching) resolver. This article looks at the configuration of named as a DNSSEC-validating resolver. The signing of a zone on an authoritative name server is dealt with in a separate article.

Because so many legacy BIND implementations are in use – some of which have been running for years – when explaining each feature, we have wherever possible stated the version in which it was first made available. We nevertheless recommend using the most recent version of BIND that you can, if for no other reason than that each successive version has bug-fixes and security-fixes absent from the earlier versions.

Validation

Support for the validation of DNSSEC-enabled domains was introduced with BIND version 9.6.2. Validation is enabled as follows:

  dnssec-enable yes;

  dnssec-validation auto;
  //dnssec-lookaside auto;

It's important to note that the 'dnssec-enable' option needs to be set to 'yes' not only to enable digital signature (RRSIG record) generation on an authoritative DNS server, but also to enable DNSSEC validation on a server that operates exclusively as a resolver. From version 9.16.0, the option was redundant, and it was removed altogether in version 9.18.0 and above.

The 'auto' option is available for the other two statements from version 9.7.0, which also introduced support for RFC 5011 (the automatic updating of trust anchors). In earlier versions, the only options are 'yes' and 'no'. The versions in question support only static trust anchors specified in a trusted-keys statement (replaced by the 'trust-anchors' statement in version 9.16.0 and above).

Dynamic Lookaside Validation

The 'dnssec-lookaside' option is used to configure Dynamic Lookaside Validation (DLV), a service provided by ISC (BIND's developers), which dates from before the root zone was signed. In that period, operators who wanted to sign their domains but couldn't construct continuous chains of trust to the root zone could lodge partial DNS trees ('islands of trust') with the dlv.isc.org domain, which had its own BIND trust anchor.

The DLV service is now redundant and was withdrawn in September 2017. All DLV-related code has accordingly been removed from BIND version 9.16.0 and above.

RFC 5011

From version 9.7.0, BIND saves its trust anchors in the managed key database (in the managed-keys.bind file, or, from version 9.8.0, in a '.mkeys' file for each view). In a one-off procedure, the database is initialised with the trust anchors specified in the 'managed-keys' statement ('initial-key'). If no such statement is present, BIND falls back on the external 'bindkeys-file' (default: bind.keys) or the keys that are hard-coded into the software. Newer versions of BIND don't have a 'bind.keys' file, and therefore always fall back on the inbuilt trust anchors.

BIND performs the initialisation only when the resolver is started for the first time and if the managed key database is empty. This 'bootstrap' procedure ensures that the current trust anchors are fetched from the internet, validated and installed. Thereafter, the trust anchors in the managed key database are managed automatically (in band) on the basis of RFC 5011.

From version 9.16.0, the 'trusted-keys' and 'managed-keys' statements are deprecated, and only the replacement options 'static-key' and 'initial-key' should be used (within the 'trust-anchors' statement). If the trust anchors aren't available in DNSKEY format, but only in DS format (as with new root trust anchors announced but not yet published by IANA), you can use them with the options 'static-ds' and 'initial-ds'..

Trust anchors

Operators of older validating resolvers need to check that the most recent public root KSK (KSK-2017) has indeed been installed and activated on their systems as a trust anchor. The most important aspects of the KSK-2017 trust anchor's installation in the various versions of BIND are set out below.

Checks

From version 9.11.0, you can retrieve the contents of the managed key database using the following command:

  rndc managed-keys status

In older versions (from 9.9.3), the script contrib/check5011.pl provides similar functionality.

The output is a list of trust anchors (per view):

  [root@system ~]# rndc managed-keys status
view: resolver
next scheduled event: Tue, 03 Oct 2022 15:29:38 GMT
    name: .
    keyid: 19036
        algorithm: RSASHA256
        flags: SEP
        next refresh: Tue, 03 Oct 2022 15:29:38 GMT
        trusted since: Mon, 28 Dec 2015 20:05:54 GMT
    keyid: 20326
        algorithm: RSASHA256
        flags: SEP
        next refresh: Tue, 03 Oct 2022 15:29:38 GMT
        trusted since: Thu, 10 Aug 2017 16:21:39 GMT

The command 'rndc secroots -' (from version 9.7.2) is used to obtain a list of both the managed keys and the static and negative trust anchors (again per view):

[root@system ~]# rndc secroots -
secure roots as of 25-Jan-2023 13:24:11.522:

 Start view resolver
   Secure roots:

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed

   Negative trust anchors:

The response shows that in this case two trust anchors are installed: with key IDs 19036 (KSK-2010) and 20326 (KSK-2017), respectively. The root KSK rollover process has since been completed in full, implying that any trust anchors for KSK-2010 that may remain should be removed from all resolvers. Detailed information about the root KSK rollover is available from ISC here.

Negative trust anchors

To set a negative trust anchor – a domain for which validation is disabled, as specified in RFC 7646 – you need to use the command 'rndc nta' (from version 9.11.0). The negative trust anchor functionality is intended mainly so that validation errors involving incorrectly configured ('bogus') domains can be (temporarily) disregarded.

Old configuration files

When checking the version of an existing BIND installation ('named -v'), make sure that the configuration file used ('/etc/named.conf') is up to date. If a DNS server was set up some time ago, and the software has since been upgraded to a more recent version by system updates, the configuration will often remain based on an earlier version. In that case, the best approach is to upgrade the configuration to the current version of BIND before setting up DNSSEC. In RHEL (and derivatives), CentOS (Stream) and Fedora, the templates supplied for named.conf can be found in the directory /usr/share/doc/bind(-version)/sample/etc/. However, the template at that location is also now outdated.

Testing

From version 9.10, you can check the current status of validation by the resolver using the command 'rndc validation check':

  [root@system ~]# rndc validation check
  DNSSEC validation is enabled (view resolver)

Finally, there is the command for remotely checking that your validating resolver is working properly (replace <ADDRESS> with the name or address of the server):

  dig @<server> servfail.nl

If your resolver is validating, the response to that command will be the status message SERVFAIL, because, as the domain name in this case indicates, the command deliberately involves a bogus DNSSEC chain of trust. A non-validating server won't check for a digital signature and will therefore simply return the status NOERROR.

servfail.nl-2022-12-17-10 03 24-UTC

If and when new DNSSEC functionality is added to BIND, we will update this article accordingly.