SIDN to promote adoption of the DANE internet standard
E-mail security standard added to the Registrar Scorecard
Chose your color
Frequently visited
Frequently asked questions
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.
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.
To update the contact details associated with your domain name, you need to contact your registrar. Read more about updating contact details.
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.
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.
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.
E-mail security standard added to the Registrar Scorecard
For the second half of the year, we'll be adding the DANE internet standard to the Registrar Scorecard (RSC) -- our incentive scheme for .nl registrars. DANE needs to be implemented in order to receive a STARTTLS incentive payment. Our reasons for promoting DANE, and what it's all about, are explained below.
We want to encourage the use of modern internet standards through the RSC. We already promote IPv6, for example, because we see it as essential for improved, sustainable access on a constantly expanding internet. Various other, relatively new standards can also contribute to the security and reliability of the internet.
The most obvious example is DNSSEC. DNSSEC makes name-address translation (the DNS) much more secure by preventing scammers getting a falsified address accepted for a domain name. With the aim of improving e-mail security, we're also promoting the DMARC, SPF and DKIM standards. That trio of standards is intended to combat phishing, a common form of internet abuse. Our policy on e-mail standards is also aligned with the government's 'use-or-explain' list and NCSC advice.
It seems extraordinary now, but for many years a lot of data traffic was sent over the internet without encryption. The various protocols simply didn't allow for it. Fortunately, things are very different now. The basic web protocol, HTTP, doesn't provide for encryption, so an encrypted version was developed: HTTPS, which utilises additional Transport Layer Security (TLS). Most of us know HTTPS best as the (typically green) padlock in our browser address bar.
Originally, the e-mail protocol SMTP didn't use encryption either. E-mail messages were transmitted in plain text format, so that the content was visible to an interceptor. Interception remains a fairly common problem, unfortunately, even though there is now a TLS extension to the standard, called STARTTLS. We therefore encourage the use of STARTTLS through the RSC as well.
With STARTTLS, mail servers need to agree on use of the protocol before exchanging a message. If agreement is reached, the message should be sent in encrypted form.
However, the original STARTTLS system isn't watertight. An attacker can easily interfere with the 'conversation' about whether STARTTLS should be used, so that the mail servers fail to agree on encryption. In the absence of agreement, the servers fall back on the old non-encrypted transmission method. It's also possible for an attacker to inject a fake certificate, taking advantage of the fact that the servers don't check properly. An encrypted connection is then established, but the mail isn't secure from the attacker.
Fortunately, there are protocols that address those issues: MTA-STS (which is still under development) and DANE. The developing MTA-STS standard is similar to the better-known HTST protocol. And it has the same flaw as that protocol: it follows the trust-on-first-use principle. In other words, another server's bona fides are initially taken on trust. So the system relies on there being no attacker active during the vulnerable first contact phase. After that, communication is secure. DANE doesn't have that vulnerability: it's secure from the outset. All the more so because, unlike MTA-STS, DANE leans heavily on DNSSEC.
The DANE protocol was originally used to increase website security. However, widespread adoption for that purpose was frustrated, mainly by the fact that not all end-users have the benefit of a DNSSEC-validating resolver. DANE is easy to use for securing STARTTLS on e-mail servers, and adoption for that purpose is proceeding at a healthy pace. The standard is also on the 'use-or-explain' list and accordingly recommended by the NCSC. As a result, government bodies are obliged to use it.
With additional DANE security, a STARTTLS connection is no longer facultative. A domain operator can now use DANE to say, "my mail server supports STARTTLS and, if yours does too, you must use it when we exchange mail." That means an attacker can't downgrade a session between two mail servers, by tricking the servers into using a non-encrypted connection. DANE therefore represents a big step towards secure e-mail, which is why we have added it to the list of modern security standards that we promote and incentivise through the RSC.
Article by:
Share this article