zlacker

[parent] [thread] 4 comments
1. raxi+(OP)[view] [source] 2021-09-11 23:37:48
I guess you just do not understand what EDNS is, and why it is optional and why its optional-ness is not a pro-CloudFlare argument.

It is very simple:

Query(source IP is an ISP in Paris, no EDNS): gimme IP of "website.com"

WebsiteComDNS: IP of the server closest to Paris

Query(source IP is Google, no-EDNS): gimme IP of "website.com"

WebsiteComDNS: Hm, it is likely Google Cloud, or GoogleBot, answer with IP of own server on Google Cloud

Query(source IP is Google, EDNS: I am acting on behave of an user in Paris): gimme IP of "website.com"

WebsiteComDNS: IP of the server closest to Paris

Query(source IP is Cloudflare, no-EDNS): gimme IP of "website.com"

WebsiteComDNS: where the fuck is CloudFlare? Africa? answer with something random

replies(1): >>akerl_+V6
2. akerl_+V6[view] [source] 2021-09-12 00:52:01
>>raxi+(OP)
I appreciate that you’ve moved from assuming what Cloudflare is doing to assuming what I understand. I think this thread has run its course.
replies(1): >>raxi+v8
◧◩
3. raxi+v8[view] [source] [discussion] 2021-09-12 01:07:58
>>akerl_+V6
I concluded that from sentences like "they don’t owe you optional features because you really want to see user IP data" which reveal misunderstanding on who is sending queries and who decides what to answer to those queries.

From your text it looks like webmasters are sending requests to CloudFlare to get user's IP.

This is totally wrong.

It is CloudFlare wants to see server IP and in the query it has to explain how they will use this info, to which region they will forward my server IP.

That is what EDNS-client-IP for.

If the requester refuses to explain why they need the server IP address for (and their goal cannot be derived from the source IP of the UDP packet, like in the case of local ISP resolvers), they may be denied the privilege of the honor of receiving responses.

replies(1): >>judge2+Q41
◧◩◪
4. judge2+Q41[view] [source] [discussion] 2021-09-12 14:08:14
>>raxi+v8
> to which region they will forward my server IP.

They're not forwarding it at all. A request from LA will come from the LAX Cloudflare DC, and thus plugging in the requesting IP address into some geoip service will show Los Angeles, California. All you have to do to get this working is to fallback to the incoming IP if ECS is absent.

Or time travel to 2010 and try to respond to DNS queries while no servers are sending ECS.

replies(1): >>raxi+Sr1
◧◩◪◨
5. raxi+Sr1[view] [source] [discussion] 2021-09-12 16:49:27
>>judge2+Q41
> They're not forwarding it at all.

They indeed are, "for your privacy".

And our topic started exactly out of this:

From: https://webapps.stackexchange.com/questions/135222/why-does-...

``` Official Statement

archive.today had this to say about the issue:

https://twitter.com/archiveis/status/1017902875949793285

    2018-07-13T1545: yes, unlike other public DNS services, 1.1.1.1 does not support EDNS Client Subnet
https://twitter.com/archiveis/status/1018691421182791680

    2018-07-15T1958: "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.
 
```

> Or time travel to 2010 and try to respond to DNS queries while no servers are sending ECS.

That is exactly what `archive.{*}` does.

It responses to

[+] requests from IPs with geo-information (as in 2010, and it seems to be the most of requests still)

[+] AND to requests from public global resolvers with EDNS, which supply information to which region the server IP will be forwarded (as in 2015)

[-] But not requests from a public global resolver which conceal the source region (as it does a single privacy minded megacorp in 2019)

[go to top]