Stubby-Installer-Asuswrt-Merlin

[Poseidon]

What bothers me more than anything is messing with a very stable router. I've had no issues with my routers accepting each firmware update without resorting to a factory reset and reapplying all settings. I just flash and go. I hope these add-ons do not require more effort to keep updated and working well than this.

That's my concern too. I'm hoping that installing Stubby won't mess with my internet speed or web browsing that much. I can't seem to get a real answer wether or not Stubby slows things down or not.

 

[Adamm]

That's my concern too. I'm hoping that installing Stubby won't mess with my internet speed or web browsing that much. I can't seem to get a real answer wether or not Stubby slows things down or not.

Technically speaking, probably a few milliseconds, in real world terms you will never notice the difference. The cost/benefit ratio is very much in stubby's favor.

 

[L&LD]

That's my concern too. I'm hoping that installing Stubby won't mess with my internet speed or web browsing that much. I can't seem to get a real answer wether or not Stubby slows things down or not.

What kind of ISP speeds do you have? If it is anything over 10/1 u/d Mbps, on a low latency connection, you have nothing to worry about.

 

[RMerlin]

Is there opposition to DOH for any other reasons beside overheads/inefficiency/ugliness?

It's a bad design when you reuse a well-known port to carry a different type of trafic. It will mess with firewall/appliances that expect HTTPS traffic on that port. And ultimately, the Powers That Be who want to force you through their DNS will simply block the destination IP addresses of the DoH servers, so you'll be back at square one.

One of the original designers of the DNS system voiced his opinion against DoH for similar reasons.

https://www.theregister.co.uk/2018/...oh_as_dns_privacy_feature_becomes_a_standard/

The Internet works well because there are networking standards that are established. Bend them too much, and ultimately things start to break.

 

[Poseidon]

What kind of ISP speeds do you have? If it is anything over 10/1 u/d Mbps, on a low latency connection, you have nothing to worry about.

458 down/22 up.

I'll try Stubby. Tried using a VPN but that crippled my speeds big time and family want happy about that. Thanks

 

[maxbraketorque]

I did a bit of reading on DoT and DNSSEC, and I want to see if my understanding is correct on these protocols.

DoT encrypts the transmission between the client (ASUS router) and the specified DNS (Cloudflare, Quad9, etc.). If the DN request isn't cached at the specified DNS, then the DNS has to request the IP from the authoritative server or some other DNS, but that transmission is not encrypted, correct?

DNSSEC requires a datagram attached to the DNS response that verifies the authenticity of the resolved IP address, correct? If the IP is not available at the specified DNS (Cloudflare, Quad9, etc.), the DNSSEC method is still meant to continue out to the final authoritative server, but if that server doesn't do DNSSEC, problems can arise with IP resolution, correct?

 

[dave14305]

Very interesting commits today into Merlin by @theMIROn.

https://github.com/RMerl/asuswrt-merlin.ng/commit/b4e62e45c27ed5d18f0407ef59ee66fe08d3b967

 

[Cam]

Very interesting commits today into Merlin by @theMIROn.

With syslog support one of the next commits no less. Yay!

 

[skeal]

Looking nice!!

 

[Odkrys]

Looks good.

Edit: oh.. Rmerlin added dot preset into ui,, I need recompiling.
@RMerlin Will you support dot.conf.add and dot.postconf scripts?

And I got browser error messages when I clicked DNS Privacy Protocol and DNS-over-TLS Profile titles.

help.js:1083 
Uncaught TypeError: Cannot read property 'length' of undefined
    at openHint (help.js:1083)
    at HTMLAnchorElement.onclick (Advanced_WAN_Content.asp:1114)

help.js:1677 
Uncaught TypeError: Cannot read property 'style' of null
    at hideObject (help.js:1677)
    at eval (eval at runHook (help.js:2093), <anonymous>:1:1)
    at runHook (help.js:2093)
    at cClick (help.js:1356)
    at <anonymous>:1:1

 

[Swistheater]

Looks good.

Edit: oh.. Rmerlin added dot preset into ui,, I need recompiling.
@RMerlin Will you support dot.conf.add and dot.postconf scripts?

And I got browser error messages when I clicked DNS Privacy Protocol and DNS-over-TLS Profile titles.

help.js:1083
Uncaught TypeError: Cannot read property 'length' of undefined
    at openHint (help.js:1083)
    at HTMLAnchorElement.onclick (Advanced_WAN_Content.asp:1114)

help.js:1677
Uncaught TypeError: Cannot read property 'style' of null
    at hideObject (help.js:1677)
    at eval (eval at runHook (help.js:2093), <anonymous>:1:1)
    at runHook (help.js:2093)
    at cClick (help.js:1356)
    at <anonymous>:1:1

I notice in your picture you have connect to dns automatically turned off is that because enable the DNS privacy feature turned it off, or is that because you forgot to turn it on?

 

[bbunge]

I did a bit of reading on DoT and DNSSEC, and I want to see if my understanding is correct on these protocols.

DoT encrypts the transmission between the client (ASUS router) and the specified DNS (Cloudflare, Quad9, etc.). If the DN request isn't cached at the specified DNS, then the DNS has to request the IP from the authoritative server or some other DNS, but that transmission is not encrypted, correct?

DNSSEC requires a datagram attached to the DNS response that verifies the authenticity of the resolved IP address, correct? If the IP is not available at the specified DNS (Cloudflare, Quad9, etc.), the DNSSEC method is still meant to continue out to the final authoritative server, but if that server doesn't do DNSSEC, problems can arise with IP resolution, correct?

In two words, no and no.
If the upstream resolver has to go higher for your answer it relays the answer back to you encrypted with DoT and DNSSEC validation.

Sent from my SM-T380 using Tapatalk

 

[RMerlin]

@RMerlin Will you support dot.conf.add and dot.postconf scripts?

For now I'm focusing on tweaking/finalizing the core functionality before going with the Merlin-specific pieces like custom scripts. There are still a few things to finalize, like the UI pieces I started implementing last night.

I'll post more info in a separate thread when I'm ready to talk about it. For now best to keep this thread on topic.

 

[maxbraketorque]

In two words, no and no.
If the upstream resolver has to go higher for your answer it relays the answer back to you encrypted with DoT and DNSSEC validation.

Sent from my SM-T380 using Tapatalk

ok. Thanks. I did think that the response was returned to the client via DoT. I am just unsure what happens when the upstream server doesn't support either DoT or DNSSEC (or both).

 

[bbunge]

ok. Thanks. I did think that the response was returned to the client via DoT. I am just unsure what happens when the upstream server doesn't support either DoT or DNSSEC (or both).

Really doesn't matter. Say you use the Cloudflare resolvers in Stubby which support DoT and DNSSEC and they, Cloudflare, have to go higher to their trusted upstream resolvers, you get your answer relayed back via Cloudflare in DoT with DNSSEC validation.

Sent from my SM-T380 using Tapatalk

 

[maxbraketorque]

Really doesn't matter. Say you use the Cloudflare resolvers in Stubby which support DoT and DNSSEC and they, Cloudflare, have to go higher to their trusted upstream resolvers, you get your answer relayed back via Cloudflare in DoT with DNSSEC validation.

Sent from my SM-T380 using Tapatalk

Thanks. For now I'm trying just DNSSEC. I have switched from Cloudflare to Quad9 because when using Cloudflare I was getting the following occasional message in the router log:

... dnsmasq[...]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

I'm not getting this message with Quad9.

 

[bbunge]

Thanks. For now I'm trying just DNSSEC. I have switched from Cloudflare to Quad9 because when using Cloudflare I was getting the following occasional message in the router log:

... dnsmasq[...]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

I'm not getting this message with Quad9.

Interesting. Cloudflare with DNSSEC enabled in stubby works better for me than Quad9. I am up over 6 days on 384.10_2 with no errors. Getting boring. Might have to go fishing!

Sent from my SM-T380 using Tapatalk

 

[maxbraketorque]

If this error appears in the log (with strict validation enabled), should it mean that the attempted resolution failed, and the address of the target site can't be determined? I'm puzzled because no one in my house complained about not being able to reach a website. I suppose it could have been an advertising website or some such that no one notices if its not working.

 

[bbunge]

If this error appears in the log (with strict validation enabled), should it mean that the attempted resolution failed, and the address of the target site can't be determined? I'm puzzled because no one in my house complained about not being able to reach a website. I suppose it could have been an advertising website or some such that no one notices if its not working.

Where do you have DNSSEC enabled? Gui or Stubby?
Errors like that may not cause performance issues as stubby in roundrobin mode will switch to the next resolver in a heartbeat or less.
I would not worry about that error.

Sent from my SM-T380 using Tapatalk

 

[dave14305]

If this error appears in the log (with strict validation enabled), should it mean that the attempted resolution failed, and the address of the target site can't be determined? I'm puzzled because no one in my house complained about not being able to reach a website. I suppose it could have been an advertising website or some such that no one notices if its not working.

Is “Forward local domain queries to upstream DNS” enabled on your LAN DHCP page? The 168.192.in-addr.arpa is related to 192.168.0.0/16 reverse lookups. Just seems odd to me.