Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 210 posts

Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)

#71

Post by darkhorn »

judge2020 wrote: post #18

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 person…

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.

Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)

#72

Post by zzzcpan »

judge2020 wrote: post #53
zzzcpan wrote: post #43

Earlier quoted context omitted.

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 help…

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.

Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)

#73

Post by akerl_ »

shawnz wrote: post #60
akerl_ wrote: post #56

Earlier quoted context omitted.

The full IP of the Cloudflare resolver doing the recursive resolution is already provided to the authoritative server, as the source IP for the DNS query traffic.

I think the parent is saying, why not spoof the EDNS client subnet information?

True. Copying the information would be possible, but given they’re working on other efforts to replace the functionality of EDNS ECS in a standard way, it seems like a hacky bandaid.

Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)

#74

Post by jasonhansel »

CodeWriter23 wrote: post #58
eastdakota wrote: post #36

We don’t block archive.is or any other domain via 1.1.1.1. Doing so, we believe, would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service. Archive.is’s authoritative DNS servers return bad results to 1.1.1.1 when we query them. I’ve proposed we just fix it on our end but our team, quite rightly, said that too would violate the integrity of DNS and the…

@eastdakota what about just failing without response on archive.is calls so the second resolver address configured in the client will be used? I understand this is also a DNS integrity violation, however the result for the end user would be either the same if they don’t have a second resolver configured or enhanced if they do. The current effect is I stop using 1.1.1.1 when I need archive.is (often) and set it back t…

Also: it'd be nice if CloudFlare made a secondary DNS resolver (1.1.2.2?) that didn't pass along EDNS information, as a backup for websites like archive.is (and for anyone who cares about privacy).

Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)

#76

Post by Xylakant »

deathanatos wrote: post #70
eastdakota wrote: post #36

We don’t block archive.is or any other domain via 1.1.1.1. Doing so, we believe, would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service. Archive.is’s authoritative DNS servers return bad results to 1.1.1.1 when we query them. I’ve proposed we just fix it on our end but our team, quite rightly, said that too would violate the integrity of DNS and the…

Say you remove/don't proxy the ECS information, and I get some generic, non-geo-location aware response back. In the majority of cases, wouldn't my next step be to open a TCP connection to the IP in the response, and immediately leak my full IP address to the other end? While I get (and appreciate!) the concern for the user's privacy, I'm having a hard time seeing what practical effect not proxying the subnet the use…

> Say you remove/don't proxy the ECS information, and I get some generic, non-geo-location aware response back. In the majority of cases, wouldn't my next step be to open a TCP connection to the IP in the response, and immediately leak my full IP address to the other end?

That assumes that the nameserver and the actual server are run by the same party which quite often is not the case.

Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)

#77

Post by manigandham »

akerl_ wrote: post #73
shawnz wrote: post #60

Earlier quoted context omitted.

I think the parent is saying, why not spoof the EDNS client subnet information?

True. Copying the information would be possible, but given they’re working on other efforts to replace the functionality of EDNS ECS in a standard way, it seems like a hacky bandaid.

EDNS is a working system today, doesn't seem that hacky to use it until a new system is actually ready (which doesn't seem to be anytime soon anyway).

Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)

#78

Post by zamadatix »

akerl_ wrote: post #73
shawnz wrote: post #60

Earlier quoted context omitted.

I think the parent is saying, why not spoof the EDNS client subnet information?

True. Copying the information would be possible, but given they’re working on other efforts to replace the functionality of EDNS ECS in a standard way, it seems like a hacky bandaid.

Is there anywhere I can learn about these ongoing efforts to replace EDNS?

Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)

#80

Post by js2 »

CodeWriter23 wrote: post #58
eastdakota wrote: post #36

We don’t block archive.is or any other domain via 1.1.1.1. Doing so, we believe, would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service. Archive.is’s authoritative DNS servers return bad results to 1.1.1.1 when we query them. I’ve proposed we just fix it on our end but our team, quite rightly, said that too would violate the integrity of DNS and the…

@eastdakota what about just failing without response on archive.is calls so the second resolver address configured in the client will be used? I understand this is also a DNS integrity violation, however the result for the end user would be either the same if they don’t have a second resolver configured or enhanced if they do. The current effect is I stop using 1.1.1.1 when I need archive.is (often) and set it back t…

If you use dnsmasq, you can special case archive.is to not be resolved via 1.1.1.1.
Post reply on HN