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

StartTLS and DANE may be made mandatory for outgoing mail as well

  • Friday 6 July 2018

The Forum for Standardisation wants to add various new standards to the 'use-or-explain' list, including StartTLS and DANE for outgoing mail.

Addition to the list would more or less oblige government and quasi-government organisations to implement the standards. In practical terms, all relevant standards on the 'use-or-explain' list have to be included in tender specifications for government contracts worth more than 50,000 euros, unless there are good reasons for their non-inclusion.

Together, TLS, StartTLS and DANE provide for a secure — i.e. cryptographically protected — connection for the transmission of e-mail messages. The three standards build on the existing DNSSEC infrastructure: RFC 7672 requires the use of DNSSEC with DANE.

Pinning TLS certificates

Many SMTP servers (MX gateways) already offer the option of enabling TLS, the same form of security as used in HTTPS for the web. Delivering mail systems can then use the StartTLS command to upgrade their TCP connections to TLS. Unfortunately, clients are not obliged to cooperate, and a man-in-the-middle can easily hide a server's StartTLS capability from a client (a 'downgrade attack'). Consequently, StartTLS is not a complete solution.

However, if the mail service's TLS certificate is pinned in a DNSSEC-secured TLSA record (on TCP port 25, by means of a hash), a client can be sure that the server in question supports TLS. The Postfix mail server (the most widely used MTA after Exim) can be configured to go through a DANE authentication procedure before delivering mail to an MX gateway.

Opportunistic protocol

The crucial difference between TLS for mail and TLS for the web (HTTPS) is that the use of 'https' in a URL implies that TLS must be used and that a dedicated TCP port (number 443) is available for the purpose. By contrast, with mail the client is not obliged to use TLS, meaning that DANE/TLS for mail is an 'opportunistic protocol'. In other words, a client that already supports DNSSEC, DANE and StartTLS has to encrypt its connections with a server that supports StartTLS and makes TLSA records available. However, if any of the support elements is missing, client and server fall back to TLS without DANE or even to insecure transmission. An opportunistic model with fallback provision was chosen to ensure that autonomous message delivery can proceed without human intervention wherever possible.

IANA did at one stage reserve a TCP port (number 465) for SMTP-over-SSL (SMTPS), but the arrangement was never standardised and the port has since been assigned to a completely different service. The sticking point is that there is no way of specifying in an e-mail address whether transmission should be secured, and a receiving mail system has no way of interacting directly with a sender, other than via a bounce. Consequently, with DANE/StartTLS the aim is to secure transmission 'wherever possible'.

REQUIRETLS

Encouragingly, efforts are being made to resolve the problem. This Internet Draft proposes the introduction of a REQUIRETLS keyword/capability and a RequireTLS mail header. The idea is that a sending system will be able to use the REQUIRETLS keyword to indicate that a message can be transmitted only via a TLS-secured connection. In other words, the security of the transmission will be prioritised over delivery of the message. Receiving servers will use the same keyword as a capability indicator to tell clients that REQUIRETLS is supported and to 'promise' that onward transmission will be exclusively via secure channels.

A message's sending host will also be able to use the RequireTLS header to indicate the importance of secure transmission. For example, the sending host could explicitly permit transmission via a non-secured connection only where no other option is available (delivery of the message thus taking precedence over the security of the transmission).

MTA Strict Transport Security

Another protocol currently under development is MTA Strict Transport Security (MTA-STS). With MTA-STS, the MX gateways for a domain and whether they require the use of StartTLS are specified in a policy file. The protocol uses a DNS TXT record to publicise the existence of the policy, but the policy itself has to be looked up using HTTPS. In other words, the existing system of CA certificates for the web is utilised for policy communication. Ultimately, the intention is to create a similar hierarchy of CAs for mail-systems.

The idea is that delivering mail systems will retain the policies for an extended period (weeks or months) and before making deliveries will check the validity of the MX gateways that they are pointed to by the DNS. To reduce the risk of an MITM attack, it will be necessary to proactively refresh your stored policies on a daily or weekly basis separately from any mail delivery. An MTA-STS configuration can be tested here.

A separate mechanism is being developed for reporting problems. Known as SMTP TLS Reporting (TLSRPT), the system can also be used for DANE. The mechanism is implemented in a similar way to the DMARC reporting mechanism.

MTA-STS is an initiative by Google in response to the slow adoption of DNSSEC, which is a prerequisite for the use of DANE. The protocol is therefore intended to work without DNSSEC, but consequently offers less security than DANE. That is because the content of the policy file is merely a copy of the MX RRset with a long TTL. Prolonged retention of the information means that MX redirect attacks and StartTLS downgrade attacks can be detected. The drawback is that MTA-STS assumes the existence of a valid policy which has previously been obtained without DNSSEC security. In other words, the trust-on-first-use principle is applied, as in the HSTS protocol. Furthermore, whereas DANE provides an anchor for a particular certificate (or chain), MTA-STS involves the creation of a new CA-based certificate system, introducing all the problems associated with the use of CA certificates on the web. However, MTA-STS deliberately avoids diminishing DANE security: if DANE is present but cannot be validated, then you cannot use an MX gateway that validates in accordance with MTA-STS.

Expert review

"In 2015, StartTLS and DANE were made mandatory only for incoming mail, because at the time there was limited market support for outgoing mail," says Han Zuidweg, Senior Advisor at Logius (which operates the Forum for Standardisation). "By contrast, there was adequate support for incoming mail."

"Testing of StartTLS and DANE for outgoing mail has recently started. We're in the process of approaching the people who were involved in the expert review in 2015. If there are others who would like to be involved (because addition to the 'use-or-explain' list will affect them, for example), there's scope for their inclusion. We expect to complete the expert consultation within a month. On 6 August, the resulting recommendation will be published for public comment, at which point anyone will be able to provide input."

Adoption

Like StartTLS and DANE for incoming mail, DNSSEC was added to the 'use-or-explain' list some time ago.

Recently, the Pan-governmental Digital Government Policy Forum (OBDO) expressed the ambition to achieve server-side StartTLS and DANE implementation for all government organisations by the end of 2019. Similar aims were previously formulated for protocols such as DNSSEC, DKIM, SPF and DMARC, but adoption has been slower than hoped. If StartTLS and DANE for outgoing mail are added to the 'use-or-explain' list, a further adoption target will be defined for those protocols.

StartTLS Everywhere

A variety of initiatives are currently being taken to promote the use of StartTLS. Here at SIDN, for example, we are in the process of extending the Registrar Scorecard to incentivise the use of StartTLS, DKIM, SPF and DMARC. That will involve making payments to registrars that enable the security standards for the .nl domain names in their portfolio.

Meanwhile, as a follow-up to the popular Let's Encrypt, the Electronic Frontier Foundation (EFF) recently launched StartTLS Everywhere. The EFF will supply a plugin for certbot that will enable the installation and maintenance of a Postfix certificate. Similar plugins are being developed for Dovecot and Sendmail.

The EFF will also maintain a list of domains that offer StartTLS in combination with a CA certificate, as with STS but centralised. In addition, the EFF portal has a tool for checking whether a mail domain uses StartTLS. A similar check can be done on the Internet.nl portal as well.