You type a URL. You expect it to load. That’s the deal we’ve all silently accepted with DNS — the internet’s phonebook answers your question, and you go about your day.
But what happens when the phonebook gives you a different answer depending on which page you flip to?
This isn’t a hypothetical. It’s happening right now, and it exposes a crack in the foundation of how DNS-based security actually works.
Last week, someone ran a simple diagnostic on opencode.ai using Cloudflare’s public DNS resolvers. The results should make you uncomfortable.
dig +short opencode.ai @1.1.1.1 returns a clean set of IP addresses: 172.65.90.20 through .23. The site exists. It resolves. Everything works as expected.
dig +short opencode.ai @1.1.1.2 returns 0.0.0.0. That’s not a real IP. That’s a kill shot. In DNS security terms, 0.0.0.0 means “this domain is dangerous, and we’re protecting you from it.”
Same company. Same resolver system. Same domain. Two completely different verdicts.
A 0.0.0.0 response isn’t just a block — it’s a digital death sentence handed down by an invisible jury that can’t even agree on a verdict.
Here’s where most people would jump to the obvious question: “Is opencode.ai actually malicious?” VirusTotal flags it. Some threat feeds have it categorized as bad. Fair enough.
But that’s not the real story. The real story is what happens when you realize Cloudflare — the company positioning itself as the internet’s neutral infrastructure backbone — is running multiple threat classification systems that don’t talk to each other.
1.1.1.1 is Cloudflare’s standard DNS resolver. 1.1.1.2 is their malware-blocking variant. 1.1.1.3 blocks adult content. They’re supposed to be the same system with different filter layers stacked on top.
Except they’re not. They’re pulling from different threat feeds, applying different classification criteria, and producing contradictory results — all while presenting themselves to users as a single, coherent service.
When the tool that’s supposed to protect you can’t even agree with itself, trust becomes a luxury you can’t afford.
Think about what this means in practice. You’re a developer who relies on opencode.ai. You’ve been using Cloudflare’s 1.1.1.2 resolver because you want the malware protection. One day, the site stops loading. No error page. No explanation. Just silence.
You spend hours debugging your code, your network, your firewall. You never think to question the DNS resolver because — why would you? It’s infrastructure. It’s supposed to be invisible.
But the invisibility is the problem. When security decisions happen at the DNS layer, there’s no transparency. No appeal process. No notification to the site owner saying “hey, we’re blocking you.” Just a 0.0.0.0 and a shrug.
And here’s the twist that should genuinely unsettle you: Cloudflare’s own Radar platform — their threat intelligence dashboard — doesn’t even show opencode.ai as classified as malicious. So within Cloudflare’s own ecosystem, three different systems have three different opinions about the same domain.
The resolver says it’s fine. The malware filter says it’s dangerous. The threat intelligence dashboard says it’s clean. Three departments. Three verdicts. Zero coordination.
The scariest part isn’t that Cloudflare blocked a legitimate site. It’s that they don’t even know they disagree with themselves.
This isn’t just about opencode.ai. That domain is a case study, not the thesis. The thesis is that DNS-based security is fundamentally opaque, and the companies running these systems have no incentive to fix the transparency problem because most users will never run a dig command.
Most people will just assume the site is down. Or that their internet is broken. Or that the site is “sketchy.” The damage is done silently, and the victim never even knows who pulled the trigger.
If you’re using Cloudflare’s 1.1.1.1 or 1.1.1.2 — or any DNS-based security service — you need to understand something: your access to any given website may depend on which IP you happen to hit on a given day. The same resolver, queried twice, can give you two different internets.
That’s not a feature. That’s a systemic flaw dressed up as security.
The fix isn’t complicated in theory. Threat feed aggregation should be consistent across resolver variants. Classification criteria should be documented. Site owners should be notified when they’re blocked. Users should be able to see why a domain was flagged.
But none of that will happen until enough people notice. And people won’t notice until they realize the internet they see isn’t necessarily the internet that exists.
Security theater works great until the audience notices the strings. Cloudflare’s strings are showing.
Run the dig commands yourself. Check your results across multiple resolvers. And next time a site won’t load, remember: the problem might not be the site. It might be the invisible gatekeeper who can’t make up its mind.
FAQ
Q: Is opencode.ai actually malware?
A: It's flagged by some threat feeds on VirusTotal, but Cloudflare's own Radar platform doesn't classify it as malicious. The inconsistency is the point — nobody can give you a straight answer, including Cloudflare itself.
Q: What should I do if a site won't load and I'm using Cloudflare DNS?
A: Run a dig command against multiple resolvers (1.1.1.1, 1.1.1.2, 8.8.8.8, 9.9.9.9). If you get different results, you're hitting a DNS-level block, not a real outage. Switch resolvers or query the domain directly.
Q: Isn't it acceptable for security filters to have false positives?
A: False positives happen. What's unacceptable is having three different systems within the same company produce three different verdicts for the same domain with no transparency, no notification to the site owner, and no way for users to understand why they're being blocked. That's not a false positive — that's a broken system.