The service was blocking our grapheneos.network connectivity check server for a period of time yesterday/today. It was unblocked after users reported it. It's very strange and I think it reflects quite badly on their processes for blocking supposed malware domains.
Conversation
Quad9 receives threat intel feeds from many sources and reputation-scores them, about 4M malware domains with ~400K daily change, while the project only has about a dozen people. We're running about a 1/600,000 false-positive rate, but user reports define the source reputations.
1
2
How is abuse through malicious reporting prevented?
GrapheneOS is being actively attacked by people hostile towards us. The servers are regularly under denial of service attack. It's not at all above them to send in false reports for our domains to different services.
1
1
1
People don't report malicious sites to . Quad9 doesn't do positive attribution of malware, only negative. As I said before, Quad9 sources malware threat intel from many different analysts, receives false-positive reports, and reputation-scores the analysts based on them.
1
So if what you think is happening to you is actually happening to you, check to see which analyst was the source of the false report (from the reporting form on the front page of our web site) and ALSO let them know, so they don't also pass the bad info to others.
1
I don't see a way to check now since the false positive was fixed. I really don't see how the domain could have ended up with a bad reputation in good faith. I find the whole thing quite problematic. If a lot of users used 9.9.9.9 it would have been extremely disruptive.
I'm sure the IP blocks have a bad reputation because they belong to OVH and they hand out a single IPv4 and IPv6 address to each VPS. OVH dedicated servers get a /64 and VPS get a /128. Nothing to do with our domain or the IP addresses we actually have assigned to the server.
1