What explains the behaviour I'm seeing here? Pi-hole's query log shows that it has received a BOGUS response from Unbound. Yet if I query Unbound directly it works fine. In otherwords, testing the assertion that Pi-hole is not 'resolving' ED448 cannot be tested by simply querying the DNSSEC-enabled recursive DNS server with a simple dig A
.
The Verisign Labs tester reports that the domain is correctly configured, so the only reason I would expect to see a BOGUS response would be if Unbound is not supporting ED448 out the box, which it apparently doesn't (ref earlier source code).
I see exactly the same results if I use Cloudflare (which is DNSSEC-enabled) in Pi-hole and dig.
Requesting from Cloudflare directly, no problem:
pi@pihole:~ $ dig ed448.no @1.1.1.1
; <<>> DiG 9.16.33-Debian <<>> ed448.no @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29187
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 1 (Unsupported DNSKEY Algorithm): (for DNSKEY ed448.no., id = 61468)
;; QUESTION SECTION:
;ed448.no. IN A
;; ANSWER SECTION:
ed448.no. 3600 IN A 194.63.248.47
;; Query time: 76 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Nov 03 00:16:48 GMT 2022
;; MSG SIZE rcvd: 91
Requesting from Pi-hole with DNSSEC enabled and with Cloudflare set as upstream, fails as BOGUS:
pi@pihole:~ $ dig ed448.no @127.0.0.1
; <<>> DiG 9.16.33-Debian <<>> ed448.no @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38535
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 1 (Unsupported DNSKEY Algorithm): (for DNSKEY ed448.no., id = 61468)
;; QUESTION SECTION:
;ed448.no. IN A
;; Query time: 68 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Nov 03 00:17:33 GMT 2022
;; MSG SIZE rcvd: 75
Requesting from Pi-hole with DNSSEC disabled and with Cloudflare set as upstream, no problem:
pi@pihole:~ $ dig ed448.no @127.0.0.1
; <<>> DiG 9.16.33-Debian <<>> ed448.no @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61377
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 1 (Unsupported DNSKEY Algorithm): (for DNSKEY ed448.no., id = 61468)
;; QUESTION SECTION:
;ed448.no. IN A
;; ANSWER SECTION:
ed448.no. 3600 IN A 194.63.248.47
;; Query time: 20 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Nov 03 00:21:49 GMT 2022
;; MSG SIZE rcvd: 91
My interpretation is that just because a DNS server is DNSSEC-enabled, it still requires the requesting party to process the relevant validation. Using dig domain @dnsserver
to query Unbound won't do that, and since the domain is correctly configured with ED448, the conclusion is that Unbound, or the other upstream servers tested, are unable to process ED448.
The tester at https://rootcanary.org/test.html says that Cloudflare 1.1.1.1 is not supporting ED448, and neither is a stock apt install of Unbound.