Extended DNS Error support for Unbound

Unbound 1.16.0 adds support for Extended DNS Errors (EDEs) as codified in RFC 8914. While EDE was already supported in NSD since version 4.3.6 released in April of 2021, as with most things in a resolver, EDE support took more time to implement.

As a short primer, EDEs are EDNS options that enrich a DNS response with an error code which tells you what the error was, and can even include human-readable text specifying what went wrong exactly.

A simple example of this is when an authoritative server is queried for a zone of which it doesn’t hold information over. Nominally, the server would respond with REFUSED and would leave the user to guess what the reason could be for this response. Now we can add an EDE code Not Authoritative in the response, alongside the nominal REFUSED, which provides the user with some more insight. We see an example of this below:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 41018
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 20 (Not Authoritative)
;; QUESTION SECTION:
;example.com.			IN	A

Another example is when a resolver is validating DNSSEC for a zone, but the DNSKEY can’t be found for this zone:

In this scenario, which can be seen in the image above, the nominal response would be a SERVFAIL which would leave a user completely clueless of what actually went wrong, as the scope of a SERVFAIL is so broad just about anything could have happened. When doing this for example.com in Unbound, you would get the EDE code DNSKEY Missing, as well as a text indication of why this query failed. The human-readable portion of the EDE will look like this:

validation failure <www.example.com. A IN>: 
no DNSKEY rrset for trust anchor example.com. while building chain of trust.

Supported EDEs in Unbound

The RFC specifies 25 possible errors, which we can cluster as roughly: DNSSEC-, filtering-, and informative errors. Of course, while we concede the point that all EDEs are by definition informative, we argue that the other categories are more specific clusters. To these, we can also add “warnings”, which are not technically errors as the status code can be NOERROR, but can be added to a query response where the answer is stale for example.

Unbound currently supports all DNSSEC validation errors, because we felt this would have the greatest impact, as well as one filtering- and some informative errors. Unbound also supports the Stale Answer EDE, as this was requested by some of our users during development.

Here is an overview of the EDEs and their error codes Unbound supports:

Configuring EDE for Unbound

EDE can be turned on by simply adding ede: yes in the config file under the server clause. EDE is disabled by default to ensure that no behaviour changes show up when upgrading to the latest Unbound version. With EDE enabled, all supported errors are reported.

If you also want the stale answers "warnings" for expired responses to have an error code, the option ede-serve-expired: yes will provide that (as long as serve-expired: yes is also configured).

Our hope is that with wide deployment of EDE the DNS offers more transparency to the user, which could even take form in browser error messages, and make the Internet more robust.