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

Automatic installation of new DNSSEC trust anchor

  • Monday 24 July 2017

Most software for DNSSEC-validating resolvers now supports RFC 5011. Any resolver running such software can therefore automatically install the new public root KSK as a trust anchor.

Although RFC 5011 is designed so that (root) KSK rollovers can take place without the system administrator's intervention, it's important to check that your resolver's current installation/configuration does actually support automatic trust anchor installation. If a validating resolver doesn't have the new trust anchor installed by 11 October 2017, all internet domains will become unreachable for any user or application relying on that resolver.

In an earlier article we explained the different ways that validating resolver operators can install the new trust anchor on their systems and provided guidance tailored to the various resolver software packages.

In this article, we take a look at RFC 5011 and tell you what support the most popular resolver software products provide. In a follow-up piece, we'll explain how you can check that the new trust anchor is installed and working properly.

RFC 5011

RFC 5011 is a protocol that lets a validating resolver implement the whole rollover process itself. First, the new public key (in the form of a DNSKEY record) is obtained from an authoritative server for the root zone (or another trust point). The record has a digital signature based on the old, trusted key pair, so the resolver is able to confirm the record's authenticity using the usual DNSSEC functionality. The SEP bit (Secure Entry Point bit; see RFC 3757) in the DNSKEY record tells the resolver that the KSK is valid.

At a later stage, the old public key can be removed from the list of trust anchors by setting the DNSKEY record's REVOKE flag. In other words, as well as being used to declare insecure key pairs invalid, this existing functionality now serves to clear out expired keys.

Because the method depends entirely on a trusted public key being present on the resolver side, it will work only with systems on which a trust anchor is already installed. Most resolver software developers therefore provide the current trust anchors hard-coded into their products as a matter of course.

KSK-2017

The new key (KSK-2017) was published in the root zone on 11 July. You can request the current public keys from the root zone as follows:

dig +multiline . DNSKEY

The following output will then be obtained:

  .    13775 IN DNSKEY  257 3 8 (
           AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
           bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
           /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
           JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
           oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
           LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
           Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
           LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
           ) ; KSK; alg = RSASHA256; key id = 19036
  .    13775 IN DNSKEY  257 3 8 (
           AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
           iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
           7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
           LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
           efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
           pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
           A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
           9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
           ) ; KSK; alg = RSASHA256; key id = 20326
  .    13775 IN DNSKEY  256 3 8 (
           AwEAAYvxrQOOujKdZz+37P+oL4l7e35/0diH/mZITGjl
           p4f81ZGQK42HNxSfkiSahinPR3t0YQhjC393NX4TorSi
           TJy76TBWddNOkC/IaGqcb4erU+nQ75k2Lf0oIpA7qTCk
           3UkzYBqhKDHHAr2UditE7uFLDcoX4nBLCoaH5FtfxhUq
           yTlRu0RBXAEuKO+rORTFP0XgA5vlzVmXtwCkb9G8GknH
           uO1jVAwu3syPRVHErIbaXs1+jahvWWL+Do4wd+lA+TL3
           +pUk+zKTD2ncq7ZbJBZddo9T7PZjvntWJUzIHIMWZRFA
           jpi+V7pgh0o1KYXZgDUbiA1s9oLAL1KLSdmoIYM=
           ) ; ZSK; alg = RSASHA256; key id = 15768

The key with key ID 20326 is the new public KSK. The value 257 (set SEP-bit) tells you that this is a valid KSK.

Activation

For security reasons, RFC 5011 states that a new public KSK must not be added to the trust anchors for at least thirty days (the hold-down period). During that period, a resolver has to check at intervals not exceeding two weeks whether the new key is still present. Any resolver that has obtained the key as described will therefore activate it as a trust anchor in the period 10 to 24 August.

Support

The most popular resolver software packages are listed below, with details of their RFC 5011 support status.

BIND named

  • Supports RFC 5011 from version 9.7.0 ('managed-keys')

  • Manual installation from version 9.6.2 ('trusted-keys'), the first implementation of DNSSEC validation in BIND

Unbound

  • Supports RFC 5011 from version 1.4.0 (managed keys in 'auto-trust-anchor-file')

  • Manual installation as static trust anchor for older versions (using 'unbound-anchor')

  • KSK-2017 trust anchor supplied with software from version 1.6.1

  • Release 1.6.5 fixes a problem with Unbound installations made between 11 September and 11 October of this year; operators who install Unbound in the near future should therefore use this latest version

PowerDNS Recursor

  • Supports validation only from version 4.0; doesn't yet support RFC 5011

  • KSK-2017 trust anchor supplied with software from version 4.0.5

  • Upgrade or manual installation using the Lua interface

Infoblox

Windows DNS Server

Knot DNS Resolver

Dnsmasq

  • Doesn't support RFC 5011

  • KSK-2017 trust anchor supplied with software from version 2.77

  • Manual installation required (from version 2.69, the first implementation of DNSSEC, using trust-anchors.conf)

  • Developer Simon Kelley says that versions older than 2.76 should no longer be used anyway, due to bugs in the validation element

Next step: testing

The list presented above, together with the information we previously provided about manual trust anchor updating, gives you a good basis for preparing your resolvers for the actual rollover (scheduled for this autumn). It's important to recognise that, in practice, an existing installation may differ considerably from those we describe. For example, the maintainer of an OS distribution may have added KSK-2017 to 'their' packages as a trust anchor. There is also the possibility of an installation running a new version of the resolver software, but with an outdated configuration.

The next step is to test whether everything is working as it should. That topic will be covered in a follow-up article, which we'll publish once all resolvers that support RFC 5011 should have activated the new trust anchor.