What's new

NextDNS Installer

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

Done.

For the curious ones; I still see these:
  • Time seems far in the past, waiting for NTP to run
  • Continue without NTP setup
  • roundtrip: x509: certificate has expired or is not yet valid
Did you try a clean reset of all your settings before trying this version since the previous version impacted nvram variables that this version may not, it is recommended you reset your settings and clean install nextdns installer. This is to eliminate old settings being the culprit. To do so please clear/reset your nvram and reenter all your correct settings. Then please install nextdns. Only then can you say 100 percent that nextdns is the culprit.
 
I intend to use amtm's Diversion/Pixelserv/Skynet + NextDNS when things quiet down a bit on the changes front. I am a big fan "layering" approaches b/c one tool rarely delivers everything and see value in each of these tools for my personal use. Is one good-enough without the others? Sure. Can you use all? Sure. The solution depends on what we are trying to achieve. There is no right or wrong answer - only choices.

I was wondering one thing, does this layering approach increase latency? If I just use NextDNS without Diversion, would it be slightly faster than using both?
 
Did you try a clean reset of all your settings before trying this version since the previous version impacted nvram variables that this version may not, it is recommended you reset your settings and clean install nextdns installer. This is to eliminate old settings being the culprit. To do so please clear/reset your nvram and reenter all your correct settings. Then please install nextdns. Only then can you say 100 percent that nextdns is the culprit.
Sounds like overkill to me, since it impacted only a few settings and it is clear from their code which ones (and with which value).
 
Sounds like overkill to me, since it impacted only a few settings and it is clear from their code which ones (and with which value).
Not sure if the new update restored old (nvram)values but if it did i guess it should be ok
 
Last edited:
Olivier told me to change a value via the web GUI. That's saved in the NVRAM?
Yea i think i read that post..
Was about changing your manual WAN DNS to auto (should not make a difference since you manually added other servers, the issue is if it is left emty=no servers in WAN)
 
Done.

For the curious ones; I still see these:
  • Time seems far in the past, waiting for NTP to run
  • Continue without NTP setup
  • roundtrip: x509: certificate has expired or is not yet valid

For some reason, the NTP not set detection does not work with you. I have another idea on how to fix NTP issue, stay tuned.
 
Yea i think i read that post..
Was about changing your manual WAN DNS to auto (should not make a difference since you manually added other servers, the issue is if it is left emty=no servers in WAN)
I tried both, with the same result.

So I'm waiting for Olivier's next build.
 
To validate my idea, can you set detect-captive-portal to true and try again?
That does seem to help!

The router rebooted and I could log in on the web GUI (which is already progress!).

Next I ssh'd in to the router to check the date, but that was still wrong:
Code:
admin@ac86u /tmp/home/root > date
Sat May  5 07:06:22 CEST 2018
However, DNS lookups via NextDNS now work.

And when I checked the time again, it was OK:
Code:
admin@ac86u /tmp/home/root > date
Mon Feb 17 18:14:10 CET 2020
 
I was wondering one thing, does this layering approach increase latency? If I just use NextDNS without Diversion, would it be slightly faster than using both?

Not 100% sure. I have no tracking data showing the time to resolve using NextDNS from my router's perspective. Diversion is right there under your roof so we are talking feet and not miles. NextDNS servers are in datacenter's miles away (could be many). In theory adding processing adds latency unless that processing is removing more latency than it's processing. That's one of the reasons I was interested in Unbound.

I want layering more for a security perspective so if there's a problem in one or the other I've got coverage active. What I can say is my main router is an AC86U running diversion, skynet, ... and linked up with NextDNS. My web pages are plenty, blinking fast!!
 
Last edited:
Not 100% sure. I have no tracking data showing the time to resolve using NextDNS from my router's perspective. Diversion is right there under your roof so we are talking feet and not miles. NextDNS servers are in datacenter's miles away (could be many). In theory adding processing adds latency unless that processing is removing more latency than it's processing. That's one of the reasons I was interested in Unbound.

I want layering more for a security perspective so if there's a problem in one or the other I've got coverage active. What I can say is my main router is an AC86U running diversion, skynet, ... and linked up with NextDNS. My web pages are plenty, blinking fast!!
I would have to say Diversion is faster as it uses already cached responses, and does not require the additional time on look-ups that NextDNS server has to do in order to process a block list or a response. In some situations NextDNS may be faster if dnsmasq is using an already cached response, overall i am still with diversion though. @thelonelycoder has that locked down pretty tight.
 
I would have to say Diversion is faster as it uses already cached responses, and does not require the additional time on look-ups that NextDNS server has to do in order to process a block list or a response. In some situations NextDNS may be faster if dnsmasq is using an already cached response, overall i am still with diversion though. @thelonelycoder has that locked down pretty tight.

It would require some benchmarking. Keep in mind that some of those Asus routers have limited compute capacity. One could argue that doing all the matching on router can slow down the overall performance of the router and impact even non DNS traffic to a certain extent. So it really depend on the capabilities of your router + the number and size of the blocklists you enabled.

In general I don't recommend layering blocking services. While it can give the impression that it can catch more stuff, it quickly become very hard to debug false positives. Logging becomes inconsistent and you have to manage whitelisting in two places.

In my opinion, it only make sense when you are mixing technologies. For instance, DNS with browser extension (like uBlock Origin) is an interesting combo. DNS based blocking will protect every apps & devices of your network while browser extension can catch and hide more varieties of ads but will only work in browser.
 
That does seem to help!

The router rebooted and I could log in on the web GUI (which is already progress!).

Next I ssh'd in to the router to check the date, but that was still wrong:
Code:
admin@ac86u /tmp/home/root > date
Sat May  5 07:06:22 CEST 2018
However, DNS lookups via NextDNS now work.

And when I checked the time again, it was OK:
Code:
admin@ac86u /tmp/home/root > date
Mon Feb 17 18:14:10 CET 2020

Could you please upgrade to the last version, disable captive portal detection and validate that it still work with NTP? Thanks for your help.
 
It would require some benchmarking. Keep in mind that some of those Asus routers have limited compute capacity. One could argue that doing all the matching on router can slow down the overall performance of the router and impact even non DNS traffic to a certain extent. So it really depend on the capabilities of your router + the number and size of the blocklists you enabled.

In general I don't recommend layering blocking services. While it can give the impression that it can catch more stuff, it quickly become very hard to debug false positives. Logging becomes inconsistent and you have to manage whitelisting in two places.

In my opinion, it only make sense when you are mixing technologies. For instance, DNS with browser extension (like uBlock Origin) is an interesting combo. DNS based blocking will protect every apps & devices of your network while browser extension can catch and hide more varieties of ads but will only work in browser.
While I support and like your enthusiasm for your product, on your free time can you take a look at some of these benchmarks and try to reproduce them using nextdns (note this may need some adjusting as it doesn't take into consideration of the dns server in relation to the clients location). ?
https://kazoo.ga/pixelserv-tls-more-is-less/
 
While I support and like your enthusiasm for your product, on your free time can you take a look at some of these benchmarks and try to reproduce them using nextdns (note this may need some adjusting as it doesn't take into consideration of the dns server in relation to the clients location). ?
https://kazoo.ga/pixelserv-tls-more-is-less/

Interesting benchmark, but it does only measure the difference between two block modes. As you mentioned, it does not measure the impact of DNS filtering, would it be local or remote.

The latency to our servers would be the major factor impacting the performance. As most DNS queries are performed in parallel, the performance to your DNS resolver, with local or remote filtering, will have the biggest impact on performance. What you don’t want, is filtering slowing down your DNS query latency. That is why we carefully select the blocklists we propose and avoid impossible to optimize matching methods like regex.
 
Last edited:

Similar threads

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