[Preview] Asuswrt-Merlin 384.11 with DNS over TLS

[skeal]

As for proxy-dnssec in dnsmasq.conf, use it or not. Makes no difference to stubby dnssec validation. I feel it is good to have there as web browsers begin to use dnssec validation.

Agreed, we found that the get extensions true in the .yml takes precedence in the Stubby trials.

 

[dave14305]

Still trying to get an answer why this entry is in stubby.yml: resolvconf: "/tmp/resolv.conf"

This tells stubby where to resolve names for the initial startup and setup of the TLS resolvers. I think of it similar to how many people add "server=/pool.ntp.org/1.1.1.1/" to dnsmasq.conf so that ntp can sync before everything is up and running fully. /tmp/resolv.conf will always point to your WAN DNS servers, which is why I think it's a bad idea to set WAN DNS to your router LAN IP nowadays.

 

[scjr]

Question for the experts.

I’m using DoT now through Cloudflare, which I chose under ‘Preset servers’. I also chose DNSFilter ‘Router mode’ to force clients to use Cloudflare. Everything seems to be running well. The DNS leak test site seems good. See pic below.

Why do my ISP’s DNS resolvers still show under Network Map/Internet status?

Go easy.. rookie here, with limited network knowledge.

 

[dave14305]

LAN Page
9. DNS Server 1 set to match 8

By doing this you are having all your clients bypass the router DNS server and go right to quad 9 (non-TLS). For DNSFilter router mode to truly force clients to use the router's dnsmasq/stubby, LAN DHCP DNS 1 needs to be blank.
So we need to figure out why you're having a hard time in that setup.

 

[dave14305]

Why do my ISP’s DNS resolvers still show under Network Map/Internet status?

That area is not Stubby-aware and reflects the values of the WAN DNS 1 and 2 servers. If you are still set to Connect automatically... then it will be your ISP DNS servers shown there. Sounds like you're good to go!

 

[scjr]

That area is not Stubby-aware and reflects the values of the WAN DNS 1 and 2 servers. If you are still set to Connect automatically... then it will be your ISP DNS servers shown there. Sounds like you're good to go!

Thanks, Dave.

Should I change ‘Connect to DNS Server automatically’ to No and leave it blank or that doesn’t matter?

 

[bluepoint]

This tells stubby where to resolve names for the initial startup and setup of the TLS resolvers. I think of it similar to how many people add "server=/pool.ntp.org/1.1.1.1/" to dnsmasq.conf so that ntp can sync before everything is up and running fully. /tmp/resolv.conf will always point to your WAN DNS servers, which is why I think it's a bad idea to set WAN DNS to your router LAN IP nowadays.

This is also my understanding. The initial DNS lookup for NTP comes from the WAN DNS until DOT is started. Once DOT is up, the server takes over.

 

[dave14305]

Thanks, Dave.

Should I change ‘Connect to DNS Server automatically’ to No and leave it blank or that doesn’t matter?

It's best to leave it as-is, or at least with valid DNS servers. You could make it 1.1.1.1 and 1.0.0.1 if you truly wanted only Cloudflare to receive your DNS queries, but there are very limited scenarios where the WAN DNS servers come into play. (i.e. only during startup or only if the new setting for "Wan: Use local caching DNS server as system resolver" is set to No, and even then, only for the router's own dns queries).

 

[Swistheater]

So here is my issue I have configured stubby.postconf to use a cat command to override the existing stubby.yml with a custom stubby.yml. So far the only difference in mine from the original is that I added some other servers, but durring reboot it takes alonger for connection to be restored. Is there a more graceful way of doing this?

 

[scjr]

It's best to leave it as-is, or at least with valid DNS servers. You could make it 1.1.1.1 and 1.0.0.1 if you truly wanted only Cloudflare to receive your DNS queries, but there are very limited scenarios where the WAN DNS servers come into play. (i.e. only during startup or only if the new setting for "Wan: Use local caching DNS server as system resolver" is set to No, and even then, only for the router's own dns queries).

Will leave as you recommend.

Thank you so much, Dave. Really appreciate your expertise!

 

[dave14305]

So here is my issue I have configured stubby.postconf to use a cat command to override the existing stubby.yml with a custom stubby.yml. So far the only difference in mine from the original is that I added some other servers, but durring reboot it takes alonger for connection to be restored. Is there a more graceful way of doing this?

Put your complete custom config file as /jffs/configs/stubby.yml and the firmware will use it instead of the generated one. Most people are only really aware of the "add" and "postconf" scripts, but the custom config (wholesale replacement) is also an option.

https://github.com/RMerl/asuswrt-merlin/wiki/Custom-config-files

 

[bluepoint]

in reality they should setup the three option system -like john's fork
one where you can choose the server to do dnssec and pass the cached data to router- proxy-dnssec
or
allow the router to use DNSMASQ to do dnssec
or
getdns through stubby.yml - using the dnssec extensions

What about servers that not only support DNSSEC but validates DNSSEC on its own? In Merlin's DOT, if I use Cloudflares servers and DNSSEC disabled, DNSSEC protection works but if I use Quad 9(9.9.9.9) which does not validate/protect on it's own the test site below shows I'm not protected with DNSSEC. So it seems we can only use enable DNSSEC from the GUI if the server doesn't validate DNSSEC on its own.
http://www.dnssec-or-not.com/

 

[XIII]

If I decide to give up my custom unbound configuration (if...), what would I need to configure in 384.11 to achieve this?

• DOT via Cloudflare (1.1.1.1)
• DNSSEC turned on

(I’m confused by all the posts about 3 different DNSSEC settings)

 

[dave14305]

If I decide to give up my custom unbound configuration (if...), what would I need to configure in 384.11 to achieve this?

• DOT via Cloudflare (1.1.1.1)
• DNSSEC turned on

(I’m confused by all the posts about 3 different DNSSEC settings)

In the current Alpha 4, you only have to enable DNSSEC and it turns on DNSSEC in Stubby and enables dnsmasq to proxy and cache the "AD" flag from Stubby to clients. The three options mentioned are only valid for John's fork. Adding Cloudflare DoT is no sweat either. But DNSSEC is always a controversial debate around here, so everyone is always prepared to be wrong.

 

[bbunge]

Put your complete custom config file as /jffs/configs/stubby.yml and the firmware will use it instead of the generated one. Most people are only really aware of the "add" and "postconf" scripts, but the custom config (wholesale replacement) is also an option.

https://github.com/RMerl/asuswrt-merlin/wiki/Custom-config-files

stubby.yml is not in the list...

 

[bbunge]

This tells stubby where to resolve names for the initial startup and setup of the TLS resolvers. I think of it similar to how many people add "server=/pool.ntp.org/1.1.1.1/" to dnsmasq.conf so that ntp can sync before everything is up and running fully. /tmp/resolv.conf will always point to your WAN DNS servers, which is why I think it's a bad idea to set WAN DNS to your router LAN IP nowadays.

See my prior post where I set DNS Server1 to the router LAN ip address. Do not have server= entry in dnsmasq.conf.add in fact do not have dnsmasq.conf.add.

 

[dave14305]

stubby.yml is not in the list...

Because the feature is in alpha status still. But it's in there.

 

[skeal]

It's best to leave it as-is, or at least with valid DNS servers. You could make it 1.1.1.1 and 1.0.0.1 if you truly wanted only Cloudflare to receive your DNS queries, but there are very limited scenarios where the WAN DNS servers come into play. (i.e. only during startup or only if the new setting for "Wan: Use local caching DNS server as system resolver" is set to No, and even then, only for the router's own dns queries).

NTP update does not take place any sooner with the DNS Server set to 1.1.1.1 instead of the router's IP. The time sync happens at the same point in my reboot anyway.

 

[themiron]

Reboot worked without issues. @RMerlin @themiron clearly the proxy-dnssec does not need to be there, if using the webui settings.

it must be there, othercase authenticated status of reply from stubby will be lost in dnsmasq and will never reach lan clients.

Still trying to get an answer why this entry is in stubby.yml: resolvconf: "/tmp/resolv.conf"

because this file is the only valid path with upstream (isp) nameservers that stubby can use.

I think of it similar to how many people add "server=/pool.ntp.org/1.1.1.1/" to dnsmasq.conf so that ntp can sync before everything is up and running fully.

right, not a really great idea to have it configured, taking into account ntp issue was fixed in alpha2 and dnsmasq will always try to resolve all [*.]pool.ntp.org via 1.1.1.1 w/o dot/dnssec/etc with this record even if internet connection was not built or can't be built yet (think about pptp/l2tp or pppoe+dhcp, or other vpn-foo).

/tmp/resolv.conf will always point to your WAN DNS servers, which is why I think it's a bad idea to set WAN DNS to your router LAN IP nowadays.

yes, it's bad idea causing dns loop.

So far the only difference in mine from the original is that I added some other servers, but durring reboot it takes alonger for connection to be restored. Is there a more graceful way of doing this?

yep, add that servers via web ui.

In the current Alpha 4, you only have to enable DNSSEC and it turns on DNSSEC in Stubby and enables dnsmasq to proxy and cache the "AD" flag from Stubby to clients. The three options mentioned are only valid for John's fork. Adding Cloudflare DoT is no sweat either. But DNSSEC is always a controversial debate around here, so everyone is always prepared to be wrong.

things were changed, seems dnsmasq's dnssec works a bit faster unlike stubby with its additional uncached dot checking requests for every incoming one. so, dnsmasq now is used for dnssec for all non-dot + dot cases.
automatic anchor download is a good feature, but not a big deal.

Is this difference in settings (dnssec vs dnssec_return_status) equivalent to the current DNSSEC Strict Validation parameter? It seems the firmware only toggles dnsmasq settings and not Stubby when this is set.

no, they are different.
strict validation is about deeper checking of unsigned replies, dnsmasq takes steps to be sure they are really not signed. dnssec vs dnssec_return_status is more about bad/changed replies at the time when they can't be checked at all (due no root keys accesible, blocked by firewall, routing or so) and therefore dnssec validation is not functional.

 

[skeal]

Thank you for clearing up the various questions around this wonderful new addition @themiron !!