--- title: RFC 8914 Extended DNS Errors testbed --- This is a testbed, for testing propagation of [RFC8914 Extended DNS Errors][RFC8914] 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][RFC8914sec3]: > [...] > > 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][Response Policy Zone], 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][unbound-1191] * 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][pdns-12572] (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: - `