RFC 8914 Extended DNS Errors testbed

This is a testbed, for testing propagation of RFC8914 Extended DNS Errors in the wild.

$ dig blocked.nx.ede.dn5.dk @1.1.1.1

; <<>> DiG 9.20.7-1-Debian <<>> blocked.nx.ede.dn5.dk @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28690
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 15 (Blocked): (🚧 Blocked 🚧)
;; QUESTION SECTION:
;blocked.nx.ede.dn5.dk.         IN      A

;; Query time: 15 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Sat Apr 19 16:34:11 UTC 2025
;; MSG SIZE  rcvd: 73

What does RFC 8914 say about propagation?

In RFC 8914 section 3 - Extended DNS Error Processing:

[…]

When a resolver or forwarder receives an EDE option, whether or not (and how) to pass along EDE information on to their original client is implementation dependent. Implementations MAY choose to not forward information, or they MAY choose to create a new EDE option(s) that conveys the information encoded in the received EDE. When doing so, the source of the error SHOULD be attributed in the EXTRA-TEXT field, since an EDNS0 option received by the original client will appear to have come from the resolver or forwarder sending it.

[…]

We probably need to write an update, at least changing it so that forwarders SHOULD propagate EDE’s.

draft-ietf-dnsop-structured-dns-error is currently working on changing EXTRA-TEXT to a more formal format for a few EDEs, currently this testbed uses EXTRA-TEXT for for static human readable Unicode messages for each error.

Adoption status

Adoption in DNSSEC

The DNSSEC related EDE are probably the most widely deployed EDE’s. The EDE concept also originated from the needs of the DNSSEC working-group, so it’s not that surprising.

Use with DNS filtering

While there are several EDE’s defined for use with DNS filtering, they are still lacking implementations, hence the need for this testbed.

draft-ietf-dnsop-structured-dns-error is trying to formalize EXTRA-TEXT encoding. Work is needed on integrating EDE’s with RPZ, and ensuring that DNS forwarders, like home routers, propagate EDE’s to end-user applications.

STOP pages

Traditionally DNS filtering have often hijacked the filtered domain, and sent visitors to a “STOP” page, served only over HTTP, sometimes with a HTTP status code 451 Unavailable for legal reasons. As plain HTTP is being phased out, concepts like HSTS Preload and HTTPS-by-default and end-users following https:// links, means that it is very unlikely that end-users will actually see these STOP-pages.

Adopting the DNS filtering-related EDE’s and formalising EXTRA-TEXT, could lead to end-user applications, like web-browsers, having more user-friendly error-messages, than simply Connection refused.

Improvement projects

Last updated: 2025-04-18

This is an incomplete list of improvement projects:

• Unbound: Add support for RPZ to reply with an EDE
• Ongoing, use RIPE Atlas to map EDE propagation. (Initial findings: to be presented at RIPE90 DNS-WG)
• Find / file more bugs (TODO)

Completed

• dnsdist: Add support for adding EDE codes with Lua (unfortunately, no support for EXTRA-TEXT yet)

Testbed

This testbed was setup, to help with testing EDE propagation.

Query format

The following queries are currently supported:

• <label>.nx.ede.dn5.dk - Responds with NXDOMAIN.
• <label>.cname.ede.dn5.dk - Responds with NOERROR and a CNAME record.
• <label>.addr.ede.dn5.dk - Responds with NOERROR and an A/AAAA record.

All of them responds with the EDE code assigned to the given <label>.

As an alternative, <label> can also be substituted with <code>, all currently valid values are listed in the following section.

Examples queries

• dig blocked.nx.ede.dn5.dk @1.1.1.1 (the one shown at the top of the page)
• dig prohibited.cname.ede.dn5.dk @1.1.1.1
• dig a filtered.addr.ede.dn5.dk @1.1.1.1
• dig aaaa censored.addr.ede.dn5.dk @1.1.1.1
• dig 25.nx.ede.dn5.dk @1.1.1.1

1.1.1.1 (aka. CloudFlare public DNS resolver) is used in these examples because it is currently the only public resolver, that propagates EDE’s).

List of supported error codes

These are the codes currently implemented in the testbed.

Changelog

• 2025:
  • April:
    • This page was put together.
    • CannedDNS was extended to be able to serve as authoritative DNS server for this testbed.
  • March:
    • CannedDNS was developed during DNS Hackathon 2025.
• 2023:
  • May:
    • This testbed was originally implemented at DNS Hackathon 2023, using a patched version of dnsdist.

Credits

This testbed was put together by Asbjørn Sloth Tønnesen.

See also

• IANA EDE code registry
• Response Policy Zone
• git repo for this testbed