Info: Stubby 0.2.3 (latest) is on entware.

[skeal]

Ok I got this working I think. I have my router address as my WAN DNS and I can surf. However I fail Cloudflare's test page. I have rebind on but no dnssec. I do a test at dnsleaktest.com and instead of 1 Canadian Cloudflare server I have 2.

 

[skeal]

Works!!!

I ran this:

kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com  google.com

Worked like a charm..

 

[skeal]

I spoke to soon and dnsmasq.conf.add messes it up and it stops working

no-resolv
server=127.0.0.1#5453

 

[skeal]

I can't seem to stop DNSSEC from working. I have it all off on the dhcp page and it still checks out as working.

 

[Xentrk]

That dnssec_return_status is same stuff as in Merlin LAN dnssec setting. Do not enable for quad9 or cloudflare. Also don’t use the stubby dnssec setting as stubby have problem with generating logs. So you would know what is going on. If really need to do dnssec verification, then activate via Merlin webgui.

Enable dns rebind protection got nothing to do with dnssec. It is to prevent dns rebinding Attack by filtering Private IP addresses out of DNS responses. See here

DNSSEC appears to work with Cloudfare. Update: more testing needed! I turned on DNSSEC from the WEB GUI and was unable to resolve domain names.

I see validation messages in the system log file and see Stubby created the root anchor files in /opt/var/cache/stubby folder. The caveat is the https://1.1.1.1/help page. The page will show that 1.1.1.1 is not working if you have DNSSEC enabled. This has been reported on several forums I looked at when researching.

 

[Xentrk]

I can't seem to stop DNSSEC from working. I have it all off on the dhcp page and it still checks out as working.

I believe the firmware is populating /tmp/etc/dnsmasq.conf with the DNSSEC entry depending on the DNSSEC setting in the firmware web gui. The firmware is also populating /tmp/etc/dnsmasq.conf with the no-resolv entry. So no need to add no-resolv to /jffs/configs/dnsmasq.conf.add.

@DonnyJohnny is using the method below to update /tmp/resolv.dnsmasq:

Lastly, go to web GUI, under WAN, Internet Connection, WAN DNS Setting
Set DNS to Manual.
Dns#1 : your router ip eg. 192.168.1.1
Dns#2 : leave blank

I am overriding any DNS entries created on the Web Gui WAN page by creating a file called /jffs/configs/resolv.dnsmasq. The file contents are

server=127.0.0.1

Inside /jffs/scripts/dsnmasq.postconf and /jffs/scripts/openvpn-event, I place the line

cp /jffs/configs/resolv.dnsmasq /tmp/resolv.dnsmasq

This will override the firmware updating of /tmp/resolv.dnsmasq and ensures that the value of server=127.0.0.1 is in the file. Too early to say if this is the preferable method. But the method works.

Update: I do enter 1.1.1.1 in the WAN GUI as DNS Server 1. This populates /tmp/resolv.conf with the value: nameserver 1.1.1.1

I'll test the method used by @DonnyJohnny before I publish my install script. I found bouncing an OpenVPN client causes /tmp/resolv.dnsmasq to get updated with the servers specified on the WAN DNS and the OpenVPN DNS entries 10.8.0.1 and 10.9.0.1. Doing this breaks Stubby. So that is why I also have the entry inside /jffs/scripts/openvpn-event.

 

[Xentrk]

Update on post above...

I confirmed that @DonnyJohnny's method works for me. You can put the router IP address in DNS1 field.

To confirm, I turned off DNSSEC in the web placed a comment on the line below in stubby.yml

#dnssec_return_status: GETDNS_EXTENSION_TRUE

Then, restarted stubby e.g. /opt/etc/init.d/S61stubby restart. Then, went to https://1.1.1.1/help

This method works if you do not use an OpenVPN Client on the router. If you use OpenVPN Client, you will need to use the method described above in /jffs/scripts/openvpn-event. However, replace the 127.0.0.1 entry with your router's IP address.

 

[DonnyJohnny]

DNSSEC appears to work with Cloudfare. I see validation messages in the system log file and see Stubby created the root anchor files in /opt/var/cache/stubby folder. The caveat is the https://1.1.1.1/help page. The page will show that 1.1.1.1 is not working if you have DNSSEC enabled. This has been reported on several forums I looked at when researching.

I recommend turning off DNSMASQ when first testing so you can validate using the Cloudfare help page. Once you are comfortable that it's working, enabled DNSSEC.

This could be a reason why dnssec validation don’t work on cloudflare.

https://www.cloudflare.com/dns/dnssec/ecdsa-and-dnssec/

I am not an expert. So don’t fully understand the article but know cloudflare dns is different from others.

 

[Xentrk]

https://rootcanary.org/test.html

This is with DNSSEC turned off on the Web GUI. Perhaps this parm

dnssec_return_status: GETDNS_EXTENSION_TRUE

inside stubby.yml has something to do with the green padlocks?

 

[DonnyJohnny]

https://rootcanary.org/test.html

This is with DNSSEC turned off on the Web GUI. Perhaps this parm

dnssec_return_status: GETDNS_EXTENSION_TRUE

inside stubby.yml has something to do with the green padlocks?
View attachment 14573

The extension above I think is similar to the dnssec validation in webgui before Merlin latest firmware change them to strict validation.
Meaning although they validate dnssec, not still let it pass even not fully validate. But likely you will receive a lot of insecure msg in log.

That green log, even without enable dnssec validation, it will still be the same. CF does support dnssec just that it seems different from other dns provider.

By the way, enabling the extension seems to crush my stubby after a while of testing. Maybe to do extensive logging of insecure error?

Also after enabling the extension, https://1.1.1.1/help no longer show u connected to cf and using DOT

 

[DonnyJohnny]

How to find spki pin of Cloudflare or other dns provider.

echo | openssl s_client -connect '1.1.1.1:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl  dgst -sha256 -binary | openssl enc -base64

Replace the 1.1.1.1 to other DOT providers you using like 9.9.9.9 (quad9)

Example of what is in stubby.yml

  - adress_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=

Info got from
https://blog.because-security.com/t/use-cloudflare-dns-with-tls-on-mac-os-x-gui-and-cli-way/315

 

[skeal]

Something is not right. I disabled dnssec last night. Went to bed and got up and tested to see if dnssec still worked at the many dnssec test sites. It was still working. Why??

 

[DonnyJohnny]

Something is not right. I disabled dnssec last night. Went to bed and got up and tested to see if dnssec still worked at the many dnssec test sites. It was still working. Why??

Dnssec disable doesn’t mean disable dnssec itself. It mean disable dnssec validation.
Already say it will work. CF DNS support dnssec. It is just that I think CF did something different from other dns provider like Google. Maybe not the standard way therefore the dnssec validation doesn’t work with it.
When dnssec validation is enabled, it seems not allowing the queries response to reply back due to lack of something.

By the way with dnssec disable, what is the result of https://1.1.1.1/help

 

[Xentrk]

Something is not right. I disabled dnssec last night. Went to bed and got up and tested to see if dnssec still worked at the many dnssec test sites. It was still working. Why??

I think it is for the reasons I mention in Post #109
Something I need to research some more.

 

[Xentrk]

Also, check the contents of /opt/var/cache/stubby. Looks like DNSSEC root anchor files!

root-anchors.p7s  root-anchors.xml  root.key

 

[DonnyJohnny]

@Xentrk @skeal
For your info why dnssec validation failed.
https://serverfault.com/questions/720293/dnsmasq-returns-false-bogus-result-for-dnssec-validation

 

[RMerlin]

@Xentrk @skeal
For your info why dnssec validation failed.
https://serverfault.com/questions/720293/dnsmasq-returns-false-bogus-result-for-dnssec-validation

That refers to dnsmasq 2.72, it was fixed with 2.73. Asuswrt-Merlin is on 2.80.

 

[DonnyJohnny]

That refers to dnsmasq 2.72, it was fixed with 2.73. Asuswrt-Merlin is on 2.80.

Ya I read that. But somehow cloudflare will fail dnssec validation by dnsmasq. Seems to be due to use of different algorithms.

Don’t know.. Scratching head. Haha.

 

[RMerlin]

Ya I read that. But somehow cloudflare will fail dnssec validation by dnsmasq. Seems to be due to use of different algorithms.

It works for some and fails for others. My guess is that some of Cloudflare's distributed servers might be misconfigured possibly.

 

[blueshark]

something a cant understand

with John fork stubby work perfectly but, with Merlin Firm and this config it’s not working!!?