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

Extended DNS Errors used in DNS software and services

Modern, standardised function call for user applications still needed

Red warning symbol in a digital environment
  • Friday 13 June 2025

The Extended DNS Errors (EDE) introduced by RFC 8914 seem to be a useful addition to the DNS protocol – not only for the primary purpose of error detection and diagnosis (tooling), but also now as a basis for a more sophisticated protocol for resolvers to report errors to authoritative name servers (RFC 9567).

However, there’s still a need for a new or extended function call to enable (stub) resolvers to relay EDE error codes to user applications that send them queries.

RFC 8914 defines a long list of ‘Extended DNS Errors’ (EDE). In total, there are 24 error codes/messages, of which nearly half relate to DNSSEC. The RFC also provides scope for the list to be extended further in the future by the addition of new error codes. At the moment, that can be done on a first-come, first-served basis without too much difficulty.

Table 1: EDE error codes

Code

Code

0

Other

13

Cached Error

1

Unsupported DNSKEY Algorithm

14

Not Ready

2

Unsupported DS Digest Type

15

Blocked

3

Stale Answer

16

Censored

4

Forged Answer

17

Filtered

5

DNSSEC Indeterminate

18

Prohibited

6

DNSSEC Bogus

19

Stale NXDOMAIN Answer

7

Signature Expired

20

Not Authoritative

8

Signature Not Yet Valid

21

Not Supported

9

DNSKEY Missing

22

No Reachable Authority

10

RRSIGs Missing

23

Network Error

11

No Zone Key Bit Set

24

Invalid Data

12

NSEC Missing

Automated error reporting

The formalised error messages have 2 obvious uses. First, as a framework for automated error reporting by resolvers to authoritative name servers. To that end, RFC 9567 defines an extension to the existing DNS protocol on queries and responses. That extension enables name servers to specify an ‘agent domain’ in their responses, to which resolvers can then report problems by means of special queries.

Because this portal is not secured by any form of authentication, the idea is that an agent should be able to deduce the existence of problems by the statistical analysis of inbound reports. For the first time, therefore, it’s now possible for resolvers to automatically report name server problems to the relevant operators. We discussed this mechanism at more length in a previous article.

Limited support

As far as we’re aware, Unbound is currently the only resolver that’s able to report errors to name servers as provided for in RFC 9567. From version 1.23 (April 2025), you can enable reporting with this option setting:

dns-error-reporting: yes

The BIND named resolver doesn’t (yet) support this functionality, but the complementary element of RFC 9567 is already available in the authoritative name server. From version 9.21.3, you can specify a ‘Report-Channel’ agent in your responses as described here:

send-report-channel <agent domain>

Inbound error messages can also be recorded in the logs using this option setting for the (authoritative) agent domain:

log-report-channel yes

User applications

The second use of the formalised error messages is at least as valuable and is the primary usage scenario for EDE, according to RFC 8914. Until now, a (stub) resolver has been able to merely tell a user application that a fault has occurred, if it is unable to resolve or validate a domain name (usually by means of a SERVFAIL RCODE). That is reflected in the simplicity of the POSIX function getaddrinfo(), for example.

The BIND/BSD/glibc function ‘res_query()’ and the old glibc function ‘gethostbyname()’ [FreeBSD] are able to communicate a little more information, but their error codes remain limited and aren’t mutually consistent or consistent with the RCODE response codes defined in RFC 1035 and later extensions to the DNS protocol.

For an application builder who wants to do more – which is extremely useful when DNSSEC is in use – the only option is to use the resolver of one of the popular DNS packages or a DNS service that passes on EDE codes to its clients. Moreover, the resolver has to be used in combination with a (stub) resolver/library that is capable of communicating the EDE codes via the API/call to the querying application.

EDE could then also be used to tell the end user why DNS responses are blocked, filtered, censored or forbidden. An extension to EDE intended to support such use is currently under development [1, 2, 3].

DNS software

We’ll start with the most popular DNS packages. As you can see below, most packages have implemented EDE in the last few years. However, no package (yet) supports all the codes. The reason being that errors can occur in a variety of locations, implying that additional program code for error detection and propagation would need to be added at numerous locations throughout the software.

From the release notes, it’s also apparent that, in many cases, the initial implementation has been followed by the subsequent addition of further error codes. See, for example, the list for BIND9.

DNS service providers

Like the popular DNS packages, the main DNS service providers now support EDE error codes [Cloudflare 1.1.1.1, Google Public DNS]. Again like the DNS packages, the support isn’t yet complete, but is gradually being extended [Cloudflare 1.1.1.1].

A promising extension

In 2023, a team at the Université Grenoble-Alpes investigated the implementation and utility of EDE. First, the researchers evaluated how 4 widely used DNS packages and 3 major DNS service providers dealt with a large number of domain names that the researchers themselves had deliberately configured with certain errors. They found that, in 94 per cent of cases, the resolvers generated different EDE messages.

The initial evaluation found the implementation by Cloudflare 1.1.1.1 to be the best. Next, therefore, that service was used to test the resolution of more than 300 million domain names. Of those names, nearly 18 million (6 per cent) were found to trigger EDE errors, with broken delegations and DNSSEC validation failures being the most common problems.

The researchers concluded that EDE is a promising extension for the detection and diagnosis of DNS errors. Most of the inconsistencies in the returned error codes were issues of detail only, but nevertheless warranted the attention of DNS software developers and DNS service providers. The full publication is available at hal.science.

DNS libraries

The EDE error codes relayed to the client by the (caching) DNS resolvers, the DNS services and the authoritative name servers are now at least recorded in the logs of the (stub) resolvers. Depending on the type of software, the information should really be communicated to the user application as well, via the supporting API. That does of course require that the EDE reports come back to the application programmer when the function call is made to establish a network connection. However, as indicated above, that doesn’t (yet) happen. Not even libunbound passes on the EDE error codes (the most obvious way of doing that would be to extend the ‘ub_result’ struct that returns the ‘ub_resolve()’ and ‘ub_resolve_async()’ functions).

The only libraries that we know currently support native EDE error codes are ldns (from version 1.8.2, via the ‘ldns_edns_ede_get_code()’ and ‘ldns_edns_ede_get_text()’ functions) and Net::DNS (a Perl library). The resolution functions of the getdns library (developed by NLnet Labs, like Unbound, ldns and Net::DNS) don’t yet support EDE. Nor does the ‘getdns_query’ command-line tool or the ‘stubby’ stub resolver (both based on the getdns library). BIND’s ‘dig’ tool is able to display EDE information to the user, however.

User applications

Because of all the resolution requests they generate, web browsers look like a good place to start showing EDE error messages to end users [feature requests for Chrome and Vivaldi]. After all, they already do that when TLS-related problems arise. For portability reasons, browsers generally use the operating system’s (stub) resolver via the ‘getaddrinfo()’ function. However, they also have their own address resolution implementations for their DoT/DoH/DoQ functionality.

To sum up, EDE provides a good basis for the detection and diagnosis of DNS problems. Furthermore, the error messages have now been implemented in the most popular DNS packages and major DNS services. However, the one thing that’s still needed is a modern, standardised function call to enable (stub) resolvers to also relay EDE error codes to user applications that send them queries.

Related articles