8 ms·

In this particular case we truncate EDNS to protect the privacy of users because we believe 1) privacy is a fundamental human right; and 2) the original sin of

In this particular case we truncate EDNS to protect the privacy of users because we believe 1) privacy is a fundamental human right; and 2) the original sin of the Internet is that IP addresses are too closely tied to the identities of individuals and services. Truncating EDNS is trying to honor #1 and overcome #2. So is our work on protocols like Oblivious DNS. This work, frankly, upsets some of our customers or potential customers (like Archive.is). But it’s the right thing to do for the long term health of the Internet.

nora-puchreiner 3y ago
[flagged]
- sitzkrieg 3y ago
  agreed, came to point this out. or they monitor hn to go be the heroes of centralized internet yet again
- eastdakota 3y ago
  I wish we (and the rest of the world) were as organized as it’d take to support conspiracy theories. Easier explanation probably is that I just woke up about 90 minutes ago. HN is about #9 on the list of things I check every morning. Saw this post and thought: “Oh not this again!” Pinged our team to get latest status since I hadn’t thought about archive.is in several years. And then jumped into the comments. But your story is way more fun, makes us look way more organized, and, frankly, would give me hope that there are really smart people out there organizing and planning the chaos. So let’s go with yours.
  - nora-puchreiner 3y ago
    Brands do creative marketing and do invest in it (especially after they stock fell on Q2 report). That is why they are brands. There is no "conspiracy" nor "chaos".
    - eastdakota 3y ago
      I’m smiling thinking of the reaction I’d get on our marketing team if I suggested: “Hey, I have an idea, let’s post a negative story on Hacker News so then people in the comments will say things and I can reply.” John (our CTO) and I care about HN because we’re engineers at heart. Unfortunately, most the people we sell to today have never even heard of let alone participated in this community. But, over time, I hope as many of the people in this community get C’s in front of their titles and manage hundred million dollar IT budgets, I hope you’ll stay engaged here. More engineers in the C-suite would be great. Though what you’ll find, sadly, is there’s still lots and lots of chaos.
      - nora-puchreiner 3y ago
        There is a legend about an online store on the eve of the 2000s, which behaved very badly towards customers, and on forums everyone discussed how bad they are. But their mentions performed very good for SEO and sales. It's a [m-word] textbook story, I don't believe you don't know it. There are no "negative stories", there are newsworthy occasions. Reminders that we're still alive, that we're still working. And comments about how great we are, which for some reason are far more numerous (and upvoted) in this thread than Hacker's technical discussions.
        freedomben 3y ago
        I would bet the scale and scope of Cloudflare's business would make HN a complete waste of time over and over, even if it were some marketing conspiracy. The CEO of an org like CF has way better things to do with his company-time than shill on HN. Plus, if you took 2 minutes to look at eastdakota's comment history and/or mine, you'll see we are longtime active HN users. So if we're somehow in cahoots to drum up some good marketing PR on HN, then we've put more than 10 years of effort into building fake profiles with comment history and have carefully made sure to hide our affiliation, just so I could compliment Cloudflare on HN and hope that the Gods of random actually got it noticed and upvoted, just so the CEO could come in and leave a comment. Or, maybe we're just people that like and use HN that happen to believe what we say.
  - lkbm 3y ago
    Honestly, my go-to explanation would have been "Cloudflare has an automated alert for when they're on the HN front page". Not an, urgent, wake up the team alert, but a "post it to a Slack channel" bot. Maybe I should throw together a Cloudflare Worker that does this.
- hoppyhoppy2 3y ago
  >Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - nora-puchreiner 3y ago
    Well, calling marketing their name is abuse nowadays. A forbidden m-word
  - flangola7 3y ago
    When it comes to tech giants it's a matter of assume malicious until proven otherwise.
freedomben 3y ago
More of a meta comment, but thank you for your willingess to upset some customers and potential customers. Having and standing by principles can be damn inconvenient at times, but the world is a much better place because of it.
- adql 3y ago
  It's entirely smokescreen. Yes your DNS doesn't "leak" your IP... but server will immediately get the IP of the client on first try of connecting it.
  - djbusby 3y ago
    But the DNS won't. Many times the DNS and Webserver are different hosts. Eg: DNS in Route53 and Webserver in Linode
    - jachee 3y ago
      Also, looking up DNS in one direction and browsing (say over a VPN) in another. The destination site doesn’t always get the same IP that the DNS request gets.
- nullindividual 3y ago
  > thank you for your willingess to upset some customers and potential customers Or, thank you for wasting your customers time attempting to figure out why one or more sites aren't responding appropriately on your network while they work on other networks. Not everyone is clued into EDNS or why archive.is doesn't function with CF. CF is wasting everyone's time.
  - lolinder 3y ago
    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.
supriyo-biswas 3y ago
Sure, we’re to believe that, given that you’re trying to lock out Linux users[1] (which still isn't resolved yet) and pushing for device attestation[2] to lock out rooted devices at the same time. [1] https://news.ycombinator.com/item?id=36197401 https://news.ycombinator.com/item?id=36197401 [2] https://www.ietf.org/archive/id/draft-private-access-tokens-01.html https://www.ietf.org/archive/id/draft-private-access-tokens-...
- brookst 3y ago
  There’s a fair argument to make against device attention, but casting the exclusion of rooted devices as the goal of the policy rather than a side effect is a bit disingenuous.
- afavour 3y ago
  Your link for [1] shows that CF responsed, confirmed the bug and that they fixed it. If that’s not actually the case have you tried engaging with them again? They seemed very responsive the first time.
  - supriyo-biswas 3y ago
    CF (like many other companies) are responsive only when the complaint is posted on HN. Regardless, the issue wasn't solved, it came back within a few hours. I've tried raising this issue on their forum, where I've failed to get the attention of the engineering teams, and while posting the ray ID should be sufficient, all you'd really get is clueless, unpaid volunteers asking you questions in circles like "what website do you see this on" (everywhere), "are you using adblock" (no, and Adblock has never blocked their Turnstile scripts) and "what's your user agent?" (the default Chromium one). If I had to hazard a guess, it's their bot management script seeing "Linux" in the user agent and detecting missing video codecs (which is par for the course for standard Chromium builds), and thinking it's a headless browser. Between the the fact that differences between the JS runtime of Chromium and Chromium headless are very small these days, and the ClientHello permutation has destroyed bot management vendors' ability to distinguish different browser builds, they decided blocking all Linux users using Chromium was fair enough.
nullindividual 3y ago
I use Quad9 because of this reason. CF will also misdirect Exchange Online connections which can significantly impact client performance. It would be great if CF offered a choice, like Quad9.
- rovr138 3y ago
  misdirect? What's happening with them?
  - nullindividual 3y ago
    Exchange Online determines the closest EXO front door by the location of resolver. Other M365 services do not use this method, it is an artifact from Exchange Server. EDIT: This is outlined in [0], although it doesn't go into the depth I wish it did. > By providing local Internet egress and by configuring internal DNS servers to provide local name resolution for Microsoft 365 endpoints, network traffic destined for Microsoft 365 can connect to Microsoft 365 front end servers as close as possible to the user. [0] https://learn.microsoft.com/microsoft-365/enterprise/microsoft-365-network-connectivity-principles?view=o365-worldwide https://learn.microsoft.com/microsoft-365/enterprise/microso...
tomp 3y ago
> This work, frankly, upsets some of our customers or potential customers (like Archive.is). That's a bit unfair, don't you think? From what I remember of the saga, the original reason for Archive.is's block is that they run their own CDN, and by not knowing the location of the user, they can't determine the closest server to respond with. edit: found source https://twitter.com/archiveis/status/1018691421182791680 https://twitter.com/archiveis/status/1018691421182791680 So the alternative viewpoint is, that Cloudflare is being anti-competitive by technically preventing other CDN providers from working. Disclosure: I'm a happy Cloudflare user, but all in all I think Archive.is service is far more fundamental for the internet (especially as it's 100% free!). So I would really appreciate if you could figure out a way of working together. Until then, 8.8.8.8 it is!
- yellowapple 3y ago
  > they run their own CDN, and by not knowing the location of the user, they can't determine the closest server to respond with. I feel like the more reasonable answer here is to just let the user take the latency hit. Surely requests being somewhat slower is preferable to requests being outright bitbucketed, right?
  - adql 3y ago
    Right but then working slow looks like archive.is issue but is ultimately caused by cloudflare. CF is bascically saying "we can know your IP but not the site you are trying to resolve" (that will know your IP anyway once you navigate there).
    - yellowapple 3y ago
      > Right but then working slow looks like archive.is issue but is ultimately caused by cloudflare. Whereas not loading at all looks like archive.is issue but is ultimately caused by archive.is. > CF is bascically saying "we can know your IP but not the site you are trying to resolve" (that will know your IP anyway once you navigate there). Not necessarily. For example, the DNS query could go straight to CF while the eventual request to archive.is goes through a proxy or VPN.
adql 3y ago
User will navigate to the site and show their own IP anyway. You achieved basically zero increase in privacy while making any competitor have problems with any of their users that use 1.1.1.1 And any malicious client that tries to leak data via DNS can just ask for DNS record like my-ip-is-7.8.9.0.example.com and completely go around that privacy "enhancement". Sorry but the "privacy" here looks like smokescreen to stifle competition.
- lolinder 3y ago
  The concern isn't that the website will know the IP, it's that every single entity on the network between Cloudflare and the authoritative DNS server (most or all of which will not be operated by the website) will know it. It still may not be the right decision, but it's important to frame the trade-off correctly.
  - sXgC6dwhMJMBvue 3y ago
    So just don't send ECS on any query except once you get to the public-suffix's NS... Every element on the network between the user and the website will know it, too.
ninjagoo 3y ago
So Stavros [1] indicates that archive.is needs that EDNS data to protect themselves against CSAM/ISIS material based attacks, and they suggested solutions but CF refused to cooperate. Is this true? [1] https://news.ycombinator.com/item?id=36971650 https://news.ycombinator.com/item?id=36971650
- Thiez 3y ago
  This seems trivial to avoid now that this trick is public knowledge.
pierat 3y ago
> In this particular case we truncate EDNS to protect the privacy of users In other words, you want the data, but prevent others from seeing your advantage? This is what archive.is is doing, and you stomp your collective feet at. > because we believe 1) privacy is a fundamental human right; and 2) the original sin of the Internet is that IP addresses are too closely tied to the identities of individuals and services. If you cared about that, you wouldn't either block Tor or send us through captcha-hell just to pull a single webpage. > Truncating EDNS is trying to honor #1 and overcome #2. So is our work on protocols like Oblivious DNS. This work, frankly, upsets some of our customers or potential customers (like Archive.is). But it’s the right thing to do for the long term health of the Internet. 'Upsets'? Wow. Talk about a "Rules for thee but not for me."
- cmeacham98 3y ago
  What advantage? Is there reason to believe that 1.1.1.1 treats CloudFlare's CDN specially and forwards EDNS info or similar?
  - nora-puchreiner 3y ago
    EDNS absence does affect cheap DNS-based CDNs and has to effect on expensive AnyCast CDNs (one of them is CloudFlare CDN).
    - supriyo-biswas 3y ago
      Amazon’s Cloudfront is anything but cheap, but they too are based on DNS based routing.
btown 3y ago
Have you thought about spoofing the EDNS to (a less truncated version of) the nearest Cloudflare edge node's IP? This would be no more of a privacy leak than traffic from your edge to origin servers, while providing generally enough geographic information to keep latency low on the source. This is at the very least compliant with the spirit of the RFC, no? EDIT: another comment, though somewhat hearsay, suggests that Cloudflare's caching could make this difficult to implement: https://news.ycombinator.com/item?id=36971650 https://news.ycombinator.com/item?id=36971650
jshier 3y ago
This, and Warp's insistence on passing my origin IP to my destinations, are two things I wish I could customize when using Cloudflare. Before going corporate OpenDNS had something similar, and you could even set up custom behaviors per origin IP (for home and work), which I miss. These are good defaults, but I wish to change the defaults while also allowing particular domains to get my full EDNS info, like particular CDNs. While I'm here, I'd also like to layer Zero Trust and Warp+ so I can toggle my internal network while staying on Warp+. Also, the separation in Zero Trust and tunnels between routed DNS names and private IPs is very confusing. Why do I need both? Custom DNS entries for Zero Trust DNS would be nice, so I could point internal domains to the external routing without having to have public DNS, or even have the domains match.
- doabell 3y ago
  > Warp's insistence on passing my origin IP to my destinations IIRC WARP was only able to forward your origin IP to websites using Cloudflare. Then, as of Aug 2022, their FAQ[1] says your origin IP is hidden regardless of which website. Their IPs do reveal your geolocation though. There was a bug[2] that revealed your IP to select websites; that seems to have been fixed by Nov 2022. Disclaimer: I’m not knowledgeable enough to test every possible IP leak mechanism (like WebRTC), so I didn’t do that. I’m basically taking their word for it. [1] https://developers.cloudflare.com/warp-client/known-issues-and-faq/#does-warp-reveal-my-ip-address-to-websites-i-visit https://developers.cloudflare.com/warp-client/known-issues-a... [2] https://community.cloudflare.com/t/beware-cloudflare-warp-does-not-always-hide-your-ip/425348/8 https://community.cloudflare.com/t/beware-cloudflare-warp-do...
polski-g 3y ago
Why don't you just send fraudulent EDNS info?
Zuiii 3y ago
> In this particular case we truncate EDNS to protect the privacy of users because we believe 1) privacy is a fundamental human right; and 2) the original sin of the Internet is that IP addresses are too closely tied to the identities of individuals and services. Your beliefs certainly aren't reflected in how you treat users. It's been a good while since I've been able to visit any cloudflare protected site using Tor. Your broken systems keep presenting me with infinite checkboxes that do absolutely nothing. If you want to block people who truly believe that privacy is a fundamental human right, at least have the decency to be honest. Tell Tor users that they are permanently blocked so that they don't waste their time clicking on pointless checkboxes.

nora-puchreiner 3y ago

[flagged]

sitzkrieg 3y ago
agreed, came to point this out. or they monitor hn to go be the heroes of centralized internet yet again
eastdakota 3y ago
I wish we (and the rest of the world) were as organized as it’d take to support conspiracy theories. Easier explanation probably is that I just woke up about 90 minutes ago. HN is about #9 on the list of things I check every morning. Saw this post and thought: “Oh not this again!” Pinged our team to get latest status since I hadn’t thought about archive.is in several years. And then jumped into the comments. But your story is way more fun, makes us look way more organized, and, frankly, would give me hope that there are really smart people out there organizing and planning the chaos. So let’s go with yours.
- nora-puchreiner 3y ago
  Brands do creative marketing and do invest in it (especially after they stock fell on Q2 report). That is why they are brands. There is no "conspiracy" nor "chaos".
  - eastdakota 3y ago
    I’m smiling thinking of the reaction I’d get on our marketing team if I suggested: “Hey, I have an idea, let’s post a negative story on Hacker News so then people in the comments will say things and I can reply.” John (our CTO) and I care about HN because we’re engineers at heart. Unfortunately, most the people we sell to today have never even heard of let alone participated in this community. But, over time, I hope as many of the people in this community get C’s in front of their titles and manage hundred million dollar IT budgets, I hope you’ll stay engaged here. More engineers in the C-suite would be great. Though what you’ll find, sadly, is there’s still lots and lots of chaos.
    - nora-puchreiner 3y ago
      There is a legend about an online store on the eve of the 2000s, which behaved very badly towards customers, and on forums everyone discussed how bad they are. But their mentions performed very good for SEO and sales. It's a [m-word] textbook story, I don't believe you don't know it. There are no "negative stories", there are newsworthy occasions. Reminders that we're still alive, that we're still working. And comments about how great we are, which for some reason are far more numerous (and upvoted) in this thread than Hacker's technical discussions.
      - freedomben 3y ago
        I would bet the scale and scope of Cloudflare's business would make HN a complete waste of time over and over, even if it were some marketing conspiracy. The CEO of an org like CF has way better things to do with his company-time than shill on HN. Plus, if you took 2 minutes to look at eastdakota's comment history and/or mine, you'll see we are longtime active HN users. So if we're somehow in cahoots to drum up some good marketing PR on HN, then we've put more than 10 years of effort into building fake profiles with comment history and have carefully made sure to hide our affiliation, just so I could compliment Cloudflare on HN and hope that the Gods of random actually got it noticed and upvoted, just so the CEO could come in and leave a comment. Or, maybe we're just people that like and use HN that happen to believe what we say.
- lkbm 3y ago
  Honestly, my go-to explanation would have been "Cloudflare has an automated alert for when they're on the HN front page". Not an, urgent, wake up the team alert, but a "post it to a Slack channel" bot. Maybe I should throw together a Cloudflare Worker that does this.
hoppyhoppy2 3y ago
>Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- nora-puchreiner 3y ago
  Well, calling marketing their name is abuse nowadays. A forbidden m-word
- flangola7 3y ago
  When it comes to tech giants it's a matter of assume malicious until proven otherwise.

freedomben 3y ago

More of a meta comment, but thank you for your willingess to upset some customers and potential customers. Having and standing by principles can be damn inconvenient at times, but the world is a much better place because of it.

adql 3y ago
It's entirely smokescreen. Yes your DNS doesn't "leak" your IP... but server will immediately get the IP of the client on first try of connecting it.
- djbusby 3y ago
  But the DNS won't. Many times the DNS and Webserver are different hosts. Eg: DNS in Route53 and Webserver in Linode
  - jachee 3y ago
    Also, looking up DNS in one direction and browsing (say over a VPN) in another. The destination site doesn’t always get the same IP that the DNS request gets.
nullindividual 3y ago
> thank you for your willingess to upset some customers and potential customers Or, thank you for wasting your customers time attempting to figure out why one or more sites aren't responding appropriately on your network while they work on other networks. Not everyone is clued into EDNS or why archive.is doesn't function with CF. CF is wasting everyone's time.
- lolinder 3y ago
  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.

supriyo-biswas 3y ago

Sure, we’re to believe that, given that you’re trying to lock out Linux users[1] (which still isn't resolved yet) and pushing for device attestation[2] to lock out rooted devices at the same time. [1] https://news.ycombinator.com/item?id=36197401 https://news.ycombinator.com/item?id=36197401 [2] https://www.ietf.org/archive/id/draft-private-access-tokens-01.html https://www.ietf.org/archive/id/draft-private-access-tokens-...

brookst 3y ago
There’s a fair argument to make against device attention, but casting the exclusion of rooted devices as the goal of the policy rather than a side effect is a bit disingenuous.
afavour 3y ago
Your link for [1] shows that CF responsed, confirmed the bug and that they fixed it. If that’s not actually the case have you tried engaging with them again? They seemed very responsive the first time.
- supriyo-biswas 3y ago
  CF (like many other companies) are responsive only when the complaint is posted on HN. Regardless, the issue wasn't solved, it came back within a few hours. I've tried raising this issue on their forum, where I've failed to get the attention of the engineering teams, and while posting the ray ID should be sufficient, all you'd really get is clueless, unpaid volunteers asking you questions in circles like "what website do you see this on" (everywhere), "are you using adblock" (no, and Adblock has never blocked their Turnstile scripts) and "what's your user agent?" (the default Chromium one). If I had to hazard a guess, it's their bot management script seeing "Linux" in the user agent and detecting missing video codecs (which is par for the course for standard Chromium builds), and thinking it's a headless browser. Between the the fact that differences between the JS runtime of Chromium and Chromium headless are very small these days, and the ClientHello permutation has destroyed bot management vendors' ability to distinguish different browser builds, they decided blocking all Linux users using Chromium was fair enough.

nullindividual 3y ago

I use Quad9 because of this reason. CF will also misdirect Exchange Online connections which can significantly impact client performance. It would be great if CF offered a choice, like Quad9.

rovr138 3y ago
misdirect? What's happening with them?
- nullindividual 3y ago
  Exchange Online determines the closest EXO front door by the location of resolver. Other M365 services do not use this method, it is an artifact from Exchange Server. EDIT: This is outlined in [0], although it doesn't go into the depth I wish it did. > By providing local Internet egress and by configuring internal DNS servers to provide local name resolution for Microsoft 365 endpoints, network traffic destined for Microsoft 365 can connect to Microsoft 365 front end servers as close as possible to the user. [0] https://learn.microsoft.com/microsoft-365/enterprise/microsoft-365-network-connectivity-principles?view=o365-worldwide https://learn.microsoft.com/microsoft-365/enterprise/microso...

tomp 3y ago

> This work, frankly, upsets some of our customers or potential customers (like Archive.is). That's a bit unfair, don't you think? From what I remember of the saga, the original reason for Archive.is's block is that they run their own CDN, and by not knowing the location of the user, they can't determine the closest server to respond with. edit: found source https://twitter.com/archiveis/status/1018691421182791680 https://twitter.com/archiveis/status/1018691421182791680 So the alternative viewpoint is, that Cloudflare is being anti-competitive by technically preventing other CDN providers from working. Disclosure: I'm a happy Cloudflare user, but all in all I think Archive.is service is far more fundamental for the internet (especially as it's 100% free!). So I would really appreciate if you could figure out a way of working together. Until then, 8.8.8.8 it is!

yellowapple 3y ago
> they run their own CDN, and by not knowing the location of the user, they can't determine the closest server to respond with. I feel like the more reasonable answer here is to just let the user take the latency hit. Surely requests being somewhat slower is preferable to requests being outright bitbucketed, right?
- adql 3y ago
  Right but then working slow looks like archive.is issue but is ultimately caused by cloudflare. CF is bascically saying "we can know your IP but not the site you are trying to resolve" (that will know your IP anyway once you navigate there).
  - yellowapple 3y ago
    > Right but then working slow looks like archive.is issue but is ultimately caused by cloudflare. Whereas not loading at all looks like archive.is issue but is ultimately caused by archive.is. > CF is bascically saying "we can know your IP but not the site you are trying to resolve" (that will know your IP anyway once you navigate there). Not necessarily. For example, the DNS query could go straight to CF while the eventual request to archive.is goes through a proxy or VPN.

adql 3y ago

User will navigate to the site and show their own IP anyway. You achieved basically zero increase in privacy while making any competitor have problems with any of their users that use 1.1.1.1 And any malicious client that tries to leak data via DNS can just ask for DNS record like my-ip-is-7.8.9.0.example.com and completely go around that privacy "enhancement". Sorry but the "privacy" here looks like smokescreen to stifle competition.

lolinder 3y ago
The concern isn't that the website will know the IP, it's that every single entity on the network between Cloudflare and the authoritative DNS server (most or all of which will not be operated by the website) will know it. It still may not be the right decision, but it's important to frame the trade-off correctly.
- sXgC6dwhMJMBvue 3y ago
  So just don't send ECS on any query except once you get to the public-suffix's NS... Every element on the network between the user and the website will know it, too.

ninjagoo 3y ago

So Stavros [1] indicates that archive.is needs that EDNS data to protect themselves against CSAM/ISIS material based attacks, and they suggested solutions but CF refused to cooperate. Is this true? [1] https://news.ycombinator.com/item?id=36971650 https://news.ycombinator.com/item?id=36971650

Thiez 3y ago
This seems trivial to avoid now that this trick is public knowledge.

pierat 3y ago

> In this particular case we truncate EDNS to protect the privacy of users In other words, you want the data, but prevent others from seeing your advantage? This is what archive.is is doing, and you stomp your collective feet at. > because we believe 1) privacy is a fundamental human right; and 2) the original sin of the Internet is that IP addresses are too closely tied to the identities of individuals and services. If you cared about that, you wouldn't either block Tor or send us through captcha-hell just to pull a single webpage. > Truncating EDNS is trying to honor #1 and overcome #2. So is our work on protocols like Oblivious DNS. This work, frankly, upsets some of our customers or potential customers (like Archive.is). But it’s the right thing to do for the long term health of the Internet. 'Upsets'? Wow. Talk about a "Rules for thee but not for me."

cmeacham98 3y ago
What advantage? Is there reason to believe that 1.1.1.1 treats CloudFlare's CDN specially and forwards EDNS info or similar?
- nora-puchreiner 3y ago
  EDNS absence does affect cheap DNS-based CDNs and has to effect on expensive AnyCast CDNs (one of them is CloudFlare CDN).
  - supriyo-biswas 3y ago
    Amazon’s Cloudfront is anything but cheap, but they too are based on DNS based routing.

btown 3y ago

Have you thought about spoofing the EDNS to (a less truncated version of) the nearest Cloudflare edge node's IP? This would be no more of a privacy leak than traffic from your edge to origin servers, while providing generally enough geographic information to keep latency low on the source. This is at the very least compliant with the spirit of the RFC, no? EDIT: another comment, though somewhat hearsay, suggests that Cloudflare's caching could make this difficult to implement: https://news.ycombinator.com/item?id=36971650 https://news.ycombinator.com/item?id=36971650

jshier 3y ago

This, and Warp's insistence on passing my origin IP to my destinations, are two things I wish I could customize when using Cloudflare. Before going corporate OpenDNS had something similar, and you could even set up custom behaviors per origin IP (for home and work), which I miss. These are good defaults, but I wish to change the defaults while also allowing particular domains to get my full EDNS info, like particular CDNs. While I'm here, I'd also like to layer Zero Trust and Warp+ so I can toggle my internal network while staying on Warp+. Also, the separation in Zero Trust and tunnels between routed DNS names and private IPs is very confusing. Why do I need both? Custom DNS entries for Zero Trust DNS would be nice, so I could point internal domains to the external routing without having to have public DNS, or even have the domains match.

doabell 3y ago
> Warp's insistence on passing my origin IP to my destinations IIRC WARP was only able to forward your origin IP to websites using Cloudflare. Then, as of Aug 2022, their FAQ[1] says your origin IP is hidden regardless of which website. Their IPs do reveal your geolocation though. There was a bug[2] that revealed your IP to select websites; that seems to have been fixed by Nov 2022. Disclaimer: I’m not knowledgeable enough to test every possible IP leak mechanism (like WebRTC), so I didn’t do that. I’m basically taking their word for it. [1] https://developers.cloudflare.com/warp-client/known-issues-and-faq/#does-warp-reveal-my-ip-address-to-websites-i-visit https://developers.cloudflare.com/warp-client/known-issues-a... [2] https://community.cloudflare.com/t/beware-cloudflare-warp-does-not-always-hide-your-ip/425348/8 https://community.cloudflare.com/t/beware-cloudflare-warp-do...

polski-g 3y ago

Why don't you just send fraudulent EDNS info?

Zuiii 3y ago

> In this particular case we truncate EDNS to protect the privacy of users because we believe 1) privacy is a fundamental human right; and 2) the original sin of the Internet is that IP addresses are too closely tied to the identities of individuals and services. Your beliefs certainly aren't reflected in how you treat users. It's been a good while since I've been able to visit any cloudflare protected site using Tor. Your broken systems keep presenting me with infinite checkboxes that do absolutely nothing. If you want to block people who truly believe that privacy is a fundamental human right, at least have the decency to be honest. Tell Tor users that they are permanently blocked so that they don't waste their time clicking on pointless checkboxes.