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

Security of DNS isn't be assured unless DNSSEC validation is enabled on the end user's client

AD flag should be trusted only on closed networks

Red digital padlock in a digital environment - Cyber security concept
  • Thursday 6 April 2023

The AD flag is used by (caching) DNS servers to indicate that they have validated the DNSSEC records. The idea is that the client doesn't then have to repeat the check.

Use of the AD flag is, of course, safe only on networks where the security of the 'last mile' is assured. Examples include company networks, campus networks and the closed access networks belonging to internet access providers and mobile operators. On such networks, validation and the caching of DNS records can be centralised on the recursive DNS servers.

In all other cases, we recommend performing 'end-to-end' validation extending all the way to end users' clients. An end user who wants guaranteed security from their DNS resolver should therefore install the Unbound resolver or other validating resolver software. The installation and configuration of Unbound with DNSSEC-Trigger is described in an other article on this website. Administrators of smaller networks can use dnsmasq, a combined DNS/DHCP server that also supports DNSSEC.

What is the AD flag for?

The Authentic Data (AD) flag is used by (caching) DNS servers to indicate that they have validated the DNSSEC records. The idea is that the client doesn't then have to repeat the check. In its DNS query, the (stub) resolver asks for validation (and the RRSIG records) by setting the DO flag (DNSSEC OK) – with the dig network tool, you can do that by using the '+dnssec' option. When responding with the DNS records, the DNS server can then send the AD flag as well. The DNS server is then effectively taking responsibility for both the caching and the validation.

However, when testing a validating DNS server, it's important to bear in mind that the DNSSEC specification (RFC 4035, section 3.1.6) states that authoritative name servers don't have to undertake validation for their own domains. They are then allowed to set the AD flag, but only if they have obtained their authoritative records in a secure manner. That has to be separately configured.

The role of the AD flag has since been extended: whereas it was originally exclusively for DNS responses, it can now be used in DNS queries. According to RFC 6840, section 5.7, it was previously recommended that the AD flag shouldn't be set in DNS queries. Now setting the AD flag in a DNS query yields information exclusively about the validation result (by means of the AD flag in the DNS response), and not about the RRSIG records themselves. The dig network tool now supports AD flagging with its '+adflag' option. The DO flag is still used as before to request RRSIG records.

When can you trust the AD flag?

Of course, the crypto-technical answer is 'never'! Because the pathway between the (stub) resolver and (caching) DNS server is generally not secure, the contents of a DNS response can always be modified by a man-in-the-middle (MITM)attack undetected by the client. In principle, neither the record contents nor any of the metadata (headers) can be trusted.

Although combining DNSSEC validation with DNS record caching seems like an obvious (and efficient) thing to do, it truncates the cryptographically secured DNSSEC chain. Ideally, the chain should extend all the way from the root zone (.) to the associated trust anchor on the client. Therefore, if validation is also performed on the caching DNS servers, a new technology is required for the last part of the chain to secure transmission of the AD flag.

Various solutions to that 'last mile' problem were already available:

  • DNS information exchange can be secured using TSIG (Transaction SIGnature). The TSIG protocol is often used for the exchange of DNS records between authoritative name servers, and to secure Dynamic DNS updates from the DHCP servers to the DNS server. TSIG could also be used for communication between resolver and DNS server, but is not an obvious option in that context. The protocol is based on symmetric cryptography, implying that a shared private key has to be exchanged between client and server.

  • By contrast, DNSCrypt is based on an asymmetric protocol, making it more suitable for securing the 'last mile'. DNSCrypt is used by the DNS service provider OpenDNS to encrypt traffic to and from its clients. The system is based on DNSCurve, developed by

    Daniel J. Bernstein (DJB), who has a reputation for fast and secure internet software. It was he who developed qmail, djbdns and EdDSA, for example. DNSCrypt is mainly supported by OpenDNS and is available for Windows, Linux, Mac OS X and iPhone.

  • DNSSIG is a rival to DNSCrypt. It is designed to maximise transparency by using TXT records.

  • In Secure Dynamic Update, Microsoft has developed a protocol for tunnelling DNS traffic. The system uses the GSS-API and a variant of Kerberos.

Despite all the earlier initiatives and ideas, none of the technologies outlined above ultimately became established as the solution for last-mile security. Instead, the open standards DoT, DoH and DoQ have become the normal way of protecting the transport of DNS traffic. However, those standards are relatively new and are currently used mainly at the application level (in web browsers).

Where can the AD flag be used?

The AD flag can, however, be used without any other security measures on a network where the security of the last mile is assured. Examples include company networks, campus networks and the closed access networks belonging to internet access providers and mobile operators. On such networks, DNSSEC validation and DNS caching can be centralised on the recursive DNS servers.