DNSSEC Test Fails

[nova]

Expected Behaviour:

Pass DNSSEC tests @ dnssec.vs.uni-due.de and www.dnssec-tools.org and fail to load www.dnssec-failed.org with Google DNS or with dnscrypt & opennic sources

Actual Behaviour:

Everything was working fine when I was running pihole on centos 7 on my pi2. Had some unrelated issues plus non stop kernel panics on centos 7 so decided to switch to raspbian. I haven't been able to get the DNSSEC to work since switching to raspbian even with a clean install.

DNSSEC website tests fail @ dnssec.vs.uni-due.de but works @ www.dnssec-tools.org. www.dnssec-failed.org also loads when it shouldn't be.

Tailing the logs, it looks like it is working which I assume would be the most accurate, but I'm unsure. Also appears to be fine when I dig the domains as well.

May 15 22:11:05 dnsmasq[6158]: 1258 192.168.1.123/58243 validation 7cf7-sigfail.verteiltesysteme.net is BOGUS
May 15 22:11:12 dnsmasq[6158]: 1261 192.168.1.123/61156 query[A] sigfail.verteiltesysteme.net from 192.168.1.123
May 15 22:11:12 dnsmasq[6158]: 1261 192.168.1.123/61156 forwarded sigfail.verteiltesysteme.net to 8.8.8.8
May 15 22:11:12 dnsmasq[6158]: 1261 192.168.1.123/61156 validation sigfail.verteiltesysteme.net is BOGUS
May 15 22:12:18 dnsmasq[6158]: 1262 192.168.1.123/61159 query[A] sigfail.verteiltesysteme.net from 192.168.1.123
May 15 22:12:18 dnsmasq[6158]: 1262 192.168.1.123/61159 forwarded sigfail.verteiltesysteme.net to 127.0.0.1
May 15 22:12:18 dnsmasq[6158]: 1262 192.168.1.123/61159 forwarded sigfail.verteiltesysteme.net to 8.8.4.4
May 15 22:12:18 dnsmasq[6158]: 1262 192.168.1.123/61159 forwarded sigfail.verteiltesysteme.net to 8.8.8.8
May 15 22:12:19 dnsmasq[6158]: 1262 192.168.1.123/61159 validation sigfail.verteiltesysteme.net is BOGUS

May 15 22:12:50 dnsmasq[6158]: 1265 192.168.1.123/52177 query[A] www.dnssec-tools.org from 192.168.1.123
May 15 22:12:50 dnsmasq[6158]: 1265 192.168.1.123/52177 forwarded www.dnssec-tools.org to 127.0.0.1
May 15 22:12:50 dnsmasq[6158]: 1265 192.168.1.123/52177 forwarded www.dnssec-tools.org to 8.8.4.4
May 15 22:12:50 dnsmasq[6158]: 1265 192.168.1.123/52177 forwarded www.dnssec-tools.org to 8.8.8.8
May 15 22:12:51 dnsmasq[6158]: * 192.168.1.123/52177 dnssec-query[DNSKEY] dnssec-tools.org to 8.8.4.4
May 15 22:12:51 dnsmasq[6158]: * 192.168.1.123/52177 reply dnssec-tools.org is DNSKEY keytag 34816, algo 5
May 15 22:12:51 dnsmasq[6158]: * 192.168.1.123/52177 reply dnssec-tools.org is DNSKEY keytag 19221, algo 5
May 15 22:12:51 dnsmasq[6158]: * 192.168.1.123/52177 reply dnssec-tools.org is DNSKEY keytag 3147, algo 5
May 15 22:12:51 dnsmasq[6158]: 1265 192.168.1.123/52177 validation result is SECURE


dig sigfail.verteiltesysteme.net

; <<>> DiG 9.10.3-P4-Raspbian <<>> sigfail.verteiltesysteme.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 564
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.  IN      A

;; Query time: 236 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 15 22:23:10 EDT 2018
;; MSG SIZE  rcvd: 57

dig sigok.verteiltesysteme.net

; <<>> DiG 9.10.3-P4-Raspbian <<>> sigok.verteiltesysteme.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5319
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sigok.verteiltesysteme.net.    IN      A

;; ANSWER SECTION:
sigok.verteiltesysteme.net. 30  IN      A       134.91.78.139

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 15 22:23:22 EDT 2018
;; MSG SIZE  rcvd: 71

Debug Token:

ypll6difrp

[jpgpi250]

I just had a conversation with @DL6ER about DNSSEC, after finding this website, that allows you to run some test. On the right side of the page, there is a box ‘further connection testing’ with the ‘DNSSEC resolver algorithm test’.

Running the test, with dnsmasq as the DNSSEC evaluator gives this result:

If you run your system with only dnsmasq (or FTLDNS), so no unbound, dnscrypt-proxy or stubby, you should at least get this result, otherwise you're using resolvers that handle DNSSEC incorrect.

It turns out, implementing this unbound solution, and having the DNSSEC evaluation performed by unbound, delivers a far better (more green) result. This implies you need to turn off the DNSSEC evaluation for dnsmasq, using settings.
Of course, you no longer have DNSSEC information in the pihole query page.

DL6ER has indicated future versions of pihole, when using unbound+DNSSEC and FTLDNS without DNSSEC will show SERVFAIL on the query page.

Further more, there is a bug (dnsmasq does check unsigned replies even without that flag set) in the dnsmasq versions 2.77 .. 2.79 (also in FTLDNS - uses 2.79) that causes dnsmasq to ignore an unsigned (and thus BAD) DNSSEC record. This wan't be solved until dnsmasq2.80 is released (and FTLDNS has adopted this version. This bug causes evaluations to be SECURE, where they should in fact fail.

[gecko]

Here are my results for pihole+stubby

[mibere]

My setup: Pi-hole (FTLDNS) -> dnscrypt-proxy -> dnscrypt.me

with enabled DNSSEC in Pi-hole: same as in screenshot by jpgpi250
with disabled DNSSEC in Pi-hole: same as in screenshot by gecko

[DL6ER]

For the sake of completeness, I will add the result of unbound + Pi-hole (as described in our official guide) here as well:

Note that RSA-MD5 is considered highly insecure and is marked as "must not implement" in RFC 6944.

[nova]

Very interesting...good to know. Thanks jpgpi250.

My initial issue with the DNSSEC website tests seems to have disappeared after a few days. However I did also re-install Pi-hole and switch to the FTLDNS branch but I didn't check beforehand to see if it fixed itself so can't say for sure what resolved my initial issue.

Just to add, here's what I currently have now with Pi-hole w/ FTLDNS + dnscrypt-proxy using Cloudfare.