What's new

ASUSWRT-Merlin and NextDNS issue

  • 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!

I think it’s stubby that fails. We got several reports of instability of stubby with our service. We still need to figure out why.
Is there an ideal idle_timeout for Stubby with NextDNS? Quad9 has (or had) a much shorter idle timeout than Cloudflare, for example.
 
If you don't disable DNSSEC validation in dnsmasq, any blocked queries on domains supporting DNSSEC will fail the validation. It will still kind of block them but pollute your logs and may slow down the blocking as most stub will retry on SERVFAIL instead of just giving up.

We do DNSSEC validation at NextDNS level. It is advised not to enable it as client level with us.
I recommend proxy-dnssec instead as it is the only option that makes sense since nextdns is providing validations, you would want it to properly pass off to clients and vice versa and benefit from caching those responses.
 
Last edited:
I'd like to chime in, if the behaviour is seeing SERVFAIL when using Stubby? I've seen this crop up a lot today when using NextDNS, previously using Cloudflare/Google DoT without issue

The SERVFAIL is not generated by NextDNS but by the DNSSEC validating client when a response is altered, which is what we do when we block a domain.
 
The SERVFAIL is not generated by NextDNS but by the DNSSEC validating client when a response is altered, which is what we do when we block a domain.
Weird that SERVFAIL was being returned for most domains, though that may have been because I inadvertently had dnsmasq also validating dnssec responses?
 
Weird that SERVFAIL was being returned for most domains, though that may have been because I inadvertently had dnsmasq also validating dnssec responses?

In the case of stubby I suspect it does not reconnect correctly when the server closes the connection and start sending SERVFAIL for all queries then. Stubby issue as potentially no link with DNSSEC. It is just a guess, I need to find a way to reproduce the issue in a controlled way (and the time to do it).
 
You may have more timeouts with secondaries as they are on a separate network with less PoPs (so farther).


In the case of stubby I suspect it does not reconnect correctly when the server closes the connection and start sending SERVFAIL for all queries then. Stubby issue as potentially no link with DNSSEC. It is just a guess, I need to find a way to reproduce the issue in a controlled way (and the time to do it).
Let me know if I can help in any way. Last time I looked into Stubby in any real detail there wasn't much available in the way of increasing the verbosity of logging. Not sure if that has changed now!
 
In the case of stubby I suspect it does not reconnect correctly when the server closes the connection and start sending SERVFAIL for all queries then. Stubby issue as potentially no link with DNSSEC. It is just a guess, I need to find a way to reproduce the issue in a controlled way (and the time to do it).
I would look into the tls_backoff_time when disabling round-robin. You might be failing both upstreams and not have reached the backoff time threshold.
 
In the case of stubby I suspect it does not reconnect correctly when the server closes the connection and start sending SERVFAIL for all queries then. Stubby issue as potentially no link with DNSSEC. It is just a guess, I need to find a way to reproduce the issue in a controlled way (and the time to do it).
By the way, which is correct?
DNS-over-TLS
Prepend the name of your choice to the provided domain (the name should only contain a-z, A-Z, 0-9 and -).
Example: for "John-Home-Router", you would use John-Home-Router-XXX.dns.nextdns.io as your DNS-over-TLS endpoint.

or

DNS-over-TLS
Use the following in stubby.yml:

round_robin_upstreams: 0
upstream_recursive_servers:
- address_data: 45.90.28.0
tls_auth_name: "XXX.dns1.nextdns.io"
- address_data: 2a07:a8c0::0
tls_auth_name: "XXX.dns1.nextdns.io"
- address_data: 45.90.30.0
tls_auth_name: "XXX.dns2.nextdns.io"
- address_data: 2a07:a8c1::0
tls_auth_name: "XXX.dns2.nextdns.io"

Should we be adding a name in stubby.yml?
 
Keep us posted.

I got the 86U in, installed 384.15, setup the usb drive, installed amtm and all the other scripts I normally run. This thing is a lot faster than my 68U , which is still running my network. I have a couple of devices on the 86U and will let it run overnight before swapping it in place of the 68U. So far I am loving the new router! Oh yea, the new web page for Skynet stats is pretty cool.
 
I also had a lot of SERVFAIL’s.

In fact, my network was almost unusable in the last few days that I used NextDNS via stubby (I had to restart the dnsmasq service multiple times every hour). Everything seems stable now that I’m back on Cloudflare.

Would like to use NextDNS, so hope the SNB community can help them solve this.
 
I also had a lot of SERVFAIL’s.

In fact, my network was almost unusable in the last few days that I used NextDNS via stubby (I had to restart the dnsmasq service multiple times every hour). Everything seems stable now that I’m back on Cloudflare.

Would like to use NextDNS, so hope the SNB community can help them solve this.
I too have reverted to cloudflare after nextdns stopped working overnight.
 
... This thing is a lot faster than my 68U , which is still running my network.
Yeap, I waterfalled my older 68U/1900u units into WAPs at opposite ends of the house.. more than one target to hit and I used different names so the family knows which WAP is which.. . YMMV :)
 
I recommend proxy-dnssec instead as it is the only option that makes sense since nextdns is providing validations, you would want it to properly pass off to clients and vice versa and benefit from caching those responses.
Guys, I still don't understand this conversation - sorry. Can someone explain, in laymen's terms, why we do or do not want DNSSEC checked in the WAN GUI when using NextDNS. I've seen too many conflicting reports now to know which one to believe ON or OFF and why? And BTW, I'm using DNS-over-TLS
 
Guys, I still don't understand this conversation - sorry. Can someone explain, in laymen's terms, why we do or do not want DNSSEC checked in the WAN GUI when using NextDNS. I've seen too many conflicting reports now to know which one to believe ON or OFF and why? And BTW, I'm using DNS-over-TLS
Since ad-blocking is happening on the upstream resolver (NextDNS), it may return “modified” results for a signed zone. dnsmasq will see these as BOGUS results if doing its own DNSSEC validation. When Diversion is doing the blocking, it doesn’t have to check the results because the blocked domain names never get sent upstream for resolution.

EDIT: sorry, maybe not layman enough.
 
^^^^ Actually, helpful - makes perfect sense.

BUT .. I think you posted that you prefer to keep DNSSEC on locally and you made a few posts earlier to the configs to to allow diversion + Pixelserv to act as a 2nd layer to NextDNS as long as we set NextDNS to use 0.0.0.0 returns.. or am I mis-remembering? For me, I like layers for this stuff... so if something sneaks past the front link, there's a fallback waiting to stop it.
 

Latest threads

Sign Up For SNBForums Daily Digest

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