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.
Just four weeks until the root KSK rollover: time to check your DNSSEC trust anchors!
Just four weeks until the root KSK rollover: time to check your DNSSEC trust anchors!
Monday 18 September 2017
Validating resolvers that support RFC 5011 should by now have installed and activated the new public root KSK as a trust anchor. If you're still using software that doesn't support RFC 5011 and you haven't yet manually installed the new trust anchor, it's important that you do it soon. From 11 October, all internet domains will become unreachable for anyone relying on a resolver that doesn't have the new trust anchor installed.
In this article, we explain how you can check the availability of the new trust anchor.
Automated test environment
ICANN has set up an automated test environment that validating resolver operators can use to check that the RFC 5011 update mechanism is working properly on their systems. The procedure involves first manually installing a trust anchor for a special subdomain. The public KSK for the subdomain is then rolled over, so that the complete update cycle is followed. For details of the update mechanism, see the earlier article about RFC 5011.
Each week, a new test cycle is started with a new domain. Detailed information about the current status of the relevant domain and how to check whether everything is working properly is available by subscribing to e-mail updates.
Limited testing
The ICANN test environment serves only to check the general performance of the RFC 5011 update mechanism. You can't use it specifically to establish whether the KSK-2017 trust anchor is present and working properly. Or, as ICANN themselves say in their 2017 KSK Rollover External Test Plan: "It allows operators of validating resolvers to test whether their systems are likely to work during the KSK rollover if they are using RFC 5011."
However, what an operator wants now, with just four weeks left before the actual rollover, is to know for sure that the public KSK-2017 really has been installed on the resolver as a trust anchor. Unfortunately, it isn't yet possible to actually validate a domain name using the new root KSK. That's because, in order to limit the size of the UDP packet and thus prevent fragmentation of the network packets, a single-signature rollover design has been adopted. Consequently, until the actual rollover on 11 October, the root ZSK won't be signed using the new KSK, meaning that no chain of trust whatsoever can be built for KSK-2017.
Check trust anchors
The RFC 5011 update mechanism is ultimately a means to an end, i.e. installation of the KSK-2017 trust anchor. So it's more important to check whether the end has been achieved than whether the means are functional. In the following paragraphs, therefore, we look at each of the most popular resolver software products in turn and explain how the current trust anchors can be shown.
However, before checking the trust anchors, it's worth making sure that your resolver is actually validating. You can do
dig @ADRES dnssec-failed.org a +dnssec
If your resolver is validating, the response to that command will be the status message SERVFAIL, because, as the domain name 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 return the status NOERROR.
BIND named
From version 9.7.0, BIND named, the most widely used DNS server software, saves its trust anchors in the managed key database (in the managed-keys.bind file, or in View from version 9.8.0). From version 9.11.0, you can check out the contents using the following command:
rndc managed-keys status
In older versions, the script contrib/scripts/check5011.pl provides similar functionality.
If the KSK-2017 trust anchor, whose key ID is 20326, isn't listed (with the status 'trusted'), you'll need to refer to the detailed information about the root KSK rollover published by ISC (BIND named's developer).
Unbound
The validating resolver software Unbound saves its trust anchors in the 'auto-trust-anchor-file' (/etc/unbound/root.key). That file should include the KSK-2017 trust anchor (key ID 20326), and its status should be 2/VALID.
PowerDNS Recursor
The philosophy of the developers of PowerDNS Recursor is that, wherever possible, the complexities should be hidden from the user (resolver operator) and that as much as possible should be automated. Where the trust anchors are concerned, that implies having the public root KSKs hard-coded into the software. From version 4.0.5, the KSK-2017 (key ID 20326) is accordingly hard-coded. If you are using an older version, you'll need to add the new trust anchor using the Lua interface or the 'rec_control add-ta' command.
The following command can be used to find out what trust anchors the Recursor is currently using:
rec_control get-tas
Knot DNS Resolver
The trust anchors of the Knot DNS Resolver are saved in the 'trust_anchors.file' (root.keys). That file should include the following two key strings:
The Dnsmasq server loads its trust anchors from the trust-anchors.conf file. From version 2.77, the new KSK-2017 trust anchor is supplied with the software in that file. Developer Simon Kelley says that versions older than 2.76 should no longer be used anyway, due to bugs in the validation element.
(See the CHANGELOG for version 2.69 for details of the implementation of DNSSEC validation in Dnsmasq.)
Infoblox
All Infoblox appliances require the manual installation of the new KSK-2017 trust anchor. Infoblox Nederland says users are being actively informed.
Windows DNS Server
DNSSEC wasn't fully implemented on the Windows platform until Windows Server 2012. The trust anchors for the Windows DNS Server are saved in the file %windir%System32DNSTrustAnchors.dns.
In the PowerShell, you can view the current trust anchors using the following command:
Get-DnsServerTrustAnchor -Name .
The TrustAnchorData delivered in response should include the new key (key ID 20326) and the TrustAnchorState should be Valid.
Hassle-free roll-over
The verified availability of an active KSK-2017 trust anchor gives validating resolver operators the best chance of a smooth rollover on 11 October. Successful completion of the checks described above is therefore vital. As explained earlier, there is no way of actually validating a domain name on the basis of the new root KSK ahead of the rollover. The checks described are consequently both the least and the most that an operator can do before the big day.
If the checks reveal that the new KSK-2017 trust anchor isn't available/active on the resolver, we recommend referring back to our earlier articles on manual and automatic installation of the new trust anchor. Of course, there's also information in the software supplier's own documentation, and ICANN has published two hands-on articles [1, 2].
NB: because of the hold-down period of at least thirty days, it's now too late to start an update procedure based on RFC 5011. Therefore, any validating resolver that doesn't yet have the KSK-2017 trust anchor installed now requires urgent manual installation.
Finally, it's worth pointing out that, if the new trust anchor doesn't work on 11 October, the ultimate fallback option is to temporarily disable DNSSEC validation until the underlying problem has been rectified.
