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.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
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.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.
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
server=127.0.0.1
cp /jffs/configs/resolv.dnsmasq /tmp/resolv.dnsmasq
#dnssec_return_status: GETDNS_EXTENSION_TRUE
This could be a reason why dnssec validation don’t work on cloudflare.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.
The extension above I think is similar to the dnssec validation in webgui before Merlin latest firmware change them to strict validation.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
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
- adress_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
tls_pubkey_pinset:
- digest: "sha256"
value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
Dnssec disable doesn’t mean disable dnssec itself. It mean disable dnssec validation.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??
@Xentrk @skeal
For your info why dnssec validation failed.
https://serverfault.com/questions/720293/dnsmasq-returns-false-bogus-result-for-dnssec-validation
Ya I read that. But somehow cloudflare will fail dnssec validation by dnsmasq. Seems to be due to use of different algorithms.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.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!