Hacker News new | past | comments | ask | show | jobs | submit login

The problem is the archive.is (and other TLDs) server not returning any Good IP if the EDNS client subnet isn't present.

Would like to point out that Cloudflare's resolver is EDNS compliant, it just doesn't send the client subnet.

See: https://twitter.com/archiveis/status/1018691421182791680 (picture of tweet https://aws1.discourse-cdn.com/cloudflare/optimized/3X/8/2/8... )

Based on that tweet, the owner has a personal grudge against Cloudflare and is choosing to return bad results.




I take back every bad thing I have ever said about mailing lists - at least it was easier to follow the drama than these damn twitter links.


My issue with mailing lists is the browsing experience. It's very difficult to view conversations, especially compared to Gmail's threaded view. Seems like something an open source project could solve!


Text of tweet by @archiveis:

"Having to do" is not so direct here. Absence of EDNS and massive mismatch (not only on AS/Country, but even on the continent level) of where DNS and related HTTP requests come from causes so many troubles so I consider EDNS-less requests from Cloudflare as invalid.


For additional context, here is the Cloudflare explanation about EDNS client subnets:

> EDNS Client Subnet > >1.1.1.1 is a privacy centric resolver so it does not send any client IP information and does not send the EDNS Client Subnet Header to authoritative servers.

Cloudflare's requests are of course perfectly valid, with @archiveis actively deciding not to service them.


It has nothing to do with privacy, as the next thing following DNS resolution is establishing a TCP connection which always leaks full IP address to the same person or organization controlling authoritative servers. Basically EDNS is just a convenient way for DNS-based CDNs to provide a better edge node. But this is directly competing with Cloudflare, so Cloudflare invents excuses not to implement something that helps other CDNs.


See the CEO's comment: https://news.ycombinator.com/item?id=19828702

> We’re aware of real world examples where nationstate actors have monitored EDNS subnet information to track individuals, which was part of the motivation for the privacy and security policies of 1.1.1.1.

So it's not just "Cloudflare benefits from pushing anycast" (even if that's part of it).


So, what he claims is that state actors monitor traffic at certain locations, extract subnet information from DNS packets that only large centralized DNS resolvers include when query some authoritative servers that where probed to support that feature. That subnet is not a subnet of an end user IP address, but an IP address of a recursive resolver of that user's ISP. They have to correlate that information with a connection made from that ISP to a web server to track the user. What 1.1.1.1 brings here? State actors now can correlate an actual IP address sending data to 1.1.1.1, with a clear text DNS query going out of it, making tracking more reliable and simple and worse for privacy. And still worse for other CDNs.

Don't take Cloudflare's PR seriously, they are completely full of it. They used to be more honest, but those days are long gone.


1.1.1.1 supports dns/https. It is entirely possible to make a request to 1.1.1.1 for an ip and have nobody be able to know what you made the request for.

There is no guarantee the name server they are querying is the same as the server in the A result, and the idea is to reduce the number of points where people other than the A result and the client know that they plan to talk to each other.

It's not bullshit.


> There is no guarantee the name server they are querying is the same as the server in the A result

That's ok. Let me try to explain a bit more:

Queries to 1.1.1.1 are going over public internet. And even though they are encrypted, they also carry metadata with them, including IP addresses of who is doing them, precise time, rough size, various OS specific stuff, etc. And packets going out to authoritative servers from 1.1.1.1 are in clear text. There is a very tiny window of possible queries out of 1.1.1.1 for encrypted data coming in from some IP address and therefore only a tiny number of possible responses from authoritative servers. Given that and enough intercepted data all over the world it is easy to correlate clear text DNS responses with IP addresses or who got responses from cache and on which popular website ended up, etc.


Not quite as easy as when you just have to intercept traffic at one of the intermediate nodes though, it seems.

I think that makes the privacy argument a fairly valid thing.


You seem to misunderstand it. There are less points to intercept traffic at with 1.1.1.1, than without it. Much more feasible to spy on a massive scale, much less privacy and usefulness of client subnet EDNS option completely disappears. In 1.1.1.1 case it's literally irrelevant for privacy whether they do it or not. 1.1.1.1 already hurts privacy massively and not passing client subnet only hurts competing CDNs.


This is no longer a factual discussion. You mention two separate issues:

1. Use of EDNS client subnet information harms user privacy, by providing information that would not otherwise be there.

2. Many users on a single global DNS provider lowers the amount of points that needs to be attacked to obtain DNS information.

However, you position your statement as if #2 somehow render #1 moot, which is an entirely subjective evaluation from the perspective of a user, and also not at all relevant to the discussion of #1, as that on its own is not 1.1.1.1 specific.

For an example of why this is very subjective, the user may believe that the security of ISP DNS servers is likely not trustable, and that infiltrating countless ISP DNS services would likely be much less work than infiltrating one of the larger providers, such as 1.1.1.1, with better security practices.

The only things relevant to this discussion is whether or not it is sensible to respond with bogus data to a valid request that does not contain optional fields, and separately whether or not it is sensible for a DNS provider to not contain these fields.


That's not true.

Many setups proxy everything but dns traffic.

That's why this topic is a thing.

https://trac.torproject.org/projects/tor/wiki/doc/Preventing...


> the next thing following DNS resolution is establishing a TCP connection which always leaks full IP address to the same person or organization controlling authoritative servers

Depends who runs the authoritative servers - if you hit the authoritative DNS services for most of my domains, you are providing your information to 123-Reg (or, increasingly, Google), if you start a TCP connection, you are providing it to me.


The fallback should be to do GeoDNS based on the resolver's IP. In case of Cloudflare that's certainly good enough, since they've got 150+ POPs.


> requests come from causes so many troubles

Given they serve their pages over tor, I don't buy that explanation at all. Assuming location of client == location of CloudFlare source would give them a rough match in most cases. In tor they're almost guaranteed to be wrong.


Ah yes, the huge trouble of a website that is a few MS slower as opposed to just not working at all.

I’m not sure I see what kind of logic goes into this argument.


Furthermore let's see this report:

https://ednscomp.isc.org/ednscomp/6ed2aca587

EDNS Compliance Tester says that archive.is has some issues.

https://dnsflagday.net

> Minor problems detected! > This domain does not support latest DNS standards.


Could they send "generic" subnet or even better could they let user choose the subnet?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: