15 ms·

Why does 1.1.1.1 not resolve archive.is?

313 points by stargrave 7y ago

ggm 7y ago
ECS is not equivalent to 'send the IP' but is revealing. the fact that I subsequently connect to another place over HTTP or some other protocol is distinct from telling a DNS authority who is asking a question about a domain name: the article implies "its the same leakage" but it isn't: different people get told.
- cnst 7y ago
  What's the actual meaningful difference, though? ECS is limited to a /24 anyways, so, it doesn't even reveal the exact IP address in any case.
  - ggm 7y ago
    Thats a good question. How you feel about third parties knowning what endpoints you go to depends on what endpoints you're going to, and why. In some economies, its hugely informing. In many cases its explicitly what BI is -to know what you do, and when you do it. I don't have good sense of this, but people I trust say a surprisingly small collection of information identifies you to a specific level. same /24 is only 255 people if there isn't a CGN. More to the point, if your /24 identifies your economy, you're now subject to IPR limits and can be told different things. So some ECS objection is rooted in opposition to regional IPR. Netflix. Sub-optimal CDN delivery (to one person) is wall avoidance (to another)
    - cnst 7y ago
      What exactly do you use DNS for? Most folks use it to resolve a domain name so that they can make an HTTP and/or HTTPS requests from the very same IP address over the very same internet connection. Surprise: these subsequent HTTP/HTTPS requests would have your complete identifying information down to the very specific /32 IPv4 or /128 IPv6 address uniquely assigned to yourself. So, in reality, the extra privacy gained from not doing ECS is hardly something with a measurable effect, because this information HAS to leak in any case. Even if make DNS encrypted, even if you employ encrypting TLSv1.3 SNI, the IP addresses will still leak, and with a much higher precision anyways. So, this we-don't-do-ECS-because-privacy is a rather pointless statement in the end.
      - rvnx 7y ago
        +1 @cnst, what privacy concerns are you all afraid of with ECS ? archive.is will get informed that someone around IP range A.B.x.x tries to reach its website, just a few seconds later to see a connection from A.B.C.D. The main reason that Cloudflare wouldn't share this info is to prevent competitors like Akamai to operate a CDN as good as them. It looks more like sabotaging competition than increasing privacy.
        FDSGSG 7y ago
        In practice this is one of the most common techniques used to deanonymize proxy users.
        cnst 7y ago
        How? If your client is leaking DNS outside of the confines of the proxy you're using, you've got bigger problems than ECS.
        FDSGSG 7y ago
        I don't disagree about DNS leaks being a separate problem, that doesn't change anything about what I said though.
        cnst 7y ago
        > The main reason that Cloudflare wouldn't share this info is to prevent competitors like Akamai to operate a CDN as good as them. It looks more like sabotaging competition than increasing privacy. Exactly. Their own answers in the threads over here at HN are basically admitting as much — they claim to be working on solutions alternative to ECS, because Google and some others have more PoPs than Cloudflare does. They're obviously using this as a competitive advantage to slow down competing CDNs. And noone's talking about!
  - vavrusa 7y ago
    Disclaimer: I work on 1.1.1.1. You might not consider your /24 as personally identifying, but others might. The original RFC discusses these problems fairly well (https://tools.ietf.org/html/rfc7871 https://tools.ietf.org/html/rfc7871, Privacy notice and privacy considerations). Frank Denis also wrote a good summary on ECS (https://00f.net/2013/08/07/edns-client-subnet/ https://00f.net/2013/08/07/edns-client-subnet/). There's a multitude of ways to fix this - use a whitelist of nameservers to send ECS to to avoid spraying the source prefix everywhere, encrypt the whitelisted connections, or aggregate the source prefix into a largest covering server scope (e.g. if the client is in /24 but nameserver serves the same answer for /16, then using any address in the /16 would do). We're evaluating all of them as there's different trade-offs (see https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-https-doh-update-recent-testing-results-and-next-steps/ https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-...).
    - breakingcups 7y ago
      What do you say to the very often heard criticism that the exact IP address will be leaked the moment the user establishes a TCP connection to the domain they just looked up?
      - vavrusa 7y ago
        Hi, I answered it in another comment below.
    - the8472 7y ago
      How about looking up the client's AS via BGP or whois and broadening the scope so that it matches its net block? Then if a CDN peering with a particular ISP wants more granular DNS load balancing they could ask the ISP to announce their routes by region or something like that.
    - GrayShade 7y ago
      I haven't really looked into EDNS, but can't you send fake the EDNS that points to a Cloudflare PoP close to the user (thus giving them a Cloudfare address)?
  - deleted 7y ago
    [deleted]
  - majewsky 7y ago
    Even if ECS only reveals your /24, immediately afterwards you're going to connect to the service with your own IP, so Eve can correlate the pair of domain name and /24 from the ECS request with the source IP from the TCP connection to match your IP with the domain name you're navigating to.
    - vavrusa 7y ago
      This is not the privacy concern, check out the https://tools.ietf.org/html/rfc7871#section-11.1 https://tools.ietf.org/html/rfc7871#section-11.1 discussing it. Yes, if you open a connection to the target IP, then all transit networks between client and the target IP (including the target itself) know who is talking. These are on-path parties. The main (privacy) issue with ECS is not this, but that it shares client's subnet with potentially every nameserver on the referral path (including transit networks between the recursive and nameserver), for every name client looks up (even when it might not support ECS). The client is also not in control of the prefix length. /24 for IPv4 is a recommended default, but the recursive may use however much it wants and there's no way to prove to the client that it didn't. Opt-out is also difficult (afaik only getdns and Firefox clients support an opt-out).
      - the8472 7y ago
        > but that it shares client's subnet with potentially every nameserver on the referral path [...] for every name client looks up Does CF DNS not use qname minimization? That would reduce the association between subnets and names looked up.
amarshall 7y ago
Previous discussion concerning this, which includes replies from Cloudflare: https://news.ycombinator.com/item?id=19828317 https://news.ycombinator.com/item?id=19828317
- dvfjsdhgfv 7y ago
  The author of the post specifically addresses these replies from Cloudflare.
- cnst 7y ago
  > 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. I actually forgot to consider this angle, as the discussion was centred at archive.is. I'd imagine 1.1.1.1 has a very negative consequences for Netflix local caches, for example. This is where your local homegrown provider gets to save significant $$$$ due to interconnect/bandwidth costs by hosting a local Netflix cache through their appliance, and you get to benefit by the latest shows being locally cached, delivered at maximum speeds, instead of being hailed through the whole internet each time for each device. If you're using 1.1.1.1, you're basically not only making sure that your internet will be much slower due to suboptimal CDN performance by any CDN other than Cloudflare CDN, but that you're also going to needlessly be running extra simultaneous streams of your favourite shows instead of fetching a local copy from your own ISP, increasing the cost of bandwidth transit to your ISP. And, remember, you don't actually get any extra privacy by bypassing ECS in the first place, because your exact full IP address will have to be used to establish any subsequent TCP or UDP connections to make those requests for actual content in any case. You're basically breaking the whole internet by using 1.1.1.1, all for no real benefit! It's worse than we initially thought!
  - throw0101a 7y ago
    > I'd imagine 1.1.1.1 has a very negative consequences for Netflix local caches, for example. Is it possible for Netflix to use anycast? For their appliances they can advertise to an ISP's routers via (i/e)BGP or OSPF / IS-IS to keep traffic internal, but have a fallback of having a presence in various IXPs. Isn't this how Cloudflare works, anycast?
deleted 7y ago
[deleted]
- deleted 7y ago
  [deleted]
deleted 7y ago
[deleted]
darklajid 7y ago
I'm with some of the people on Twitter: It seems weird (to put it mildly) to just blackhole your own site with no explanation whatsoever to the end-user. For everyone on 1.1.1.1 archive.is will now be "down" and they're none the wiser. Maybe there's a big backstory here, but without context that seems passive-aggressive and quite random?
- profmonocle 7y ago
  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.
  - majewsky 7y ago
    SERVFAIL or REFUSED is also not helpful to the end user. They should return the IP of a host serving a static single-page website explaining the issue.
    - zamadatix 7y ago
      REFUSED will trigger a lookup on the next DNS server in the list, which may not be Cloudflare, instead of guaranteeing the user can't go to the real page.
- spzb 7y ago
  Indeed. This is the first I'd heard of this situation. I'd previously just assumed archive.is was a shonky service that didn't work properly. Hadn't connected it with my use of 1.1.1.1
viraptor 7y ago
> massive mismatch (...) of where DNS and related HTTP requests come from causes so many troubles Does anyone know what they could mean here? I get that having more open connections and slow requests is not great, but there are popular attacks people will try against them in this case. They already have to handle pathologic cases of slow requests, so handling some small number of slower clients shouldn't be an issue. Or are they talking about some other problem?
- miyuru 7y ago
  They are taking about Geo load balancing via DNS.[1] Just try one of the akamai endpoints to test it. (E.g media.steampowered.com) For me 1.1.1.1 serves akamai singapore IPs, while 8.8.8.8 serves IPs of my ISPs akamai cache in Sri Lanka. If your ISP has a bad route to 1.1.1.1, this just gets worse. [1] https://en.wikipedia.org/wiki/GeoDNS https://en.wikipedia.org/wiki/GeoDNS
  - profmonocle 7y ago
    Blocking a user because the site might load more slowly for them doesn't make any sense to me. If the user is choosing to use a DNS server that returns sub-optimal CDN IPs, isn't that their problem?
    - oarsinsync 7y ago
      > If the user is choosing to use a DNS server that returns sub-optimal CDN IPs How many users are explicitly choosing that? How many users are actually choosing something very different, and this is an unintended consequence of their choice, that they would otherwise be unaware of if not for this provider taking a stand?
      - dwild 7y ago
        > How many users are explicitly choosing that? How many users are actually choosing something very different, and this is an unintended consequence of their choice, that they would otherwise be unaware of if not for this provider taking a stand? Not sending anything at all doesn't solve any of this. If a message was shown explaining the situation, sure, but archive.is solution doesn't answer your question at all.
LeoNatan25 7y ago
This is the reason I stopped using 1.1.1.1.
- pnako 7y ago
  Quad9 has a variant, 9.9.9.11 that works well with CDNs.
- nobodyshere 7y ago
  A very silly one at that given their reasons for not resolving archive.is are quite rational and on the contrary makes me want to swap google's DNS servers for theirs.
  - cnst 7y ago
    What exactly do you use DNS for? If it's to subsequently make a HTTP and/or HTTPS request, then your full IP address (and not just a /24 subnet) will be leaked to the very same parties anyways. Even if they eventually make DNS encrypted, even if encrypting TLSv1.3 SNI work properly (and both of these are pretty big ifs, BTW), the IP addresses will still leak, always, and with a much higher precision anyways. So, this we-don't-do-ECS-because-privacy is hardly a rational statement on Cloudflare's part in the end — it merely breaks the performance of their competitor CDNs without any real privacy angle.
    - zamadatix 7y ago
      DNS isn't always run by the place the site is hosted and until the other 2 are implemented everyone along the lookup path can also see where you are going. Increasingly a destination IP is becoming less of a hint of what you are browsing to. Whether you think that's enough to care about or not it's very different than the picture you painted.
  - tambre 7y ago
    > their reasons for not resolving archive.is They do solve archive.is. But archive.is's DNS servers have been configured to return bogus answers to queries from Cloudflare's servers.
Santosh83 7y ago
I'm using Cloudflare's DoH service built into Firefox and archive.is is resolvable.
- Operyl 7y ago
  I think that's because Firefox falls back to system resolver if something funky happens. I'm using it strictly over DoH and it isn't working for me still.
- deleted 7y ago
  [deleted]
jchw 7y ago
I am no expert by any means. However, I strongly suspect EDNS is not actually needed to run a CDN. There’s a lot of approaches to balancing load and distributing traffic. An example of another approach would be using anycast IPs. I’m also surprised that traffic from Cloudflare DNS users caused any significant problem. Was it really that much traffic?
- profmonocle 7y ago
  > However, I strongly suspect EDNS is not actually needed to run a CDN. It's not. The proof is that CDNs existed long before edns-client-subnet was introduced. All it does is allow the CDN's DNS servers to return the most optimal A/AAAA records for the client. But the worst that should happen without it is you get sent to a more distant CDN server, and the content loads more slowly. The fact that archive.is somehow suffers without this feature (which, btw, wasn't standardized until 2016) suggests they're doing something really, really odd. If I were them, I'd focus on making my system more robust, rather than demanding the rest of the Internet adopt a relatively young, optional DNS extension.
  - cnst 7y ago
    Per https://serverfault.com/a/560059/110020 https://serverfault.com/a/560059/110020, Google's 8.8.8.8 has had support for `edns0-client-subnet` since at least 2013, so, even if it's only been standardised in 2016, it's been a de-factor standard for quite a while, especially in the internet-technology-years. Here's an interesting thought — if it's so bad for privacy and isn't necessary for a CDN, does Cloudflare the CDN simply disregard ECS when receiving requests from DNS.Google, or do they take it into account?
    - DarkWiiPlayer 7y ago
      > de-factor standard Google isn't the internet, you know?
    - profmonocle 7y ago
      > even if it's only been standardised in 2016, it's been a de-factor standard for quite a while, especially in the internet-technology-years. If archive.is thinks that Internet standards should be adopted so quickly, it's weird that they don't support IPv6 considering it's been a standard since 1998! Obviously I'm kidding, but only kind of. When it comes to insisting on adopting new standards, edns-client-subnet is a weird hill to die on, especially considering it was always meant to be optional. > does Cloudflare the CDN simply disregard ECS when receiving requests from DNS.Google, or do they take it into account? I don't think they have a reason to use it because they use TCP anycast. Looking at https://cachecheck.opendns.com/ https://cachecheck.opendns.com/ they seem to return the same IPs regardless of geography.
profmonocle 7y ago
> I consider EDNS-less requests from Cloudflare as invalid. If your site depends on a DNS extension that's only 3.5 years old (and designed to be optional), I think it's fair to say your site is just offline for some users due to a config mistake. You're free to set up your servers however you like, but there's wisdom in Postel's law.
- rumanator 7y ago
  > there's wisdom in Postel's law. For the lazy like me: robustness principle, aka Postel's law https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle Thank you for the reference. I learned something today!
  - cmroanirgo 7y ago
    Thanks for the link, for which there's the counter-argument, "The Harmful Consequences of the Robustness Principle" [0]: > A flaw can become entrenched as a de facto standard. Any implementation of the protocol is required to replicate the aberrant behavior, or it is not interoperable. This is both a consequence of applying Postel's advice, and a product of a natural reluctance to avoid fatal error conditions. [0] https://tools.ietf.org/html/draft-iab-protocol-maintenance-01 https://tools.ietf.org/html/draft-iab-protocol-maintenance-0...
- Thorrez 7y ago
  Archive.is does not block all requests lacking EDNS. They specifically block requests coming from Cloudflare's datacenters. Cloudflare is not accidentally misconfiguring their EDNS, Cloudflare is intentionally not sending EDNS.
  - Operyl 7y ago
    They’re intentionally not sending an optional extension, that seems .. fair honestly.
    - 7y ago
vesche 7y ago
Roads...? Where we're going, we don't need roads.
nindalf 7y ago
This link and the two answers within demonstrate something important, broader than the DNS related issue at hand. Both make implicit assumptions. One assumes the worst of Cloudflare and thinks “what’s the worst reason Cloudflare could have for doing this. How do they profit off this?” And the other assumes that Cloudflare has good intentions. Neither answer is technically wrong. Both flow logically from their initial assumptions. But it shows how different our conclusions can be depending on where our initial biases lie. For the person who believes the first answer and says “prove to me that Cloudflare isn’t doing something nefarious”, it’s not possible. The analysis is correct and can’t be challenged unless the initial assumption is challenged. And for people who strongly believe that Cloudflare has bad intentions, nothing can be done to change their mind. In this example it’s Cloudflare but it applies to any person or organisation that we feel strongly about.
- cheschire 7y ago
  The second one is not an assumption, it's Cloudflare's official position. For a person who is against Cloudflare, I feel like this would only serve to reinforce the confirmation bias as there's seemingly no person except a Cloudflare employee willing to step up and defend the action. So, yes, good observation.
  - nindalf 7y ago
    Arguably, no one except a Cloudflare employee could know the reason why they took this decision. A random person speculating “maybe they did this for privacy reasons” doesn’t strike me as better than Cloudflare saying “we did this for privacy reasons”. And while the second answer is a statement, not an analysis the rest of what I said holds. You will only accept their statement as the truth if you assume good intent of them.
    - 113 7y ago
      Corporations operate for profit.
      - 7y ago
deleted 7y ago
[deleted]
tedk-42 7y ago
I really don't see this as a problem of Cloudflare. End users switching to Cloudflare's DNS endpoint are doing so because they feel the DNS provider is both faster and more secure. They rightly made the decision NOT to pass on the end user's IP information to the upstream DNS server. I agree with this decision and they are acting in my best interests in doing so. To draw some kind of nefarious intention from this is absurd. Until Cloudflare are proven to be nefarious actors, I'll continue to use their service.
- varelaz 7y ago
  That looks like uncompetitive behavior from Cloudflare, so it's their problem also. Cloudflare can send EDNS if nameserver and the actual server run by the same party, but they don't
  - zzzcpan 7y ago
    Well, yeah. This was one of the significant reasons against Cloudflare's DoH too. They want all Firefox users to use their DNS resolver and deprive the ability of competing DNS-based CDNs (most CDNs) to pick good nodes in Firefox. I've been thinking of blacklisting Cloudflare completely on all of my servers just for that. And it seems Firefox will even be able to detect that and fallback to proper DNS for such domains.
- oarsinsync 7y ago
  > They rightly made the decision NOT to pass on the end user's IP information to the upstream DNS server. I agree with this decision and they are acting in my best interests in doing so. To draw some kind of nefarious intention from this is absurd. In this instance, the upstream DNS server and the resultant HTTP server are operated by the same organisation. Cloudflare have opted to not provide the /24 (or /56 if IPv6) network that the original DNS request came from, in the DNS request. Your computer will then provide the /32 (or /128 if IPv6) that your request is coming from when you connect to the HTTP server. What privacy win have you gained by Cloudflare not providing that information in this instance?
  - 7y ago
cm2187 7y ago
I don’t understand the privacy reason. If I am querying for domain x, why does it matter that domain x’s DNS servers know what IP I am querying them from? I am going to hit their web server directly with that very same IP in a few milliseconds anyway.
- tomatocracy 7y ago
  There are a few reasons. Here are three I can think of off the top of my head: Many browsers prefetch DNS for links on webpages these days. So it’s entirely possible and even common that you may query DNS for sites you never visit, which would indeed be a privacy leak. Secondly, many sites have their DNS hosted elsewhere so it may not be the same people you are leaking the information to. Thirdly, if the DNS query is transmitted to the site’s DNS servers in plain text (which most DNS is), then despite eSNI etc anyone who has access to the wire traffic along the route from the DNS proxy to the site’s DNS servers (which is probably different from the route your own traffic takes to their servers) can see which site you wanted to access.
varelaz 7y ago
I think decision of archive.is is very interesting. 1) They attracted a lot of attention; 2) They showed the way to struggle with Cloudflare business that abuse their service. If several bigger CDNs like akamai or softlayer will consider requests from 1.1.1.1 without EDNS as invalid and block them, Clouldflare wouldn't be able just to say that it's their own problems
deleted 7y ago
[deleted]
PeterStuer 7y ago
Not sure why this is a link to stackexchange as the second answer is lifted from the previous HN discussion on the topic https://news.ycombinator.com/item?id=19828317 https://news.ycombinator.com/item?id=19828317
chaitanya 7y ago
Does 1.1.1.1 send ECS info to Cloudflare’s own nameservers? More generally, does 1.1.1.1 in any way treat Cloudflare’s own nameservers in a special way and send it information that it doesn’t send to others? If the answer to these questions is no, then Cloudflare’s reasons for blocking ECS (ie privacy) carry weight. Otherwise no.
- aeyes 7y ago
  When using 1.1.1.1 as resolver Cloudflare has your full IP. So they can fully track you. ECS doesn't even forward the IP, only the /24.
- jgrahamc 7y ago
  > Does 1.1.1.1 send ECS info to Cloudflare’s own nameservers? No > More generally, does 1.1.1.1 in any way treat Cloudflare’s own nameservers in a special way and send it information that it doesn’t send to others? No
known 7y ago
Is adding "62.192.168.106 archive.is" to /etc/hosts a work around?
- known 7y ago
  I added 217.79.184.91 archive.is to /etc/hosts and did sudo service systemd-resolved restart It works;
bastawhiz 7y ago
A lot of folks here seem to be saying "if you're going to make a DNS query, you're only going to make a HTTP request," which is simply untrue. Hell, you can add a HTML tag to your page to prefetch DNS queries. Browsers prefetch DNS just for hovering your mouse over a link or typing something into your address bar (without actually navigating). Should some DNS server know your IP address just because you moved your mouse over a link? IMO, no.
- jiveturkey 7y ago
  I don't understand what side you're taking here. Please can you rephrase your argument. 100% serious, I'd like to know what point you're making. Pre-emptively: because whatever DNS server you are using already knows your IP address, regardless whether it's the first query for the site itself, or subsequent queries for site-related additional resources.
  - tracker1 7y ago
    If you hover your mouse over an ad linking to sketchy-service.com ... then the remote dns host for sketchy-service.com now has your IP address.
    - jiveturkey 7y ago
      That seems neither here-nor-there for the 1.1.1.1 service. Doesn't the browser's internal resolver use an external recursive server (either the host's configured ones or browser-determined ones)? Chrome does, AFAICT. As opposed to being a recursive resolver itself, it just implements a caching stub resolver. The remote DNS host for sketchy-service.com doesn't see your IP address, they see the recursive server's address.
    - joveian 7y ago
      Browsers can also prefetch pages under some circumstances (I'm not sure of the details). In that case, the web server for sketchy-service.com now has your exact IP address (vs. the truncated address encouraged by this extension). In firefox this can be prevented with: network.dns.disablePrefetch True network.prefetch-next False

313 points by stargrave 7y ago

ggm 7y ago

ECS is not equivalent to 'send the IP' but is revealing. the fact that I subsequently connect to another place over HTTP or some other protocol is distinct from telling a DNS authority who is asking a question about a domain name: the article implies "its the same leakage" but it isn't: different people get told.

cnst 7y ago
What's the actual meaningful difference, though? ECS is limited to a /24 anyways, so, it doesn't even reveal the exact IP address in any case.
- ggm 7y ago
  Thats a good question. How you feel about third parties knowning what endpoints you go to depends on what endpoints you're going to, and why. In some economies, its hugely informing. In many cases its explicitly what BI is -to know what you do, and when you do it. I don't have good sense of this, but people I trust say a surprisingly small collection of information identifies you to a specific level. same /24 is only 255 people if there isn't a CGN. More to the point, if your /24 identifies your economy, you're now subject to IPR limits and can be told different things. So some ECS objection is rooted in opposition to regional IPR. Netflix. Sub-optimal CDN delivery (to one person) is wall avoidance (to another)
  - cnst 7y ago
    What exactly do you use DNS for? Most folks use it to resolve a domain name so that they can make an HTTP and/or HTTPS requests from the very same IP address over the very same internet connection. Surprise: these subsequent HTTP/HTTPS requests would have your complete identifying information down to the very specific /32 IPv4 or /128 IPv6 address uniquely assigned to yourself. So, in reality, the extra privacy gained from not doing ECS is hardly something with a measurable effect, because this information HAS to leak in any case. Even if make DNS encrypted, even if you employ encrypting TLSv1.3 SNI, the IP addresses will still leak, and with a much higher precision anyways. So, this we-don't-do-ECS-because-privacy is a rather pointless statement in the end.
    - rvnx 7y ago
      +1 @cnst, what privacy concerns are you all afraid of with ECS ? archive.is will get informed that someone around IP range A.B.x.x tries to reach its website, just a few seconds later to see a connection from A.B.C.D. The main reason that Cloudflare wouldn't share this info is to prevent competitors like Akamai to operate a CDN as good as them. It looks more like sabotaging competition than increasing privacy.
      - FDSGSG 7y ago
        In practice this is one of the most common techniques used to deanonymize proxy users.
        cnst 7y ago
        How? If your client is leaking DNS outside of the confines of the proxy you're using, you've got bigger problems than ECS.
        FDSGSG 7y ago
        I don't disagree about DNS leaks being a separate problem, that doesn't change anything about what I said though.
      - cnst 7y ago
        > The main reason that Cloudflare wouldn't share this info is to prevent competitors like Akamai to operate a CDN as good as them. It looks more like sabotaging competition than increasing privacy. Exactly. Their own answers in the threads over here at HN are basically admitting as much — they claim to be working on solutions alternative to ECS, because Google and some others have more PoPs than Cloudflare does. They're obviously using this as a competitive advantage to slow down competing CDNs. And noone's talking about!
- vavrusa 7y ago
  Disclaimer: I work on 1.1.1.1. You might not consider your /24 as personally identifying, but others might. The original RFC discusses these problems fairly well (https://tools.ietf.org/html/rfc7871 https://tools.ietf.org/html/rfc7871, Privacy notice and privacy considerations). Frank Denis also wrote a good summary on ECS (https://00f.net/2013/08/07/edns-client-subnet/ https://00f.net/2013/08/07/edns-client-subnet/). There's a multitude of ways to fix this - use a whitelist of nameservers to send ECS to to avoid spraying the source prefix everywhere, encrypt the whitelisted connections, or aggregate the source prefix into a largest covering server scope (e.g. if the client is in /24 but nameserver serves the same answer for /16, then using any address in the /16 would do). We're evaluating all of them as there's different trade-offs (see https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-https-doh-update-recent-testing-results-and-next-steps/ https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-...).
  - breakingcups 7y ago
    What do you say to the very often heard criticism that the exact IP address will be leaked the moment the user establishes a TCP connection to the domain they just looked up?
    - vavrusa 7y ago
      Hi, I answered it in another comment below.
  - the8472 7y ago
    How about looking up the client's AS via BGP or whois and broadening the scope so that it matches its net block? Then if a CDN peering with a particular ISP wants more granular DNS load balancing they could ask the ISP to announce their routes by region or something like that.
  - GrayShade 7y ago
    I haven't really looked into EDNS, but can't you send fake the EDNS that points to a Cloudflare PoP close to the user (thus giving them a Cloudfare address)?
- deleted 7y ago
  [deleted]
- majewsky 7y ago
  Even if ECS only reveals your /24, immediately afterwards you're going to connect to the service with your own IP, so Eve can correlate the pair of domain name and /24 from the ECS request with the source IP from the TCP connection to match your IP with the domain name you're navigating to.
  - vavrusa 7y ago
    This is not the privacy concern, check out the https://tools.ietf.org/html/rfc7871#section-11.1 https://tools.ietf.org/html/rfc7871#section-11.1 discussing it. Yes, if you open a connection to the target IP, then all transit networks between client and the target IP (including the target itself) know who is talking. These are on-path parties. The main (privacy) issue with ECS is not this, but that it shares client's subnet with potentially every nameserver on the referral path (including transit networks between the recursive and nameserver), for every name client looks up (even when it might not support ECS). The client is also not in control of the prefix length. /24 for IPv4 is a recommended default, but the recursive may use however much it wants and there's no way to prove to the client that it didn't. Opt-out is also difficult (afaik only getdns and Firefox clients support an opt-out).
    - the8472 7y ago
      > but that it shares client's subnet with potentially every nameserver on the referral path [...] for every name client looks up Does CF DNS not use qname minimization? That would reduce the association between subnets and names looked up.

amarshall 7y ago

Previous discussion concerning this, which includes replies from Cloudflare: https://news.ycombinator.com/item?id=19828317 https://news.ycombinator.com/item?id=19828317

dvfjsdhgfv 7y ago
The author of the post specifically addresses these replies from Cloudflare.
cnst 7y ago
> 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. I actually forgot to consider this angle, as the discussion was centred at archive.is. I'd imagine 1.1.1.1 has a very negative consequences for Netflix local caches, for example. This is where your local homegrown provider gets to save significant $$$$ due to interconnect/bandwidth costs by hosting a local Netflix cache through their appliance, and you get to benefit by the latest shows being locally cached, delivered at maximum speeds, instead of being hailed through the whole internet each time for each device. If you're using 1.1.1.1, you're basically not only making sure that your internet will be much slower due to suboptimal CDN performance by any CDN other than Cloudflare CDN, but that you're also going to needlessly be running extra simultaneous streams of your favourite shows instead of fetching a local copy from your own ISP, increasing the cost of bandwidth transit to your ISP. And, remember, you don't actually get any extra privacy by bypassing ECS in the first place, because your exact full IP address will have to be used to establish any subsequent TCP or UDP connections to make those requests for actual content in any case. You're basically breaking the whole internet by using 1.1.1.1, all for no real benefit! It's worse than we initially thought!
- throw0101a 7y ago
  > I'd imagine 1.1.1.1 has a very negative consequences for Netflix local caches, for example. Is it possible for Netflix to use anycast? For their appliances they can advertise to an ISP's routers via (i/e)BGP or OSPF / IS-IS to keep traffic internal, but have a fallback of having a presence in various IXPs. Isn't this how Cloudflare works, anycast?

deleted 7y ago

[deleted]

deleted 7y ago
[deleted]

deleted 7y ago

[deleted]

darklajid 7y ago

I'm with some of the people on Twitter: It seems weird (to put it mildly) to just blackhole your own site with no explanation whatsoever to the end-user. For everyone on 1.1.1.1 archive.is will now be "down" and they're none the wiser. Maybe there's a big backstory here, but without context that seems passive-aggressive and quite random?

profmonocle 7y ago
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.
- majewsky 7y ago
  SERVFAIL or REFUSED is also not helpful to the end user. They should return the IP of a host serving a static single-page website explaining the issue.
  - zamadatix 7y ago
    REFUSED will trigger a lookup on the next DNS server in the list, which may not be Cloudflare, instead of guaranteeing the user can't go to the real page.
spzb 7y ago
Indeed. This is the first I'd heard of this situation. I'd previously just assumed archive.is was a shonky service that didn't work properly. Hadn't connected it with my use of 1.1.1.1

viraptor 7y ago

> massive mismatch (...) of where DNS and related HTTP requests come from causes so many troubles Does anyone know what they could mean here? I get that having more open connections and slow requests is not great, but there are popular attacks people will try against them in this case. They already have to handle pathologic cases of slow requests, so handling some small number of slower clients shouldn't be an issue. Or are they talking about some other problem?

miyuru 7y ago
They are taking about Geo load balancing via DNS.[1] Just try one of the akamai endpoints to test it. (E.g media.steampowered.com) For me 1.1.1.1 serves akamai singapore IPs, while 8.8.8.8 serves IPs of my ISPs akamai cache in Sri Lanka. If your ISP has a bad route to 1.1.1.1, this just gets worse. [1] https://en.wikipedia.org/wiki/GeoDNS https://en.wikipedia.org/wiki/GeoDNS
- profmonocle 7y ago
  Blocking a user because the site might load more slowly for them doesn't make any sense to me. If the user is choosing to use a DNS server that returns sub-optimal CDN IPs, isn't that their problem?
  - oarsinsync 7y ago
    > If the user is choosing to use a DNS server that returns sub-optimal CDN IPs How many users are explicitly choosing that? How many users are actually choosing something very different, and this is an unintended consequence of their choice, that they would otherwise be unaware of if not for this provider taking a stand?
    - dwild 7y ago
      > How many users are explicitly choosing that? How many users are actually choosing something very different, and this is an unintended consequence of their choice, that they would otherwise be unaware of if not for this provider taking a stand? Not sending anything at all doesn't solve any of this. If a message was shown explaining the situation, sure, but archive.is solution doesn't answer your question at all.

LeoNatan25 7y ago

This is the reason I stopped using 1.1.1.1.

pnako 7y ago
Quad9 has a variant, 9.9.9.11 that works well with CDNs.
nobodyshere 7y ago
A very silly one at that given their reasons for not resolving archive.is are quite rational and on the contrary makes me want to swap google's DNS servers for theirs.
- cnst 7y ago
  What exactly do you use DNS for? If it's to subsequently make a HTTP and/or HTTPS request, then your full IP address (and not just a /24 subnet) will be leaked to the very same parties anyways. Even if they eventually make DNS encrypted, even if encrypting TLSv1.3 SNI work properly (and both of these are pretty big ifs, BTW), the IP addresses will still leak, always, and with a much higher precision anyways. So, this we-don't-do-ECS-because-privacy is hardly a rational statement on Cloudflare's part in the end — it merely breaks the performance of their competitor CDNs without any real privacy angle.
  - zamadatix 7y ago
    DNS isn't always run by the place the site is hosted and until the other 2 are implemented everyone along the lookup path can also see where you are going. Increasingly a destination IP is becoming less of a hint of what you are browsing to. Whether you think that's enough to care about or not it's very different than the picture you painted.
- tambre 7y ago
  > their reasons for not resolving archive.is They do solve archive.is. But archive.is's DNS servers have been configured to return bogus answers to queries from Cloudflare's servers.

Santosh83 7y ago

I'm using Cloudflare's DoH service built into Firefox and archive.is is resolvable.

Operyl 7y ago
I think that's because Firefox falls back to system resolver if something funky happens. I'm using it strictly over DoH and it isn't working for me still.
deleted 7y ago
[deleted]

jchw 7y ago

I am no expert by any means. However, I strongly suspect EDNS is not actually needed to run a CDN. There’s a lot of approaches to balancing load and distributing traffic. An example of another approach would be using anycast IPs. I’m also surprised that traffic from Cloudflare DNS users caused any significant problem. Was it really that much traffic?

profmonocle 7y ago
> However, I strongly suspect EDNS is not actually needed to run a CDN. It's not. The proof is that CDNs existed long before edns-client-subnet was introduced. All it does is allow the CDN's DNS servers to return the most optimal A/AAAA records for the client. But the worst that should happen without it is you get sent to a more distant CDN server, and the content loads more slowly. The fact that archive.is somehow suffers without this feature (which, btw, wasn't standardized until 2016) suggests they're doing something really, really odd. If I were them, I'd focus on making my system more robust, rather than demanding the rest of the Internet adopt a relatively young, optional DNS extension.
- cnst 7y ago
  Per https://serverfault.com/a/560059/110020 https://serverfault.com/a/560059/110020, Google's 8.8.8.8 has had support for `edns0-client-subnet` since at least 2013, so, even if it's only been standardised in 2016, it's been a de-factor standard for quite a while, especially in the internet-technology-years. Here's an interesting thought — if it's so bad for privacy and isn't necessary for a CDN, does Cloudflare the CDN simply disregard ECS when receiving requests from DNS.Google, or do they take it into account?
  - DarkWiiPlayer 7y ago
    > de-factor standard Google isn't the internet, you know?
  - profmonocle 7y ago
    > even if it's only been standardised in 2016, it's been a de-factor standard for quite a while, especially in the internet-technology-years. If archive.is thinks that Internet standards should be adopted so quickly, it's weird that they don't support IPv6 considering it's been a standard since 1998! Obviously I'm kidding, but only kind of. When it comes to insisting on adopting new standards, edns-client-subnet is a weird hill to die on, especially considering it was always meant to be optional. > does Cloudflare the CDN simply disregard ECS when receiving requests from DNS.Google, or do they take it into account? I don't think they have a reason to use it because they use TCP anycast. Looking at https://cachecheck.opendns.com/ https://cachecheck.opendns.com/ they seem to return the same IPs regardless of geography.

profmonocle 7y ago

> I consider EDNS-less requests from Cloudflare as invalid. If your site depends on a DNS extension that's only 3.5 years old (and designed to be optional), I think it's fair to say your site is just offline for some users due to a config mistake. You're free to set up your servers however you like, but there's wisdom in Postel's law.

rumanator 7y ago
> there's wisdom in Postel's law. For the lazy like me: robustness principle, aka Postel's law https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle Thank you for the reference. I learned something today!
- cmroanirgo 7y ago
  Thanks for the link, for which there's the counter-argument, "The Harmful Consequences of the Robustness Principle" [0]: > A flaw can become entrenched as a de facto standard. Any implementation of the protocol is required to replicate the aberrant behavior, or it is not interoperable. This is both a consequence of applying Postel's advice, and a product of a natural reluctance to avoid fatal error conditions. [0] https://tools.ietf.org/html/draft-iab-protocol-maintenance-01 https://tools.ietf.org/html/draft-iab-protocol-maintenance-0...
Thorrez 7y ago
Archive.is does not block all requests lacking EDNS. They specifically block requests coming from Cloudflare's datacenters. Cloudflare is not accidentally misconfiguring their EDNS, Cloudflare is intentionally not sending EDNS.
- Operyl 7y ago
  They’re intentionally not sending an optional extension, that seems .. fair honestly.
  - 7y ago

vesche 7y ago

Roads...? Where we're going, we don't need roads.

nindalf 7y ago

This link and the two answers within demonstrate something important, broader than the DNS related issue at hand. Both make implicit assumptions. One assumes the worst of Cloudflare and thinks “what’s the worst reason Cloudflare could have for doing this. How do they profit off this?” And the other assumes that Cloudflare has good intentions. Neither answer is technically wrong. Both flow logically from their initial assumptions. But it shows how different our conclusions can be depending on where our initial biases lie. For the person who believes the first answer and says “prove to me that Cloudflare isn’t doing something nefarious”, it’s not possible. The analysis is correct and can’t be challenged unless the initial assumption is challenged. And for people who strongly believe that Cloudflare has bad intentions, nothing can be done to change their mind. In this example it’s Cloudflare but it applies to any person or organisation that we feel strongly about.

cheschire 7y ago
The second one is not an assumption, it's Cloudflare's official position. For a person who is against Cloudflare, I feel like this would only serve to reinforce the confirmation bias as there's seemingly no person except a Cloudflare employee willing to step up and defend the action. So, yes, good observation.
- nindalf 7y ago
  Arguably, no one except a Cloudflare employee could know the reason why they took this decision. A random person speculating “maybe they did this for privacy reasons” doesn’t strike me as better than Cloudflare saying “we did this for privacy reasons”. And while the second answer is a statement, not an analysis the rest of what I said holds. You will only accept their statement as the truth if you assume good intent of them.
  - 113 7y ago
    Corporations operate for profit.
    - 7y ago

deleted 7y ago

[deleted]

tedk-42 7y ago

I really don't see this as a problem of Cloudflare. End users switching to Cloudflare's DNS endpoint are doing so because they feel the DNS provider is both faster and more secure. They rightly made the decision NOT to pass on the end user's IP information to the upstream DNS server. I agree with this decision and they are acting in my best interests in doing so. To draw some kind of nefarious intention from this is absurd. Until Cloudflare are proven to be nefarious actors, I'll continue to use their service.

varelaz 7y ago
That looks like uncompetitive behavior from Cloudflare, so it's their problem also. Cloudflare can send EDNS if nameserver and the actual server run by the same party, but they don't
- zzzcpan 7y ago
  Well, yeah. This was one of the significant reasons against Cloudflare's DoH too. They want all Firefox users to use their DNS resolver and deprive the ability of competing DNS-based CDNs (most CDNs) to pick good nodes in Firefox. I've been thinking of blacklisting Cloudflare completely on all of my servers just for that. And it seems Firefox will even be able to detect that and fallback to proper DNS for such domains.
oarsinsync 7y ago
> They rightly made the decision NOT to pass on the end user's IP information to the upstream DNS server. I agree with this decision and they are acting in my best interests in doing so. To draw some kind of nefarious intention from this is absurd. In this instance, the upstream DNS server and the resultant HTTP server are operated by the same organisation. Cloudflare have opted to not provide the /24 (or /56 if IPv6) network that the original DNS request came from, in the DNS request. Your computer will then provide the /32 (or /128 if IPv6) that your request is coming from when you connect to the HTTP server. What privacy win have you gained by Cloudflare not providing that information in this instance?
- 7y ago

cm2187 7y ago

I don’t understand the privacy reason. If I am querying for domain x, why does it matter that domain x’s DNS servers know what IP I am querying them from? I am going to hit their web server directly with that very same IP in a few milliseconds anyway.

tomatocracy 7y ago
There are a few reasons. Here are three I can think of off the top of my head: Many browsers prefetch DNS for links on webpages these days. So it’s entirely possible and even common that you may query DNS for sites you never visit, which would indeed be a privacy leak. Secondly, many sites have their DNS hosted elsewhere so it may not be the same people you are leaking the information to. Thirdly, if the DNS query is transmitted to the site’s DNS servers in plain text (which most DNS is), then despite eSNI etc anyone who has access to the wire traffic along the route from the DNS proxy to the site’s DNS servers (which is probably different from the route your own traffic takes to their servers) can see which site you wanted to access.

varelaz 7y ago

I think decision of archive.is is very interesting. 1) They attracted a lot of attention; 2) They showed the way to struggle with Cloudflare business that abuse their service. If several bigger CDNs like akamai or softlayer will consider requests from 1.1.1.1 without EDNS as invalid and block them, Clouldflare wouldn't be able just to say that it's their own problems

deleted 7y ago

[deleted]

PeterStuer 7y ago

Not sure why this is a link to stackexchange as the second answer is lifted from the previous HN discussion on the topic https://news.ycombinator.com/item?id=19828317 https://news.ycombinator.com/item?id=19828317

chaitanya 7y ago

Does 1.1.1.1 send ECS info to Cloudflare’s own nameservers? More generally, does 1.1.1.1 in any way treat Cloudflare’s own nameservers in a special way and send it information that it doesn’t send to others? If the answer to these questions is no, then Cloudflare’s reasons for blocking ECS (ie privacy) carry weight. Otherwise no.

aeyes 7y ago
When using 1.1.1.1 as resolver Cloudflare has your full IP. So they can fully track you. ECS doesn't even forward the IP, only the /24.
jgrahamc 7y ago
> Does 1.1.1.1 send ECS info to Cloudflare’s own nameservers? No > More generally, does 1.1.1.1 in any way treat Cloudflare’s own nameservers in a special way and send it information that it doesn’t send to others? No

known 7y ago

Is adding "62.192.168.106 archive.is" to /etc/hosts a work around?

known 7y ago
I added 217.79.184.91 archive.is to /etc/hosts and did sudo service systemd-resolved restart It works;

bastawhiz 7y ago

A lot of folks here seem to be saying "if you're going to make a DNS query, you're only going to make a HTTP request," which is simply untrue. Hell, you can add a HTML tag to your page to prefetch DNS queries. Browsers prefetch DNS just for hovering your mouse over a link or typing something into your address bar (without actually navigating). Should some DNS server know your IP address just because you moved your mouse over a link? IMO, no.

jiveturkey 7y ago
I don't understand what side you're taking here. Please can you rephrase your argument. 100% serious, I'd like to know what point you're making. Pre-emptively: because whatever DNS server you are using already knows your IP address, regardless whether it's the first query for the site itself, or subsequent queries for site-related additional resources.
- tracker1 7y ago
  If you hover your mouse over an ad linking to sketchy-service.com ... then the remote dns host for sketchy-service.com now has your IP address.
  - jiveturkey 7y ago
    That seems neither here-nor-there for the 1.1.1.1 service. Doesn't the browser's internal resolver use an external recursive server (either the host's configured ones or browser-determined ones)? Chrome does, AFAICT. As opposed to being a recursive resolver itself, it just implements a caching stub resolver. The remote DNS host for sketchy-service.com doesn't see your IP address, they see the recursive server's address.
  - joveian 7y ago
    Browsers can also prefetch pages under some circumstances (I'm not sure of the details). In that case, the web server for sketchy-service.com now has your exact IP address (vs. the truncated address encouraged by this extension). In firefox this can be prevented with: network.dns.disablePrefetch True network.prefetch-next False