EDNS

[sebdeckers]

Should relay the client's IP to the DNS server.

EDNS0-Client-Subnet (GeoDNS)

DNS-over-HTTPS supports EDNS0-Client-Subnet protocol, which submits part of the client's IP address (/24 for IPv4, /56 for IPv6 by default) to the upstream server. This is useful for GeoDNS and CDNs to work, and is exactly the same configuration as most public DNS servers.

Keep in mind that /24 is not enough to track a single user, although it is precise enough to know the city where the user is located. If you think EDNS0-Client-Subnet is affecting your privacy, you can set no_ecs = true in /etc/dns-over-https/doh-client.conf, with the cost of slower video streaming or software downloading speed.

To ultilize ECS, X-Forwarded-For or X-Real-IP should be enabled on your HTTP service muxer. If your server is backed by unbound or bind, you probably want to configure it to enable the EDNS0-Client-Subnet feature as well.

https://github.com/m13253/dns-over-https#edns0-client-subnet-geodns

RFC 7871 – Client Subnet in DNS Queries – defines a mechanism for recursive resolvers like Google Public DNS to send partial client IP address information to authoritative DNS name servers. Content Delivery Networks (CDNs) and latency-sensitive services use this to give accurate geo-located responses when responding to name lookups coming through public DNS resolvers.

The RFC describes ECS features that authoritative name servers must implement; but implementers don’t always follow those requirements. There are also ECS operational and deployment issues the RFC does not address that can cause problems for resolvers like Google Public DNS that auto-detect ECS support in authoritative name servers, as well as resolvers that require ECS whitelisting, like OpenDNS.

https://developers.google.com/speed/public-dns/docs/ecs