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

DNS over HTTPS conquers the browser world

"Internet providers need to make DoH available to their customers"

Red digital padlock in a digital environment - Cyber security concept
  • Tuesday 18 May 2021

In the space of a few years, the popularity of DNS over HTTPS (DoH) has grown considerably – especially compared with the very slow take-up of many older standards, such as DNSSEC and IPv6. DoH's popularity owes much to its adoption and promotion by big players such as Mozilla, Google (Public DNS), Microsoft, Quad9 and Cloudflare (1.1.1.1).

We regard DoH as a valuable supplement to DNSSEC, but there are people who are quite reasonably concerned about Big Tech's data appetite and the implications for privacy. We prefer to make a distinction between DoH as a technology and the corporates that have embraced it, and to flag up the privacy implications of using those companies' DNS services. We do therefore recommend using DoH (if you don't run your own local validating recursive resolver), but at the operating system level, and if possible configured to work with your own access provider's DoH server.

DNS over HTTPS

As its name suggests, the DoH protocol (standardised in RFC 8484) involves the client establishing an encrypted HTTPS connection to the recursive resolver, which is then used for the exchange of DNS queries and responses.

DoH has two key benefits. First, it protects the confidentiality of the DNS exchange. In that sense, DoH complements DNSSEC, which assures only the authenticity and integrity of DNS records. Second, DoH protects the 'last mile' of the DNSSEC pathway: the final link in the DNS chain, from the client to the recursive resolver. The point being that, conventionally, clients have only a stub resolver on board, which can send DNS queries to a recursive resolver but can't perform DNSSEC validation on the DNS responses. Instead of validating the responses, the stub resolver relies on the AD flag that a validating resolver includes in the DNS response to the client. Although DoH doesn't prevent a validating resolver itself falsifying the DNS records it sends to the end user, it does at least ensure that responses can't be tampered with en route from resolver to client.

DoH isn't a replacement for DNSSEC

It's important to recognise, however, that DoH isn't a replacement for DNSSEC. RFC 8484 is concerned exclusively with use cases where DoH is deployed for communication between an end user and a caching resolver, either at the operating system level (by the stub resolver) or at the application level (by the web browser). The caching resolver may be operated by an internet access provider (if you go with your modem's default settings), or by a DNS service provider, such as Google Public DNS, 1.1.1.1 and Quad9 (if configured). However, even if DoH were one day used for all DNS connections, DNSSEC would still be needed at all points where a DoH connection terminates. First and foremost, that means on the end user's client, which (cryptographically speaking) cannot rely on the AD flag set by the caching resolver. We therefore favour enabling DNSSEC validation on the end user's machine. Of course, deployment at the terminal points also means on the caching resolver itself, where it's always necessary to validate records before they are returned to end users in the form of DNS responses. Fortunately, such validation is increasingly commonplace [1, 2]. DNSSEC should also be enabled on the authoritative name servers, whose clients need to be sure of the authenticity of the published data, implying that the data must be signed. Here in the .nl zone, a high proportion of authoritative name servers do support DNSSEC, but the international picture is far from rosy.

Growing importance of DNSSEC

DNSSEC signing on authoritative name servers, regardless of whether DoH is used, is particularly important where cloud-based systems are involved. In order to ensure that our authoritative servers are reachable from anywhere in the world, we generally make use of peering agreements with reliable partners ('peers') in the internet infrastructure world. However, we are also looking at the possibility of running authoritative name servers for the .nl zone on relatively cheap virtual machines operated by commercial service providers. With such a set-up, it is of course vital that the DNS information is always reliable, regardless of any security issues a service provider may have. That is the case if the zone is fully signed with DNSSEC (assuming that the users do perform validation). For efficiency reasons, the NSEC3 records for unsigned domains in the .nl zone are not currently signed by us. We would therefore need to sign those records in order to achieve comprehensive support. We have no concrete plans to do so, but we do envisage signing the records in due course, in combination with a rollover to the ECDSA encryption protocol (DNSSEC algorithm number 13).

Independent resolving and validation

Resolving – translating domain names into IP addresses – has traditionally been handled by the operating system. That implies installing a fully fledged validating resolver on your computer (rather than relying on the stub resolver), so that your own system can take full control of DNSSEC's cryptographic security. We can strongly recommend using NLnet Labs' Unbound software for that purpose. Unbound is now included as standard in many Linux and BSD distributions. From version 1.12, Unbound also supports downstream DoH – in other words for people who use Unbound as a (central) caching resolver. BIND named features similar support from version 9.17.10. PowerDNS supports DoH as part of the dnsdist load balancer. As indicated earlier, support for upstream DoH – from a recursive resolver to an authoritative name server – is not covered by RFC 8484. That would require the authoritative name server to offer DoH, which would have major implications for top-level domain operators. Instead of the current situation, where most DNS traffic makes use of the efficient UDP protocol, DoH support would imply a TCP connection for every querying resolver. Given that SIDN currently handles roughly three billion queries a day for the .nl zone, submitted by 1.5 million unique resolvers, the resources needed to support DoH would be huge. In that context, we have greater expectations of DNS over QUIC (part of HTTP/3), which involves HTTPS transport over UDP.

DoH in Firefox

So, although a stub resolver can perfectly well enable DoH at the operating system level, DoH is usually enabled at the application level. DoH was the focus of a lot of attention in 2019, when Mozilla announced that, for US users, the Firefox browser would be configured to use Cloudflare's DoH servers by default. The only exceptions to the default setting [1, 2] envisaged were computers set up to use a parental control/filtered service or a local DNS service, and those on which a 'split horizon' configuration was detected. Unsurprisingly, elements of the internet community were highly critical of Mozilla's decision, including British access providers and Bert Hubert (founder of PowerDNS). Their main objections were the fact that the plans would prevent filtering (a legally required option in the UK) and referral, the centralisation of DNS services, the privacy implications, and the scope for censorship. Hubert even argued that DoH would do nothing for security, and would compromise privacy by centralising DNS services in the hands of US providers. The Electronic Frontier Foundation (EFF) acknowledged those drawbacks, but spoke up in favour of DoH. The EFF called for centralisation to be mitigated by access providers making DoH services available to their customers. The idea being to reap the security benefits of DoH, while retaining the decentral recursion/validation infrastructure.

DoH in Chrome

In 2020, Google announced plans to introduce support for DoH (which they call 'Secure DNS') in their Chrome browser. In Chrome, users can choose between Google's own Public DNS service and five other services. If Chrome detects that the user's DNS service provider supports DoH, it automatically enables the protocol [1, 2, 3]. In response to the adverse comment, Mozilla has since added support for a second DoH service provider (NextDNS) to Firefox.

Marco Davids
Marco Davids, Research Engineer at SIDN Labs

Marco Davids, Research Engineer at SIDN Labs, takes a similar view to that of the EFF: "I think we need to distinguish between DoH as a technology and the interests of the Big Tech companies. DoH was thought up by the technical people at Mozilla, who insist that sound arrangements have been made with Cloudflare regarding its position as Trusted Recursive Resolver (TRR) [1, 2, 3, 4]. Nevertheless, it's good that Firefox now offers a choice for anyone who doesn't feel comfortable about Cloudflare. I like the approach Google has taken with Chrome as well. People have suggested that Google has a commercial interest in DNS data. That may be so, but that issue isn't specific to DoH. It's relevant to Google's traditional DNS service as well."

DoH support by internet access providers

"You can see the introduction of multi-service support as a win for the internet community," continues Davids. "Maybe the rethink at Mozilla wouldn't have happened without the intervention of people like Bert Hubert. Google's implementation of DoH looks like a good solution. But we haven't yet got what Bert and the EFF were calling for: internet access providers need to make DoH available to their customers." As far as we're aware, Freedom, XS4ALL and ZeelandNet/Deltanet are the only Dutch access providers to enable DoH for their customers. However, SIDN Labs also operates a (publicly accessible) experimental DoH resolver (this service stopped at the end of December 2021). Anyone looking for a public DoH service in the Netherlands or elsewhere may find the following lists useful:

If you enable DoH at the operating system level – the most appropriate level, in our view – there is no need to separately enable DoH in your browser. In fact, if you have enabled operating system support, you should disable DoH in your browser, both in order to prevent DNS traffic leaking out to destinations other than those configured in your operating system, and in order to prevent the circumvention of DNSSEC validation (typically by Unbound) or filtering (e.g. by Pi-hole).