With the transition to dns-over-https and services like 1.1.1.1, some resolvers no longer provide edn0 client-subnet information. This results in suboptimal network level load balancing for CDN’s and websites using DNS as their primary load balancing mechanism. see: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-edns0
I propose that a JavaScript API or HTTP header be made so that the page can modify browser’s internal DNS cache after the first load. Think of it as a redirect/modifier but for DNS cache inside the browser. Records modifiable should be “A” record if the browser has connected to the server via an ipv4 address and an “AAAA” record should be modifiable if the browser has connected via an ipv6 address. Additionally, the cache TTL should be the same as the TTL sent by the DNS server, and should not be modifiable by the page.
This will help websites maintain the same hostname and change the associated ipv4 or ipv6 address and load balance without requiring anycast and other artificial barriers.
Since the website receives the user’s i.p address, this doesn’t seem to increase any further security or privacy risks.
I haven’t come up with a draft proposal, this is an idea open to debate and discussion.
Cloudflare suggests that we use the resolver ip address as a fallback to their lack of edns0 client-subnet but their routing policies are misconfigured for Asia. Instead of requests being served by a server in my own country, they’re being sent to a place 3000km away and served from there because that’s apparently what their resolver thinks is the nearest. My website is artificially constrained by Cloudflare’s bgp misconfiguration and is server distance is limited to their resolvers distance when my users use 1.1.1.1