Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

As mentioned in the article, they dropped all packets that looked like responses from DNS resolvers. All client applications hosted in cloudfare shouldn't normally receive responses from DNS resolvers.


sort by: page size:

Did you switch to Cloudfare's DNS? IIRC archive.is blocks their DNS servers.

What's especially weird is that they're returning "127.0.0.3" to Cloudflare's DNS, rather than a DNS SERVFAIL or REFUSED error. On most systems that will cause a connection refused error or a TCP timeout. I would assume that was a network issue on their end, not a DNS problem.

I mean, it's archive.is that is intentionally serving an incorrect DNS record (pointing back at Cloudflare's IPs) when it gets a DNS query that every other resolver handles just fine. They may have legitimate grievances with the info being dropped, but in the end they're the ones breaking their own traffic.

Too bad all the DNS traffic just goes to Cloudflare instead of using their own resolvers.

Parent comment was likely referring to authoritative DNS, not Cloudflare's public resolvers.

The Cloudflare DNS-over-HTTPS resolver was serving up 502 errors as well, though the standard port 53 UDP resolver was working. This event definitely made me regret choosing Cloudflare as my sole DoH server.

You're probably using Cloudflare's DNS resolver.

Bear in mind that none of these DNS queries are ever sent out of CloudFlare's network - as mentioned in the previous blog entry, none of these incoming responses are valid.

See http://blog.cloudflare.com/65gbps-ddos-no-problem

" What's great is that we can safely respond and ask them to block all DNS requests originating from our network since our IPs should never originate a DNS request to a resolver. "


Archive.* sabotages their DNS records when Cloudflare queries for them. They don't like that Cloudflare doesn't do EDNS forwarding so they broke their service for people using 1.1.1.1.

That said, I have the same problem. Even hard coding the IP address I resolved through Google doesn't seem to work. I'm guessing their sabotage may have backfired and is causing issues beyond their intentional scope?


Cloudfare isn't making the same claim - they're just saying it doesn't seem to happen on their (modified) Nginx setup.

Yep, any website using CloudFlare's DNS is not resolving.

> I don't use cloudflare DNS but google DNS and got the same problems thant everyone else

Cloudflare is also the authoritative DNS server for many services. If Cloudflare is down, then for those services Google's DNS has nowhere to get the authoritative answers from.


Interestingly, using Cloudflare's dns this morning around 0900 US Eastern time, I got through just fine. And a few hours ago, using DNSWatch, I was able to get through. Trying to muddle through what was happening, I found this: https://webapps.stackexchange.com/questions/135222/why-does-...

Clearly, Cloudflare was resolving it this morning, and it isn't now. Just why, hard to say. I have other things to do, so that's where I bow out...


If true it means that Cloudflare's DNS server can't be trusted.

they're saying that ISPs run malicious DNS resolvers (which is correct), not Cloudflare.

They run their own DNS and if a request comes from Cloudflare's servers return garbage.

They don't work with Cloudflare DNS, that might have something to do with it?

My understanding is that the DNS query goes to the closest of the more than 180 Cloudflare servers, not specifically to the US servers. Complete FUD.

I’m pretty sure it’s cloudflare being bitchy about not receiving some arcane DNS field from archive and therefore blocking their requests.
next

Legal | privacy