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

31–40 of 210 posts

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

#31

Post by arghwhat »

floatingatoll wrote: post #22
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…

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.

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

#32

Post by floatingatoll »

ikeboy wrote: post #21
akerl_ wrote: post #13

Earlier quoted context omitted.

It doesn’t really seem to be the resolvers “using a protocol that [archive.is] doesn’t support”; it seems that archive.is responds to queries from Cloudflare’s systems with an incorrect response. How is Cloudflare meant to work around that kind of behavior?

https://twitter.com/archiveis/status/999788186904576002 claims that cloudflare isn't supporting a protocol that would enable it to work with their servers.

Archive.is does not appear to specify in detail what operational issues result from the missing client subnet EDNS data. We can speculate, though. Is it for data harvesting purposes, or for global load balancing concerns? Are users complaining due to some unknown side effect? Are localized in-country-firewall servers receiving traffic from out-country clients?

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

#33

Post by akerl_ »

ikeboy wrote: post #29
akerl_ wrote: post #25

Earlier quoted context omitted.

That’s not an accurate read of archive.is’s behavior. EDNS is an optional feature. archive.is has configured their nameservers to return invalid (127.0.0.0/8, from the looks of it) responses to Cloudflare requests because they’re protesting Cloudflare’s lack of EDNS, not because EDNS is somehow required to handle the requests. For context: EDNS sends the origin IP address of the DNS client through the resolver. Cloud…

The right thing for cloudflare to do then is fake the EDNS field so that they get a valid response. Maybe cloudflare doesn't want to code an ad-hoc solution just to fix one site. But that doesn't matter to the customer, who just wants it to work.

This diverges pretty hard from your earlier comparison, between this scenario and the Linux kernel breaking userspace.

If a dev updates their code so it won’t run unless an kernel flag is enabled, the kernel hasn’t broken userspace, and kernel devs are unlikely to add a “fake-enabled-flag” to trick the userspace program, even if it’s popular.

Likewise, I don’t expect my DNS resolver to add in custom behavior if upstream DNS servers make breaking changes like this. In fact, I very much prefer the opposite: my DNS service should be as dumb as possible. I don’t want it making choices about how to modify DNS queries I do, or their results.

If an upstream site broke their DNSSEC config, would you lobby for Cloudflare to modify the results so resolution succeeded for their users?

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

#34

Post by ikeboy »

akerl_ wrote: post #33
ikeboy wrote: post #29

Earlier quoted context omitted.

The right thing for cloudflare to do then is fake the EDNS field so that they get a valid response. Maybe cloudflare doesn't want to code an ad-hoc solution just to fix one site. But that doesn't matter to the customer, who just wants it to work.

This diverges pretty hard from your earlier comparison, between this scenario and the Linux kernel breaking userspace. If a dev updates their code so it won’t run unless an kernel flag is enabled, the kernel hasn’t broken userspace, and kernel devs are unlikely to add a “fake-enabled-flag” to trick the userspace program, even if it’s popular. Likewise, I don’t expect my DNS resolver to add in custom behavior if upstr…

If every other resolver works, then I expect Cloudflare to work.

The kernel hardcodes plenty of hacky things to get specific hardware to work.

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

#35

Post by V99 »

regnerba wrote: post #2

Cloudflare returns a proper response for me. nslookup archive.is 1.1.1.1 Server: 1.1.1.1 Address: 1.1.1.1#53 Non-authoritative answer: Name: archive.is Address: 134.119.220.26

It's possible your ISP is intercepting all traffic for port 53 and sending it to their own nameservers (which do send client subset) instead of you actually taking to cloudflare's 1.1.1.1 at all.

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

#36

Post by eastdakota »

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 privacy and security promises we made to our users when we launched the service.

The archive.is owner has explained that he returns bad results to us because we don’t pass along the EDNS subnet information. This information leaks information about a requester’s IP and, in turn, sacrifices the privacy of users. This is especially problematic as we work to encrypt more DNS traffic since the request from Resolver to Authoritative DNS is typically unencrypted. 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.

EDNS IP subsets can be used to better geolocate responses for services that use DNS-based load balancing. However, 1.1.1.1 is delivered across Cloudflare’s entire network that today spans 180 cities. We publish the geolocation information of the IPs that we query from. That allows any network with less density than we have to properly return DNS-targeted results. For a relatively small operator like archive.is, there would be no loss in geo load balancing fidelity relying on the location of the Cloudflare PoP in lieu of EDNS IP subnets.

We are working with the small number of networks with a higher network/ISP density than Cloudflare (e.g., Netflix, Facebook, Google/YouTube) to come up with an EDNS IP Subnet alternative that gets them the information they need for geolocation targeting without risking user privacy and security. Those conversations have been productive and are ongoing. If archive.is has suggestions along these lines, we’d be happy to consider them.

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

#37

Post by ikeboy »

akerl_ wrote: post #33
ikeboy wrote: post #29

Earlier quoted context omitted.

The right thing for cloudflare to do then is fake the EDNS field so that they get a valid response. Maybe cloudflare doesn't want to code an ad-hoc solution just to fix one site. But that doesn't matter to the customer, who just wants it to work.

This diverges pretty hard from your earlier comparison, between this scenario and the Linux kernel breaking userspace. If a dev updates their code so it won’t run unless an kernel flag is enabled, the kernel hasn’t broken userspace, and kernel devs are unlikely to add a “fake-enabled-flag” to trick the userspace program, even if it’s popular. Likewise, I don’t expect my DNS resolver to add in custom behavior if upstr…

Besides, my reading is:

Every other resolver supports EDNS

Archive.is only works with resolvers that support EDNS

Cloudflare decided not to support EDNS

That itself is a defendable decision but I do feel for a popular site they could implement some sort of fix.

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

#38

Post by darkhorn »

https://developers.cloudflare.com/1.1.1.1/nitty-gritty-detai...

>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.

What does this mean?

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

#39

Post by ikeboy »

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…

Are there any other known sites that don't work with 1.1.1.1 but work fine on other resolvers?

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

#40

Post by givinguflac »

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…

Thanks for the detailed response! I think your team is handling this the right way.
Post reply on HN