What to do to get DNSSEC working on 19.07.0-rc2

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

I found this guide the best.

1 Like

I would think OpenWRT would have support for DNSSEC in the default image, no?

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.

dnsmasq-full is required for DNSSEC support if you do not want to use something alongside (stubby, unbound).

All the guides I saw require stubby and dnsmasq-full: are you saying that dnsmaq-full is enough on tis own?

According to the wiki, personally I am always running either stubby or unbound with dnsmasq.

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.

Just to be clear, are you trying to get DNSSEC to work, or DoH?

This is his DNSSEC tutorial: https://candrews.integralblue.com/2018/08/dnssec-on-openwrt-18-06/

1 Like

Just DNSSEC. I will check out that tutorial, thanks lleachii.

If you install dnsmasq-full then DNSSEC options become available in LuCI.

Is the domain's authoritative DNS server DNSSEC enabled?

1 Like

Yes, "authoritative" is checked. I rebooted the OpenWRT router... now I am seeing the expected result:

# dig +dnssec debian.org

; <<>> DiG 9.14.8 <<>> +dnssec debian.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15377
;; 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.		238	IN	A	130.89.148.77
debian.org.		238	IN	A	149.20.4.15
debian.org.		238	IN	A	128.31.0.62
debian.org.		238	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: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec 18 20:53:35 EST 2019
;; MSG SIZE  rcvd: 321

However, when I run the same command from a client behind the router, the ad flag is missing.

Here is OpenWRT's /etc/config/dhcp

# cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'
        option dnssec '1'
        option dnsseccheckunsigned '1'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	list dhcp_option '6,172.17.1.250'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config dhcp 'guest'
	option start '100'
	option leasetime '12h'
	option limit '150'
	option interface 'guest'
	list dhcp_option '6,172.17.1.250'

Note that 172.17.1.250 is a pi-hole device, but if I run dig bypassing it, I still do now see the ad flag :confused:

  dig @172.17.1.1 +dnssec twitter.com

; <<>> DiG 9.14.8 <<>> @172.17.1.1 +dnssec twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54709
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;twitter.com.			IN	A

;; ANSWER SECTION:
twitter.com.		1386	IN	A	104.244.42.129
twitter.com.		1386	IN	A	104.244.42.1

;; Query time: 72 msec
;; SERVER: 172.17.1.1#53(172.17.1.1)
;; WHEN: Wed Dec 18 20:57:45 EST 2019
;; MSG SIZE  rcvd: 72

I have a similar setup: OpenWrt router with unbound as upstream (on the router) with qname-minimization. And a pi-hole afterwards going to the router.

(Internet) -> unbound (qname-min & DNSSEC) -> OpenWrt (dnsmasq + DHCP) -> pi-hole (dnsmasq + ad blocking) -> clients

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.

I would be fine letting pihole do that but for some reason, if I check "Use DNSSEC" within pihole's configuration, dig on my laptop does not work.

% dig +dnssec debian.org
;; Truncated, retrying in TCP mode.
;; Connection to 172.17.1.250#53(172.17.1.250) for debian.org failed: connection refused.

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?

% dig +dnssec debian.org

; <<>> DiG 9.14.8 <<>> +dnssec debian.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34867
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
...

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.

For other readers, the link above is what I did to get DNSSEC working.

# opkg update
# opkg install dnsmasq-full --download-only && opkg remove dnsmasq odhcpd-ipv6only && opkg install dnsmasq-full --cache . && rm *.ipk

Edit /etc/config/dhcp and under the config dnsmasq section, added:

  • option dnssec '1'
  • option dnsseccheckunsigned '1'
# /etc/init.d/dnsmasq restart

Further, I edited the DNS server for WAN and defined quad9's two entries there.

My pi-hole box has "DNSSEC enabled" checked and the sole entry for DNS in pi-hole is the router.

Now my browser passes both DNSSEC tests I linked in my first post and my dig command shows the ad flag.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.