[6.5.3] DNS settings not used when checking for new version of unraid and plugins

All functions on unRAID make use of the network settings, there are no separate settings for checking for updates.

 

The command below will tell which DNS entries are used by unRAID (should match the network settings)

cat /etc/resolv.conf

Perhaps your router is blocking more than expected? Any logs on the router?

This is the result from the command and it looks ok.

root@unRAID:~# cat /etc/resolv.conf
# Generated DNSv4 entries:
nameserver 9.9.9.9
nameserver 1.0.0.1
# Generated DNSv6 entries:

 

I have a dd-wrt router with a static route for 8.8.8.8 and 8.8.4.4. As soon I remove those the update starts working...

I don't have a dd-wrt router, but how exactly are you denying DNS queries to 8.8.8.8 and 8.8.4.4 ?

 

DNS queries are always on port 53. Both UDP and TCP are possible. A rule which denies specific destination address(es) and specific port(s) would work best.

 

Destination LAN NET	Subnet Mask	Gateway	Flags	Metric	Interface
default	0.0.0.0	1xx.xx.x.x	UG	0	WAN
8.8.4.4	255.255.255.255	192.168.1.254	UGH	2	LAN & WLAN
8.8.8.8	255.255.255.255	192.168.1.254	UGH	2	LAN & WLAN
1xx.xx.x.x	255.255.255.224	*	U	0	WAN
169.254.0.0	255.255.0.0	*	U	0	LAN & WLAN
192.168.1.0	255.255.255.0	*	U	0	LAN & WLAN

 

 

Those IPs are redirected to the router's IP, but this shouldn't matter as I'm using different DNSs.

Edited August 3, 2018 by thomas
more info

I find this a strange way of denying. You tell your router that 8.8.8.8 and 8.8.4.4 is on your LAN, which may give unpredictable results.

 

Does your router have ACLs or firewall rules? The better approach is to put a restriction on the traffic from the LAN (=outgoing) and deny destination 8.8.8.8+port 53

Unfortunately DD-WRT is not that smart. What I wanted to accomplish is all the devices that have google DNSs as default, to revert to the one that is running in the network. Those rules accomplish that. If I'm checking the DNS requests using the google DNSs they timeout.

What is the result of (do this on your unRAID server)

traceroute 9.9.9.9
traceroute 1.0.0.1

Tip: you can also verify the same command with 8.8.8.8 and 8.8.4.4 as destination

See below the results

 

root@unRAID:~# traceroute 9.9.9.9
traceroute to 9.9.9.9 (9.9.9.9), 30 hops max, 60 byte packets
 1  192.168.1.254 (192.168.1.254)  16.803 ms  16.798 ms  16.794 ms
 2  * * *
 3  * * *
 4  149.248.92.141 (149.248.92.141)  34.132 ms  34.142 ms  41.240 ms
 5  woodynet.torontointernetxchange.net (206.108.34.115)  41.204 ms  41.201 ms  41.197 ms
 6  dns.quad9.net (9.9.9.9)  39.981 ms !X  15.685 ms !X  20.601 ms !X
root@unRAID:~# traceroute 1.0.0.1
traceroute to 1.0.0.1 (1.0.0.1), 30 hops max, 60 byte packets
 1  192.168.1.254 (192.168.1.254)  16.792 ms  16.785 ms  16.779 ms
 2  * * *
 3  * * *
 4  149.248.92.141 (149.248.92.141)  25.321 ms  25.323 ms  25.318 ms
 5  he.ip4.torontointernetxchange.net (206.108.34.112)  26.868 ms  26.869 ms  30.658 ms
 6  198.32.181.56 (198.32.181.56)  33.326 ms cloudflare.ip4.torontointernetxchange.net (206.108.34.208)  17.442 ms as13335.toronto.megaport.com (206.53.203.8)  18.906 ms
 7  1dot1dot1dot1.cloudflare-dns.com (1.0.0.1)  17.367 ms  17.353 ms  17.349 ms
root@unRAID:~# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.254 (192.168.1.254)  12.698 ms  12.693 ms  12.688 ms
 2  192.168.1.254 (192.168.1.254)  3003.381 ms !H  3003.391 ms !H  3003.389 ms !H
root@unRAID:~# traceroute 8.8.4.4
traceroute to 8.8.4.4 (8.8.4.4), 30 hops max, 60 byte packets
 1  192.168.1.254 (192.168.1.254)  12.723 ms  12.722 ms  12.718 ms
 2  192.168.1.254 (192.168.1.254)  3005.614 ms !H  3005.617 ms !H  3005.620 ms !H

8.8.8.8 and 8.8.4.4 are indeed "terminated" by your router.

 

The plugin update function of unRAID however has a built-in Internet alive check, which is done by pinging 8.8.8.8, before it downloads files.

 

Your "deny" rule interferes with this check and hence no download takes place, resulting in the status "unknown". It is unfortunate that you can not make this deny rule more exact and only deny DNS queries.

Pinging 8.8.8.8 for internet alive, I don't think is the best practice. Maybe you should ping the first DNS server, that is defined, if it's external, or resolve an internet domain using 2 different DNS servers, from different providers...

pinging a destination is very common practice, it is done because of speed and low overhead (you want to determine as quickly as possible whether internet access works).

 

pinging the first DNS server isn't reliable. This can be your local router and it may answer fine while no internet is present.

Resolving an domain name is both time consuming and a heavy duty task (compared to a ping).

 

Could always issue a NTP request to the configured NTP server, no?

ping was invented for these kind of circumstances.

 

It all comes down to proper firewalling.

In my case I block external DNS queries too and force my LAN clients to use my local DNS servers.

The gateway (firewall) is configured in such a way that a direct DNS qurey is not allowed, but ping or traceroute to the same address is permitted.

 

1 hour ago, bonienl said:

The plugin update function of unRAID however has a built-in Internet alive check, which is done by pinging 8.8.8.8, before it downloads files.

Please, please, please make that configurable, even if we have to manually change an entry in a file. I do NOT want basic functionality hardcoded to an external IP we don't control, and we have no way of changing.

 

I realize it works properly 99.999% of the time, but can we at least have it be changeable if needed?

11 minutes ago, jonathanm said:

I realize it works properly 99.999% of the time, but can we at least have it be changeable if needed?

 

Actually the code is written with a variable, which defaults to 8.8.8.8

 

I am very hesitant to make this configurable for users, because it introduces a (huge) risk that people set this wrong.

When your firewall is set up properly there is no issue whatsoever,  but making it configurable increases the chance to nearly 100% of not working (yes, I know there are knowledgeable people out there).

 

 

Edited August 3, 2018 by bonienl

How about a compromise. Add a second user configurable field that it will fail over and try if 8.8.8.8 doesn't answer for whatever reason.

The source of the problem is the firewall.

 

If somebody decides to block any ping request on his firewall, no fail-over will ever work.

 

3 minutes ago, bonienl said:

The source of the problem is the firewall.

 

If somebody decides to block any ping request on his firewall, no fail-over will ever work.

 

Not just ANY ping request, just 8.8.8.8. All I ask is a way to keep updates working while not pinging a google address.

2 hours ago, bonienl said:

8.8.8.8 and 8.8.4.4 are indeed "terminated" by your router.

 

The plugin update function of unRAID however has a built-in Internet alive check, which is done by pinging 8.8.8.8, before it downloads files.

 

Your "deny" rule interferes with this check and hence no download takes place, resulting in the status "unknown". It is unfortunate that you can not make this deny rule more exact and only deny DNS queries.

This will kinda prevent unraid from being updated in networks where the user has no control (AFAIK some parts of China for example) over the access to 8.8.8.8

 

Windows has a similar test they use to show in the UI if you have internet connectivity, it tries to resolve a DNS address and ping it I think. But it will still go ahead and attempt to download stuff regardless.

FCP also has a silly test to ping github.com .. but the CDN in my locality doesn't allow pings... go figure...

I haven't filed a complaint there because I don't use FCP, only tested it.

 

I think its better that the UI just display a warning that the user might not have internet connectivity (with a why button) and go ahead and try anyway.

The current solution was implemented more than a year ago. Seeing this in perspective, it works 99.999% of the time.

 

I don't think we should design with the restrictions of China in mind. Not able to ping Google, probably also means not able to access Github.

 

The Windows solution takes up to several minutes before the status is updated. That is a too long wait when retrieving the plugins status information and people will feel it takes "forever" to get the information.

 

Ultimately I am looking for a non-intrusive solution working in the background without user intervention. The moment a user can make changes, it will go wrong, even when multiple warnings are given (disk FORMAT comes to my mind).

 

I only mentioned China as an extreme example.

Like I said in my post - the FCP plugin as an example has a test for internet connectivity, by pinging GitHub. It then complains that it can't connect to the internet if the ping fails. But its an invalid test for my part of the internet as the local CDN for GitHub does not like to be pinged. I checked with a VPN and a US VPS, and the CDN in that part of the internet has no issues with being pinged.

 

You really should be using curl/wget/nc against the port 80 of the server you want to access as the correct internet connectivity test. I've seen ISPs being anal about it and completely block off some services like public Google DNS. ICMP pings nowadays are blocked on some parts the internet for reasons of security, etc. It'll relax again when we finally move to IPv6 as that requires ICMPv6 to always work.

 

Ultimately I think, the UI can attempt to download and if it fails, it can run the checks to let the user know what it thinks is wrong.

Pre-emptive mechanisms for  situations like this doesn't always work right.

Hehe, I work for an ISP.

 

Not allowing ping is against established net etiquette, I would file a complaint with my provider if they do. Security, yeah right, nowadays DDOS attacks are much more sophisticated 

 

Indeed some ISPs go force you to use their own DNS servers only, but that should not prohibit to ping Google, again I would shy away from such an ISP.

 

Thanks for your suggestions anyway. I see if I can come up with something fancy.

 

I have made an update which addresses this issue.

 

Instead of pinging the Google DNS server a wget spider test is done to NCSI (network connection status indicator).

This is the same method as used by Microsoft Windows to update the Internet status in the taskbar.

 

In the process a bit smarter implementation is done to keep hold of the current Internet access state, which speeds up the plugins page updating time.

 

Edited August 4, 2018 by bonienl

When will be the new RC ready to test it?

Also I have seen that even if I can ping 8.8.8.8, there is no "next" release available...

 

Thanks

4 hours ago, thomas said:

When will be the new RC ready to test it?

 

The typical answer is soon (tm).

 

LT doesn't provide a time table, and a next version is released when deemed ready by LT. Patience required