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.
Accurate, secure system time is vital for DNSSEC – and vice versa!
Accurate, secure system time is vital for DNSSEC – and vice versa!
Building a more secure time service
Thursday 6 February 2020
Last summer, SIDN Labs launched a public internet time service. An NTP server has since been running at ntp.time.nl, which anyone can use to synchronise their system and device clocks. A reliable clock is important for countless applications, including time stamping documents, messages and mail, and displaying the time in photos and videos shot on your phone.
Precise and accurate timing is also vital for many security applications. Examples include the aggregation of server logs (e.g. for CGNAT), recording video from security cameras and checking the validity of digital signatures. Unfortunately, because the time is so important in the context of the RRSIG records added to DNS records when DNSSEC is enabled, hackers have started turning their attention to system clocks.
Almost all internet-enabled computers use one or more NTP servers. Operating system producers typically include a default list of servers that the system will refer to. A DHCP can also issue a list of time servers to any computer that connects to the network.
Often the supplier will themselves run several NTP servers. If not, you can always refer to the NTP Pool: an internet community initiative that now covers thousands of NTP servers, including ours. Be aware, however, that the Pool has itself attracted some unscrupulous individuals who add NTP servers for the sole purpose of harvesting IPv6 addresses and thus scanning the associated systems [1, 2].
The NTP Pool
People who want to use the systems in the NTP Pool normally compile a list of generic host names for their own country. For the Netherlands, the configuration is as follows:
server 0.nl.pool.ntp.org
server 1.nl.pool.ntp.org
server 2.nl.pool.ntp.org
server 3.nl.pool.ntp.org
The Pool's administrators change the servers linked to those addresses on an hourly basis, in order to spread the load across the available systems. "Our service is now attracting 4,600 users every five minutes," reports Marco Davids, Research Engineer at SIDN Labs. "Most of the traffic originates from the NTP Pool, but Cloudflare uses our service as well, in order to provide its clients in this region with stratum 1 NTP. Another of our service users is the NLNOG RING."
National NTP service
If (in network terms) you're close to SIDN's home city of Arnhem, where the bulk of our infrastructure is located, Davids recommends using the NTP server immediately (in combination with a few other NTP servers). "There's advice on configuring your computer to use our NTP service on the TimeNL website," he says. Davids emphasises that the service definitely isn't merely experimental. "TimeNL is designed to be robust and is fully production-ready. In the course of the year, we intend to make the service even more reliable by adding more servers. We're also in close contact with VSL, operator of the Netherlands' official atomic timing system, with a view to exploring ways to complement each others' activities. "We want to establish TimeNL as the Dutch national NTP service, like the services that various other countries have."
Because TimeNL is additionally a research project for SIDN Labs, a lot of service extension work is currently underway. Last month, for example, an (experimental) NTS server came on line. With NTS (Network Time Security), you have the additional benefits of TLS authentication and NTP parameter negotiation. The protocol is designed to address the issue that a man-in-the-middle can quite easily falsify unencrypted network packets exchanged using UDP (as in NTP), or spoof the sender's address. Because authentication and negotiation are conducted via a side channel, the client and server each know who the other is, while cryptography and tunnelling-related delays to the rapid NTP-over-UDP exchange are minimised. The NTS protocol currently remains in the development phase, however.
Clock adjustments
The importance of accurate system time is apparent from the number of internet (security) protocols that work with absolute timestamps. By way of example, the current DNSSEC RRSIG record for our own website (via IPv4) is shown below. The start and end of the validity period are specified to the second.
sidn.nl. 3600 IN RRSIG A 8 2 3600 20200216081059 20200117081059
42033 sidn.nl. WHuezZNN0KPIgQdM1cGqBg+0HiJA0/hT5VnaDlo1puf++s0oFrnClJJr...
If a hacker were to adjust the clock of an authoritative DNS server or a validating resolver, the way would be open for the abuse of expired signatures, invalid key material, fixed vulnerabilities and superseded configurations. For example, old (signed!) DNS responses could be re-injected in a combined replay and cache poisoning attack, causing the resolver's users to be misdirected to an IP address now controlled by the hacker. This paper explains how existing vulnerabilities in NTP and resolver implementations and configurations can be exploited so that records stored in a resolver's cache are deleted early or retained longer than was intended.
Cracked
It might even be possible to abuse one of the historical DNSSEC encryption algorithms (as detailed on IANA's website) and exploit the fact that the SHA-1 hash algorithm has now definitely been cracked.
Another possibility is that a system clock might be hacked in order to extend the window of opportunity for a successful brute-force attack. In order to moderate the processing power requirement, particularly on mobile devices, it's common practice to sign DNS records using truncated ZSK pairs. The consequent reduction in security is offset by keeping digital signature validity periods short and frequently rolling over the ZSK pairs. However, a hacker could potentially render those measures ineffective by adjusting the system time.
DNSSEC bootstrap problem
One of the underlying issues is the DNSSEC bootstrap problem: how does a system whose time has never been set know whether incoming DNSSEC signatures are valid? After all, a system may start its clock with a date as early as 1 January 1970. And the bootstrap problem's significance increases rapidly as IoT devices proliferate. For cost reasons, most IoT devices are not fitted with real-time clock (RTC) chips or batteries. Whereas NTP software can protect the system time set on a proper server by enforcing a limit on the size of adjustment, small devices without RTCs are vulnerable after every reboot.
The DNSSEC bootstrap problem is therefore essentially the same as the problem of how to load the first DNSSEC trust anchor on a validating resolver. The solution to that problem has been to set up a long downloading and validation procedure, which is not cryptographically watertight but offers reasonable security. The RFC 5011 mechanism for updating from an existing trust anchor can therefore be compared to the NTP security measure described above, where the current system time is used as the starting point for updates, and adjustments that exceed a prescribed limit are ignored.
