As I understand it, a simple test for the DNSSEC is to run dig +dnssec debian.org and to look for the ad flag in the response as well as the presence of RRSIG ... when I run this from my laptop or from the router itself, I do not see the ad flag in the output.
Running on OpenWRT:
# dig +dnssec debian.org
; <<>> DiG 9.14.8 <<>> +dnssec debian.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61509
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;debian.org. IN A
;; ANSWER SECTION:
debian.org. 92 IN A 128.31.0.62
debian.org. 92 IN A 130.89.148.77
debian.org. 92 IN A 149.20.4.15
debian.org. 92 IN RRSIG A 8 2 300 20200122194100 20191213184100 38844 debian.org. L3sEnt/Ka5X99GRQXOPv3r+g9lfM6/lCn0TGGW0IKwhaWmrgnbAKLcho eEdoKbSjK6E/7hYUc//3rcUgbJoyBxz30nkG1FGDxg68WZS74QLQdXT1 D3ClU6ct1Lujn7ZDJZWM1hcKHA367KG/zs2sebVfkUf8b68b8Fh6xOO3 wiYW+qk/HFZAvsQ5eTk+hXJKB/GX6ac5u6d8+6dcSuJ3wUhYSTFmPqLN 9EJDUaWcv40jgD5gZssxm0a3m6o4nc8n
;; Query time: 40 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec 18 13:59:41 EST 2019
;; MSG SIZE rcvd: 321
But, if I define @1.1.1.1 from the OpenWRT shell, I get back the expected ad flag so I am confused since I setup 1.1.1.1 in LuCI...
# dig @1.1.1.1 +dnssec debian.org
; <<>> DiG 9.14.8 <<>> @1.1.1.1 +dnssec debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59110
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;debian.org. IN A
;; ANSWER SECTION:
debian.org. 239 IN A 128.31.0.62
debian.org. 239 IN A 130.89.148.77
debian.org. 239 IN A 149.20.4.15
debian.org. 239 IN RRSIG A 8 2 300 20200122194100 20191213184100 38844 debian.org. L3sEnt/Ka5X99GRQXOPv3r+g9lfM6/lCn0TGGW0IKwhaWmrgnbAKLcho eEdoKbSjK6E/7hYUc//3rcUgbJoyBxz30nkG1FGDxg68WZS74QLQdXT1 D3ClU6ct1Lujn7ZDJZWM1hcKHA367KG/zs2sebVfkUf8b68b8Fh6xOO3 wiYW+qk/HFZAvsQ5eTk+hXJKB/GX6ac5u6d8+6dcSuJ3wUhYSTFmPqLN 9EJDUaWcv40jgD5gZssxm0a3m6o4nc8n
;; Query time: 24 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Dec 18 14:41:28 EST 2019
;; MSG SIZE rcvd: 321
As well, my browser (linux laptop) is failing this online test as well as this one.
What needs to be enabled on OpenWRT to use DNSSEC? Note, under Interfaces>WAN I have defined two custom DNS entries, 1.1.1.1 and 1.0.0.1
Not until people stop insisting that 4 MB of flash or 32 MB of RAM is enough. Probably not until people stop insisting that 8 MB of flash and 64 MB of RAM is enough. TLS is expensive compared to sending a UDP packet to a socket.
My goal is just have DNSSEC enabled for all devices behind OpenWRT (several zones). I also have pi-hole running on a separate box. Was is the easiest way to achieve this?
This blog entry seems pretty simple whereas the guide fantom-x shared seems much more involved.
In this setup I don't get the ad flag properly (if I don't have the DNSSEC eabled on the pi-hole).
dnsmasq and any other resolver I know dropps the ad flag returned by the upstream server by default. So if unbound is checking DNSSEC, bogus entries will be given to the next resolver with NO ip and a servfail. Correct answers will be given with ad flag.
The dnsmasq than drops the ad flag by default (it can't be sure that the upstream server is trustworthy until you told him so). If you want ad flag given to your clients, then
the dnsmasq (on the pi-hole) needs to do DNSSEC or
the dnsmasq is runned with --proxy-dnssec (but this is not working correctly so far)
unbound keeps you from bogus results .. even if you don't do further dnssec validations on the dnsmasq resolvers.
Grrrr... the problem seems to be with cloudflare. When I have their DNS servers configured, I get the error I posted above but hen I switch over to quad9, everything works as expected and the dig command returns the ad flag finally. Why?
At the moment I dont see another option to have pi-hole doing the dnssec validation.
I'd like to have the OpenWrt dnsmasq to rely on the dnssec validation of the unbound ond the pi-hole to rely on the OpenWrt dnsmasq, but .. so far the caching of the ad flag is not working properly with dnsmasq with --proxy-enabled. It just doesn't cache the ad flag and is not providing it to the clients on any subsequent request that is answered from cache.
I'll try to get contact with the developers via dnsmasq mailing lit. Maybe that brings more clearness to this topic.