What's new

[Preview] Asuswrt-Merlin 384.11 with DNS over TLS

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
fyi, as tured out earlier CF performs DNSSEC on its own, no need to enable it on router.
but might be useful with other DoT servers w/o "builtin" DNSSEC
I did notice I received a lot of errors running the two together
 
With alpha 3 my iOS Dig test did not return the "ad" flag. Created dnsmasq.conf.add with proxy-dnssec and restarted dnsmasq. Now Dig gets the "ad" flag.

Request proxy-dnssec be included in the next build.
Thanks

Sent from my SM-T380 using Tapatalk
It's added if you enable DNSSEC on the router. Are you asking for it to be included even if DNSSEC is off on the router?
 
It's added if you enable DNSSEC on the router. Are you asking for it to be included even if DNSSEC is off on the router?

It turns out it is even adding the proper dnssec extension to the stubby.yml file too. Just confirmed.
 
When I use "AdGuard" (any) I get random "page not found" type messages. Everything else like Google or Cloudfare for example is Ok.

Merlin, could we please have SafeDNS added (these do DNS over TLS + Content filtering) - this seems to be closest to OpenDNS (as OpenDNS don't do safe browsing in search engines or DNSSec or DNS over TLS). Also Cleanbrowsing do DNS over TLS but their filtering does adult+malicious+ads+safe search but doesn't allow blocking of dating web sites for example.

Also I was initially confused over how the section in WAN related to the DNS Filter section. In DNS Filter, you can set providers and then exclude for certain computers. With the section in WAN, it was assumed to apply to anything. Also getting DNS automatically - shouldn't this be greyed out if the option for DNS over TLS is then chosen?
 
When I use "AdGuard" (any) I get random "page not found" type messages. Everything else like Google or Cloudfare for example is Ok.

All stubby does is point at their servers. If they randomly fail to resolve things, that's outside the scope of the router.
Merlin, could we please have SafeDNS added (these do DNS over TLS + Content filtering) - this seems to be closest to OpenDNS (as OpenDNS don't do safe browsing in search engines or DNSSec or DNS over TLS). Also Cleanbrowsing do DNS over TLS but their filtering does adult+malicious+ads+safe search but doesn't allow blocking of dating web sites for example.

I don't want to fill up the preset dropdown with 40+ presets which will have to be updated every few months as old services disappear and new one appears. I chose to go with a subset of the most popular ones - the webui is open enough for anyone to easily enter their preferred services instead.

Also I was initially confused over how the section in WAN related to the DNS Filter section. In DNS Filter, you can set providers and then exclude for certain computers. With the section in WAN, it was assumed to apply to anything.

DNSFilter is unrelated to DNS Privacy - two completely different features.

Also getting DNS automatically - shouldn't this be greyed out if the option for DNS over TLS is then chosen?

No, because until Stubby comes up, you still need the WAN servers, for example to setup the router's clock, or to act as fallback.
 
It already is... Just enable DNSSEC on the webui.



stubby.postconf will be the place to do it.
Ah rats! DNSSEC was not enabled :( When I did enable it Q9 would not resolve. Switched to CF, rebooted, works now!
Guess I need to concentrate on one thing at a time. Was also working on Windows Insider build 1903 which failed on my test PC. Back to Ubuntu...

Sent from my SM-T380 using Tapatalk
 
By my understanding, proxy-dnssec should only be included if stubby is doing the dnssec validation (dnssec in stubby.yml) or dnssec is not set in either dnsmasq or stubby (the upstream stubby server is doing the validation). If dnsmasq is doing the dnssec validation, proxy-dnssec should not be specified.
 
By my understanding, proxy-dnssec should only be included if stubby is doing the dnssec validation (dnssec in stubby.yml) or dnssec is not set in either dnsmasq or stubby (the upstream stubby server is doing the validation). If dnsmasq is doing the dnssec validation, proxy-dnssec should not be specified.

isn't "dnssec" too strict? unlike "dnssec_return_status" it'll drop all the GETDNS_DNSSEC_INTERMEDIATE replies.
 
unrelated. I've checked cf with more reliable tools like dig.
So are you on the fence does it need to be turned on or off? I notice CF does do dnssec, but the router is the only thing that can mark the AD flag on the dig and drill test.
 
isn't "dnssec" too strict? unlike "dnssec_return_status" it'll drop all the GETDNS_DNSSEC_INTERMEDIATE replies.

So i have noticed something inside the Stubby.yml file
stubby -i | grep -i dnssec
Code:
[15:57:31.853532] STUBBY: Read config from file /etc/stubby/stubby.yml
    "dnssec": GETDNS_EXTENSION_FALSE,
    "dnssec_allowed_skew": 0,
    "dnssec_return_all_statuses": GETDNS_EXTENSION_FALSE,
    "dnssec_return_full_validation_chain": GETDNS_EXTENSION_FALSE,
    "dnssec_return_only_secure": GETDNS_EXTENSION_FALSE,
    "dnssec_return_status": GETDNS_EXTENSION_TRUE,
    "dnssec_return_validation_chain": GETDNS_EXTENSION_FALSE,
    "trust_anchors_verify_email": <bindata of "dnssec@iana.org">,
with "dnssec_return_status": GETDNS_EXTENSION_TRUE

would one still want to have validate unsigned DNSSEC replies turned on inside the the GUI as well... Wouldn't that be over kill?
 
The sub-options are only active if the first plain "dnssec" option is turned on (TRUE)
that is interesting how does dig and drill test come back with the AD flag, if this is not true as far as the main Dnssec option up top.
proxy-dnssec is turned on in dnsmasq.conf and "dnssec_return_status": GETDNS_EXTENSION_TRUE is on inside stubby.yml
 
By my understanding, proxy-dnssec should only be included if stubby is doing the dnssec validation (dnssec in stubby.yml) or dnssec is not set in either dnsmasq or stubby (the upstream stubby server is doing the validation). If dnsmasq is doing the dnssec validation, proxy-dnssec should not be specified.
My guess is:
Choose one and only one:
  • DNSSEC proxy by dnsmasq set by proxy-dnssec in /etc/dnsmasq.conf
    • or
  • DNSSEC direct by dnsmasq set by Merlin GUI LAN > DHCP Server > Enable DNSSEC support
    • or
  • DNSSEC direct by stubby set by dnssec: GETDNS_EXTENSION_TRUE and dnssec_return_all_statuses: GETDNS_EXTENSION_TRUE in stubby.yml
 
My guess is:
Choose one and only one:
  • DNSSEC proxy by dnsmasq set by proxy-dnssec in /etc/dnsmasq.conf
    • or
  • DNSSEC direct by dnsmasq set by Merlin GUI LAN > DHCP Server > Enable DNSSEC support
    • or
  • DNSSEC direct by stubby set by dnssec: GETDNS_EXTENSION_TRUE and dnssec_return_all_statuses: GETDNS_EXTENSION_TRUE in stubby.yml
To me this would seem the correct approach that you listed above... but the new firmware alpha is
using DNSSEC Proxy in dnsmasq when you enable the gui on merlin----- and it is also placing dnssec_return_all_statuses: GETDNS_EXTENSION_TRUE in stubby.yml ----- this is not really giving you a choice on which approach to use.

and no where in any of this process does it turn on dnssec: GETDNS_EXTENSION_TRUE
 
that is interesting how does dig and drill test come back with the AD flag, if this is not true as far as the main Dnssec option up top.
proxy-dnssec is turned on in dnsmasq.conf and "dnssec_return_status": GETDNS_EXTENSION_TRUE is on inside stubby.yml
Is the gui dnssec option turned off?
 
no it is turned on. and once it is turned on
dnssec_return_all_statuses: GETDNS_EXTENSION_TRUE gets populated inside stubby.yml
and DNSSEC Proxy gets placed inside DNSMASQ.conf
 
So I took the high road on this one and turned all DNSSEC off in the GUI and just added
proxy-dnssec to the dnsmasq.conf.add file all dig and drill test come back proper and the Cloudflare test comes back good.
 
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top