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.
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
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
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
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).
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.
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.
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.
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.
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.
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.