Unbound 1.16.0 adds support for Extended DNS Errors (EDEs) as codified in RFC 8914. While EDE was already supported in NLnet Labs’ Name Server Daemon (NSD) since version 4.3.6 was released in April of 2021, as with most things in a resolver, EDE support took more time to implement.
EDEs are EDNS options that enrich a DNS response with an error code that 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 over which it doesn’t hold information. 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 AAnother example is when a resolver is validating DNSSEC for a zone, but the DNSKEY can’t be found for this zone, as shown in Figure 1.
In Figure 1’s scenario, 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 that 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:
| EXTENDED DNS ERROR | ERROR CODE |
|---|---|
| Other | 0 |
| Unsupported DNSKEY Algorithm | 1 |
| Stale Answer | 3 |
| DNSSEC Indeterminate | 5 |
| DNSSEC Bogus | 6 |
| Signature Expired | 7 |
| Signature Not Yet Valid | 8 |
| DNSKEY Missing | 9 |
| RRSIGs Missing | 10 |
| No Zone Key Bit Set | 11 |
| NSEC Missing | 12 |
| Prohibited | 18 |
| Not Authoritative | 20 |
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.
Note: We advise to set val-log-level: 2 as this gives the validation EDEs more comprehensive human-readable text in the errors.
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 the wide deployment of EDE, the DNS offers more transparency to the user, which could even take the form of browser error messages, and make the Internet more robust!
Tom Carpay is a Software Engineer at NLnet Labs. His interests revolve around low-level performance engineering and enhancement.
This post is adapted from the original at NLNet Labs blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
The EXTRA-TEXT field is really the icing on the cake. It’s the moral equivalent of the 404 page in HTTP as you can populate it with pretty much anything human readable – including a URL of course.
However, I presume this is also vulnerable to abuse by amplification attacks so one must be wary of adding too much material in this field.
Nonetheless a nice touch by rfc8914.