Quad9 DNS (9.9.9.9) and ThreatSTOP network are currently blocking access to update.ixsystemscom (or to be exact, its CNAME link.storjshareio).
This currently blocks TrueNAS updates from networks using IPS, Malware filtered DNS or other network protection utilizing ThreatSTOP originated lists:
Quad9 blocked domain tester can be used to view current status of link.storjshareio blocking.
ixSystems should work with ThreatSTOP to delist their servers and services from malware blocklist status. And maybe change the system update DNS/URL to be served from bit more reliable in-house resource dedicated for that purpose.
I really think ixSystems should not use link.storjshare dot io for their system updates.
That link domain seems to be used by storj for many purposes. One being links to user originated content (which can be malware). These kind of link/share URLs are prone to be blacklisted and limited.
System update URLs should be dedicated only for that purpose.
If domain/URL is source for malware distribution they really do not have a choice. If you forgivingly leave safe havens for malware distribution the bad actors will immediately rush to use (/abuse) it. The policy is not idiotic.
One solution would be to use hashed subdomain names such as (hash).link.storjshare for customer originated content. Then domain based blacklisting could be more accurately applied to each of those individual subdomains.
In this case I suspect that StorJ linksharing facilitated distribution of something malicious using only a hashed path under the main domain link.storjshare dot io.
Blocking Storj is kind of like blocking DropBox, or Google Drive.
Just because someone might be able to upload something bad there, it in no way means the domain itself is malicious. Drive and Dropbox can be (and are) used for malware delivery.
I’ve raised a support case with Quad9 to get this removed as there’s not really any reason they should be blocking it.
There is one workaround for those with internal nameservers that can be used to spoof address resolution.
Problem is not with update.ixsystems dot com domain, but rather with the CNAME record that it points to: link.storjshare dot io - its blocked. That however further resolves to single IPv4 address. By bypassing this CNAME and resolving the update.ixsystems domain directly to A record bypasses the blocking issue.
With unbound DNS resolver I used this configuration to bypass the problematic CNAME record that has been blacklisted by malware guards:
server:
local-zone: "update.ixsystems.com." redirect
local-data: "update.ixsystems.com. 360 IN A 185.244.226.2"
(note that IPv4 above is region specific and not be the correct one in your case)
This way I was successful in upgrading TrueNAS SCALE devices in our internal network while still maintaining Quad9 DNS filtering.
Maybe ixSystems can also bypass the CNAME and link directly to their server with A record? And solve this quickly.
I still think that sharing domain/URL for customer originating content URLs and internal system update URLs is not good practice. TrueNAS OS update checks should have more robust infrastructure for their domains that is not subject to be blocked by content published by others.
I’ve pinged Storj on this as well. The linksharing service is how you use Storj as a CDN, and shouldn’t be blocked any more than other CDN providers are.
