NextDNS Installer

[RMerlin]

Any tips on how to work around the Catch-22 where NextDNS needs proper time and NTP needs DNS?

(the NTP service I use requires me to use a domain name instead of an IP address)

Ideally, NextDNS shouldn't use any crypto until the ntp_ready variable is set to 1 in nvram. This is how DoT and DNSSEC work in the built-in firmware - until the NTP is set, neither of them will validate signatures. Once ntp_ready is set to 1, they are both told to start validating certificates.

 

[XIII]

Ideally, NextDNS shouldn't use any crypto until the ntp_ready variable is set to 1 in nvram. This is how DoT and DNSSEC work in the built-in firmware - until the NTP is set, neither of them will validate signatures. Once ntp_ready is set to 1, they are both told to start validating certificates.

@Olivier Poitrey Can you please look into this?

(I can no longer remotely reboot my router since using NextDNS because of this - well I can reboot, but nothing works properly afterwards, until I log in locally and manually set the time)

 

[Ubimo]

What are the pros and cons using NextDNS over Adguard DNS?

 

[XIII]

What are the pros and cons using NextDNS over Adguard DNS?

Non-exhaustive:

• pro: much more granular control over what get's blocked
• con: NextDNS will be a paid service; AdGuard DNS is free

 

[Olivier Poitrey]

@Olivier Poitrey Can you please look into this?

(I can no longer remotely reboot my router since using NextDNS because of this - well I can reboot, but nothing works properly afterwards, until I log in locally and manually set the time)

What version do you run? The current version detects when time is not set properly, and wait until the time is set before starting up: https://github.com/nextdns/nextdns/blob/06c9adb1760d6632838ae992e65f6c0dadfb14e1/run.go#L105

Perhaps the NTP unconfigured detection is not working properly in your case. With the time properly set, what do you get for `ls -l /jffs/nextdns/nextdns`?

 

[XIII]

What version do you run? The current version detects when time is not set properly, and wait until the time is set before starting up: https://github.com/nextdns/nextdns/blob/06c9adb1760d6632838ae992e65f6c0dadfb14e1/run.go#L105

1.4.31:

admin@ac86u /tmp/home/root > /jffs/nextdns/nextdns version
nextdns version 1.4.31

Perhaps the NTP unconfigured detection is not working properly in your case. With the time properly set, what do you get for `ls -l /jffs/nextdns/nextdns`?

This:

admin@ac86u /tmp/home/root > ls -l /jffs/nextdns/nextdns
-rwxr-xr-x    1 admin    root       6619136 Feb  7 07:17 /jffs/nextdns/nextdns

 

[Olivier Poitrey]

1.4.31:

admin@ac86u /tmp/home/root > /jffs/nextdns/nextdns version
nextdns version 1.4.31

This:

admin@ac86u /tmp/home/root > ls -l /jffs/nextdns/nextdns
-rwxr-xr-x    1 admin    root       6619136 Feb  7 07:17 /jffs/nextdns/nextdns

In your system logs, do you get something like this during startup:

Time seems far in the past, waiting for NTP to run

 

[XIII]

In your system logs, do you get something like this during startup:

Time seems far in the past, waiting for NTP to run

Yes:

admin@ac86u /tmp/mnt/usb/entware/var/log > grep "Time seems far in the past, waiting for NTP to run" *
messages:May  5 05:05:35 nextdns[1215]: Time seems far in the past, waiting for NTP to run
messages:May  5 05:05:36 nextdns[1225]: Time seems far in the past, waiting for NTP to run
messages:May  5 05:05:37 nextdns[1212]: Time seems far in the past, waiting for NTP to run

 

[Olivier Poitrey]

Yes:

admin@ac86u /tmp/mnt/usb/entware/var/log > grep "Time seems far in the past, waiting for NTP to run" *
messages:May  5 05:05:35 nextdns[1215]: Time seems far in the past, waiting for NTP to run
messages:May  5 05:05:36 nextdns[1225]: Time seems far in the past, waiting for NTP to run
messages:May  5 05:05:37 nextdns[1212]: Time seems far in the past, waiting for NTP to run

When you stop nextdns, do you still have resolution? It seems nextdns is properly not started before NTP runs, but for some reason, resolution doesn't work without it, so you can't access your NTP server.

 

[RMerlin]

That log still shows May 5th, which would indicates ntp hasn't synced yet when these log entries were generated.

 

[jackiechun]

I sent over the full log to Olivier but just wanted to share a snippet of when I rebooted my AC86U:

May  5 05:05:15 nextdns[917]: Time seems far in the past, waiting for NTP to run
May  5 05:05:45 nextdns[917]: Continue without NTP setup
May  5 05:05:45 nextdns[917]: Setting up router
May  5 01:05:45 rc_service: service 1511:notify_rc restart_dnsmasq
May  5 05:05:45 nextdns[917]: Activating
May  5 05:05:45 nextdns[917]: Activate: activate: 127.0.0.1:53: no address found
May  5 05:05:45 nextdns[917]: Recieved signal: child exited (ignored)
May  5 05:05:45 nextdns[917]: Recieved signal: child exited (ignored)
Feb 10 12:44:35 ntpd: Initial clock set
Feb 10 12:44:35 rc_service: ntpd_synced 1690:notify_rc restart_diskmon
Feb 10 17:44:35 nextdns[917]: Connected 45.90.28.0:443 (con=0ms tls=49ms, TLS13)
Feb 10 12:44:38 crond[782]: time disparity of 930999 minutes detected
Feb 10 17:44:42 nextdns[917]: Discovered(MDNS) ...
Feb 10 17:44:48 nextdns[917]: Discovered(DHCP) ....
Feb 10 17:44:50 nextdns[917]: Connected 155.138.142.79:443 (con=21ms tls=41ms, TLS13)
Feb 10 17:44:50 nextdns[917]: Switching endpoint: https://vultr-toronto-1.edge.nextdns.io#155.138.142.79,2001:19f0:b001:eb6:5400:2ff:fe17:269c
Feb 10 12:47:36 WLCEVENTD: eth6: Assoc ....
Feb 10 12:47:37 dnsmasq-dhcp[1514]: DHCPREQUEST(br0) ....
Feb 10 12:47:37 dnsmasq-dhcp[1514]: DHCPACK(br0) .....

I'm in the -5 timezone so 12:44pm was correct whereas nextdns was 5 hours ahead. I'm not 100% sure but I'm guessing this caused issues with security certificate date/times and caused the connection to fail in my case. (was 384.13 + nextdns version 1.4.27, I'm now using the unencrypted nextdns servers + 384.12).

It seems the NTP update detection code in NextDNS isn't being triggered ("NTP update detected"): https://github.com/nextdns/nextdns/blob/master/run.go#L128

 

[XIII]

That log still shows May 5th, which would indicates ntp hasn't synced yet when these log entries were generated.

Yes, but isn't that an essential part of my problem?

ntp cannot sync because the domain name of the time server cannot be resolved to an IP address? (since NextDNS is not running)

 

[RMerlin]

Yes, but isn't that an essential part of my problem?

ntp cannot sync because the domain name of the time server cannot be resolved to an IP address? (since NextDNS is not running)

But the log also shows that NextDNS is well aware of it, and is still waiting. So unless it eventually gave up waiting, it should still be in wait mode.

 

[dave14305]

Yes, but isn't that an essential part of my problem?

ntp cannot sync because the domain name of the time server cannot be resolved to an IP address? (since NextDNS is not running)

I think I mentioned this a while ago, but make sure you have WAN DNS servers defined. The way NextDNS changes nvram could theoretically prevent the router from having a valid resolv.conf file, depending how the router was rebooted. Can't remember if we had that discussion here or on Github.

When you're in that no-man's land state, it would be good to examine the contents of /etc/dnsmasq.conf and /etc/resolv.conf.

 

[SomeWhereOverTheRainBow]

Any tips on how to work around the Catch-22 where NextDNS needs proper time and NTP needs DNS?

(the NTP service I use requires me to use a domain name instead of an IP address)

The chicken or the egg situation

 

[gattaca]

I think I mentioned this a while ago, but make sure you have WAN DNS servers defined. The way NextDNS changes nvram could theoretically prevent the router from having a valid resolv.conf file, depending how the router was rebooted. Can't remember if we had that discussion here or on Github..

Yes someone said that the WAN DNS allows the ROUTER to reach the NTP servers while the clients are forced to use whatever else is in play.. I think I read. So putting 9.9.9.9 or 1.1.1.1 or whatever in those two should solve the timesync? Maybe I'm wrong? I don't have NextDNS enabled right now.

 

[RMerlin]

People should never leave the WAN DNS blank. You *need* valid DNS servers configured there, either provided by the ISP (if set to Auto), either manually entered (if you prefer to use Quad8/Quad9/Quad1/QuadQuack/etc...)

It doesn't matter if you use DoT, DNSCrypt or NextDNS to encrypt your DNS queries - the router itself will still need those local WAN DNS to be present and valid.

 

[XIII]

It doesn't matter if you use DoT, DNSCrypt or NextDNS to encrypt your DNS queries - the router itself will still need those local WAN DNS to be present and valid.

Then this is also a mistake?

wan_dnsenable_x=0

(part of NextDNS’s setup.go)

 

[dave14305]

Then this is also a mistake?

wan_dnsenable_x=0

(part of NextDNS’s setup.go)

This was discussed on Github here: https://github.com/nextdns/nextdns/issues/77

I think Olivier knows it might need rework, but they certainly have their hands full supporting so many platforms.

 

[RMerlin]

Then this is also a mistake?

wan_dnsenable_x=0

(part of NextDNS’s setup.go)

This is a bad idea, yes. The router would have no way of reaching the outside world if NextDNS isn't running yet. So for instance, things like NTP updates would fail... It would most probably also break Beeline customers who need a private DNS server obtained through DHCP, which is then used to connect to the PPTP server that establishes their Internet connection.