Research Question: can a widely-used, unambiguously legitimate IP address still come back flagged as high-risk on a real reputation check? We ran the query and it did — this is that result, with the actual response, not a hypothetical.
| Test date | August 13, 2026 |
| Tool | NetRiskScan public IP Risk Check API (/api/public/ip/query) |
| Sample | 3 real, independently identifiable IPs |
The result
We queried three well-known, publicly documented addresses through NetRiskScan's own live API and recorded the responses verbatim:
| IP | Known as | Risk score | Purity score | Blacklisted | ISP field | Organization field |
|---|---|---|---|---|---|---|
8.8.8.8 | Google Public DNS | 85 — critical | 10 — dangerous | true | Google LLC | Level 3 |
1.1.1.1 | Cloudflare Public DNS | 33 — medium | 75 — good | false | Cloudflare, Inc. | Cloudflare, Inc. |
104.210.140.135 | Microsoft Azure address block | 33 — medium | 75 — good | false | Microsoft Corporation | Microsoft Corporation |
The 8.8.8.8 result is the interesting one: a critical risk score and an active blacklist flag, on an address that answers billions of legitimate DNS queries a day and is printed on router setup guides worldwide. It's also the only one of the three where the ISP field ("Google LLC") and the Organization field ("Level 3") disagree — Level 3 is the network Google's DNS infrastructure was historically routed through, a real artifact of how registration data and operational reality can diverge for a given address block.
Why this happens
This isn't a bug in the query — it's a real property of how IP reputation data works, and it's exactly what our own IP Reputation guide describes: reputation providers aggregate abuse reports and traffic-pattern signals tied to an address, and a handful of extremely high-traffic, publicly known addresses attract a disproportionate amount of both legitimate and abusive traffic. 8.8.8.8 is a public, open, unauthenticated resolver — anyone can point traffic at it, including automated tools and abusive actors staging requests that get logged as originating from or routed through that address in some providers' data. A "blacklisted" flag reflects that an address appeared on some abuse feed at some point, not that Google's infrastructure is itself compromised.
What this does — and doesn't — tell you
- It doesn't mean 8.8.8.8 is dangerous. It's one of the most heavily used, well-run pieces of internet infrastructure in existence.
- It does mean a single provider's flag is not a verdict. Reputation data is probabilistic and provider-specific; see What Is IP Reputation for why "flagged" and "malicious" are different claims.
- It's a useful sanity check for anyone building on reputation data. If your own workflow would auto-block on this score, this result is a concrete reason to add a second signal (account history, behavior, an allowlist for known infrastructure) rather than trusting IP reputation alone.
Limitations
This is a single snapshot from one provider chain, queried once, on one date. Reputation databases update continuously — a re-run next month could show a different score for any of these three addresses. This result describes what NetRiskScan's configured providers returned on August 13, 2026; it is not a claim about Google's, Cloudflare's, or Microsoft's infrastructure in general, and a provider disagreement or a high score does not by itself prove either the address or the provider is "wrong." See our Methodology page for how these scores are built and their known limits.
Conclusion
"Flagged" and "malicious" are different claims, and this result is a concrete, reproducible example of the gap between them. Check your own address with the IP Risk Check — and if you see a high score on infrastructure you know to be legitimate, this is exactly the pattern to expect from how reputation data is built, not a sign the tool is broken.