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!

'Unique prefix'
Excellent initiative. But I believe this option is useless since it is a commercially proposed DoT service. NextDNS has the purpose of trading this service with the unique configuration standard. Neither Cloudflare does this.
 
I believe this option [Unique prefix] is useless since it is a commercially proposed DoT service. NextDNS has the purpose of trading this service with the unique configuration standard.
Whatever, but in the context of the proposed GUI drop-down, on each router it must presumably be unique, otherwise you would have continued to publicly share your 'Unique prefix' in post #31 rather than (in a state of panic) redact it.
 
in post #31 rather than (in a state of panic) redact it.
After I noticed that there is no use using someone's ID. Better create an account and get the benefits of content blocks. Whether or not they use the ID. Anyway, NextDNS is still a service in the testing phase. Better to use Diversion.
 
One thing I like about using the NextDNS filtering is that I can choose the dbl.oisd.nl blocking list and not worry about limited resources on my AC68U if using the Large blocking list in Diversion. I'm running an experiment to see how I like it compared to Diversion/Pixelserv-tls. The dbl.oisd.nl list also includes the "Plus hosts" that Skynet and Diversion use together when both are active.

Yet sadly, once NextDNS is out of "beta" and begins charging a monthly fee, I imagine many testers will flee. But so far I like the service.
 
And it's back to failing despite all the fiddly nonsense I've done. Now pages just fail to resolve with some weird error and after few seconds load up. Usually. This is beyond absird and I'm just returning to some other DNS that works with ASUSWRT-Merlin. Coz this one which is the best otherwise, just doesn't.

Looks fine at first and then after many hours, it starts sperging with BS.
 
And it's back to failing despite all the fiddly nonsense I've done. Now pages just fail to resolve with some weird error and after few seconds load up. Usually. This is beyond absird and I'm just returning to some other DNS that works with ASUSWRT-Merlin. Coz this one which is the best otherwise, just doesn't.

Looks fine at first and then after many hours, it starts sperging with BS.
It's really difficult to help you further when you only give vague terms like "weird error" and "sperging". There was one setting to be customized in Stubby to make it work as NextDNS recommends. It worked fine on my router. You might have ISP issues with DoT port 853 or other geographic limitation with using the NextDNS service. But we'll never know for sure.

Let us know what DNS provider you settle on.
 
Looks fine at first and then after many hours, it starts sperging with BS.

Start with just one server. If you use multiple servers and one of these is unreliable, then you will experience highly random issues.

Also, skip on the IPv6 servers. You don't need these in a dual stack setup, and it adds yet another variable to the equation (in case your ISP's IPv6 support might be quirky in itself).
 
Start with just one server. If you use multiple servers and one of these is unreliable, then you will experience highly random issues.

Also, skip on the IPv6 servers. You don't need these in a dual stack setup, and it adds yet another variable to the equation (in case your ISP's IPv6 support might be quirky in itself).

I am currently using NextDNS. I implemented the suggested settings on using a single IPV4 DNS entry ( I have IPV6 enabled on my router ) , turning off the DNSSEC support and now web pages load much quicker when entering a web address.
 
Last edited:
DNSSEC validation will always potentially slow down name resolution, due to the extra validation round-trips.
 
Start with just one server. If you use multiple servers and one of these is unreliable, then you will experience highly random issues.

Also, skip on the IPv6 servers. You don't need these in a dual stack setup, and it adds yet another variable to the equation (in case your ISP's IPv6 support might be quirky in itself).
As merlin, use only one server , i recommend one ipv4 and and one ipv6 if you are using ipv6 connection as well, but you don't need IPV6. Their second servers are the problem. Once you are connecting to it you will start to see alot of connection drops. you also have the option to Forward Your local domain queries to their upstream if you decide to, as you can use them as that type of server, but I don't see how that would benefit your connection if you are not able to connect already. They favor DoH more than DoT, you can easily connect with DNSCRYPT proxy with them, or you will have better results with DoT with them if you are running unbound. Stubby is just far to complex to reliably use their less than favorable DoT servers.
 
don't need IPV6.
This subject is controversial. In traffic analysis of my network, queries are high on IPV6. IPV4/ IPV6 servers that use Unbound+Stubby respond very well.
Code:
[1575452952] unbound[29452:0] info: start of service (unbound 1.9.3).
[1575452952] unbound[29452:0] info: 127.0.0.1 gspe19-ssl.ls.apple.com. AAAA IN
[1575452952] unbound[29452:0] info: resolving gspe19-ssl.ls.apple.com. AAAA IN
[1575452952] unbound[29452:0] info: 127.0.0.1 gspe19-ssl.ls.apple.com. A IN
[1575452952] unbound[29452:0] info: resolving gspe19-ssl.ls.apple.com. A IN
[1575452952] unbound[29452:0] info: response for gspe19-ssl.ls.apple.com. AAAA IN
[1575452952] unbound[29452:0] info: reply from <.> 127.0.0.1#5453
[1575452952] unbound[29452:0] info: query response was CNAME
[1575452952] unbound[29452:0] info: resolving gspe19-ssl.ls.apple.com. AAAA IN
[1575452952] unbound[29452:0] info: response for gspe19-ssl.ls.apple.com. A IN
[1575452952] unbound[29452:0] info: reply from <.> 127.0.0.1#5453
[1575452952] unbound[29452:0] info: query response was CNAME
[1575452952] unbound[29452:0] info: resolving gspe19-ssl.ls.apple.com. A IN
[1575452953] unbound[29452:0] info: response for gspe19-ssl.ls.apple.com. A IN
[1575452953] unbound[29452:0] info: reply from <.> 127.0.0.1#5453
[1575452953] unbound[29452:0] info: query response was CNAME
[1575452953] unbound[29452:0] info: resolving gspe19-ssl.ls.apple.com. A IN
[1575452953] unbound[29452:0] info: response for gspe19-ssl.ls.apple.com. AAAA IN
[1575452953] unbound[29452:0] info: reply from <.> 127.0.0.1#5453
[1575452953] unbound[29452:0] info: query response was CNAME
[1575452953] unbound[29452:0] info: resolving gspe19-ssl.ls.apple.com. AAAA IN
[1575452953] unbound[29452:0] info: response for gspe19-ssl.ls.apple.com. A IN
[1575452953] unbound[29452:0] info: reply from <.> ::1#5453
[1575452953] unbound[29452:0] info: query response was ANSWER
[1575452953] unbound[29452:0] info: prime trust anchor
[1575452953] unbound[29452:0] info: generate keytag query _ta-4f66. NULL IN
[1575452953] unbound[29452:0] info: resolving . DNSKEY IN
[1575452953] unbound[29452:0] info: resolving _ta-4f66. NULL IN
[1575452953] unbound[29452:0] info: response for gspe19-ssl.ls.apple.com. AAAA IN
[1575452953] unbound[29452:0] info: reply from <.> ::1#5453
[1575452953] unbound[29452:0] info: query response was ANSWER
[1575452953] unbound[29452:0] info: prime trust anchor
[1575452953] unbound[29452:0] info: response for . DNSKEY IN
[1575452953] unbound[29452:0] info: reply from <.> ::1#5453

Fire-Shot-Capture-004-secure-dns-png-PNG-Image-1086-671-pixels-www-linuxbabe-com.png
 
Last edited:
This subject is controversial. In traffic analysis of my network, queries are high on IPV6. IPV4/ IPV6 servers that use Unbound+Stubby respond very well.
Code:
[1575452952] unbound[29452:0] info: start of service (unbound 1.9.3).
[1575452952] unbound[29452:0] info: 127.0.0.1 gspe19-ssl.ls.apple.com. AAAA IN
[1575452952] unbound[29452:0] info: resolving gspe19-ssl.ls.apple.com. AAAA IN
[1575452952] unbound[29452:0] info: 127.0.0.1 gspe19-ssl.ls.apple.com. A IN
[1575452952] unbound[29452:0] info: resolving gspe19-ssl.ls.apple.com. A IN
[1575452952] unbound[29452:0] info: response for gspe19-ssl.ls.apple.com. AAAA IN
[1575452952] unbound[29452:0] info: reply from <.> 127.0.0.1#5453
[1575452952] unbound[29452:0] info: query response was CNAME
[1575452952] unbound[29452:0] info: resolving gspe19-ssl.ls.apple.com. AAAA IN
[1575452952] unbound[29452:0] info: response for gspe19-ssl.ls.apple.com. A IN
[1575452952] unbound[29452:0] info: reply from <.> 127.0.0.1#5453
[1575452952] unbound[29452:0] info: query response was CNAME
[1575452952] unbound[29452:0] info: resolving gspe19-ssl.ls.apple.com. A IN
[1575452953] unbound[29452:0] info: response for gspe19-ssl.ls.apple.com. A IN
[1575452953] unbound[29452:0] info: reply from <.> 127.0.0.1#5453
[1575452953] unbound[29452:0] info: query response was CNAME
[1575452953] unbound[29452:0] info: resolving gspe19-ssl.ls.apple.com. A IN
[1575452953] unbound[29452:0] info: response for gspe19-ssl.ls.apple.com. AAAA IN
[1575452953] unbound[29452:0] info: reply from <.> 127.0.0.1#5453
[1575452953] unbound[29452:0] info: query response was CNAME
[1575452953] unbound[29452:0] info: resolving gspe19-ssl.ls.apple.com. AAAA IN
[1575452953] unbound[29452:0] info: response for gspe19-ssl.ls.apple.com. A IN
[1575452953] unbound[29452:0] info: reply from <.> ::1#5453
[1575452953] unbound[29452:0] info: query response was ANSWER
[1575452953] unbound[29452:0] info: prime trust anchor
[1575452953] unbound[29452:0] info: generate keytag query _ta-4f66. NULL IN
[1575452953] unbound[29452:0] info: resolving . DNSKEY IN
[1575452953] unbound[29452:0] info: resolving _ta-4f66. NULL IN
[1575452953] unbound[29452:0] info: response for gspe19-ssl.ls.apple.com. AAAA IN
[1575452953] unbound[29452:0] info: reply from <.> ::1#5453
[1575452953] unbound[29452:0] info: query response was ANSWER
[1575452953] unbound[29452:0] info: prime trust anchor
[1575452953] unbound[29452:0] info: response for . DNSKEY IN
[1575452953] unbound[29452:0] info: reply from <.> ::1#5453

secure-dns.png
As you have alluded to through your personal illustration and logs,ipv6 can be very useful when it works, the problem that most people notice is that it can also be one more variable to deal with in troubleshooting failed connections, as this can be a key factor on why there is not connection because ipv6 can be quite temperamental. The lack of ipv6 control and customizable options at the firmware level makes ipv6 less than favorable to use when it decides it does not want to act right.
 
The lack of ipv6 control and customizable options at the firmware level makes ipv6 less than favorable to use when it decides it does not want to act right.
I agree with you. But this has to do with the ISP's ability to properly configure. For my reality, it is fully functional. The question is the disregard of IPV6 in favor of IPV4.
 
Question is the fact that simply ignoring the IPV6 pattern, avoiding the requirement that ISPs fully and functionally support IPV6. I demanded it from my ISP. Anyway, this is a matter for another post
 
Last edited:
Start with just one server. If you use multiple servers and one of these is unreliable, then you will experience highly random issues.

Also, skip on the IPv6 servers. You don't need these in a dual stack setup, and it adds yet another variable to the equation (in case your ISP's IPv6 support might be quirky in itself).

I've added only IPv4 server and despite those changes with scripts, I get connectivity issues over time. Usually takes like a day and then it all goes wonky. Never shows immediately which is really weird and hard to diagnose.
 
Is your isp's ip changing often?
Do you use DDNS to update your ip on nextDNS config page?
 
Is your isp's ip changing often?
Do you use DDNS to update your ip on nextDNS config page?

When you're using DoT, NextDNS acquires your IP with the query and links it automatically to the DNS profile (configuration) you're contacting them through. You only need to link IP manually or via IP update URL if you're using regular DNS and want to use the blocking, filtering and analytics with it. So, that part should be fine since I am using DoT. That's what I was told by one of the NextDNS guys when I posted this very idea of linking IP to the profile and they said it's already being used, but only with DoT.
 
In that case, see if they have a basic RESTful API that could be invoked through a simple curl command in a ddns-start script.
 
I use nextDNS on kids school laptops but not with DoT atm
I use DDNS to update the ip
 

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