> So say you search for something on google; google returns its search results page, your browser gets the page, looks at all the links, asks DNS for the IP's to all those links' addresses, and DNS auto-sends YOUR (truncated) IP to all those addresses' servers?

Yes.

> I guess I'm unclear on why it would do that.

The DNS prefetching done by the browser exists to save your time. Instead of waiting to do a DNS lookup until you click on a link in the current page, the browser does DNS lookups on all links in the page as soon as the page is loaded. By the time you're done deciding which link to follow, the browser is already done with the initial step required to follow any link on the page.

> If the truncated IP coming to a CDN isn't coming with an actual request, how do they know that at some time later your actual request is from your truncated IP? (I also don't understand why a CDN would use some sort of DNS address as a geolocation strategy, but I guess that's another discussion.)

You seem to have misread the description.

A CDN is a group of multiple servers and all of them could, in theory, respond to your request for a specific web page. The servers in the group are spread out all over the globe, but all of them share the same domain name. When you look up the IP address of the shared domain name, this new GIS draft sends your truncated IP address to the DNS server of the CDN so it can choose the server in the group that is "closest" to you.

I hope that makes more sense.

> The DNS prefetching done by the browser exists to save your time. Instead of waiting to do a DNS lookup until you click on a link in the current page, the browser does DNS lookups on all links in the page as soon as the page is loaded. By the time you're done deciding which link to follow, the browser is already done with the initial step required to follow any link on the page.

My apologies; I was unclear. I (think I) get the DNS prefetching idea (your browser asks DNS for all the IP's on a page in the hope that one will be hit, and it won't have to spend time to do it later when a link is actually clicked), but why would DNS send anything to the site that it's getting an address for? (And under what protocol?)

When my browser asks DNS for an IP for "www.foo.com", why does "www.foo.com" need to know I asked for it?

I think the phrase "target web service" from the article is misleading. This is about passing part of the client's IP address to the authoritative nameserver for the for the target web service. From my understanding the following is an example- Let's say I'm on the east coast, I'm using Google DNS on the west coast as my DNS server, and I want to load foo.edgecast.com. foo.edgecast.com has two servers, one on the east coast and one on the west coast. When I perform a lookup for foo.edgecast.com I talk to Google's recursive resolver which then talks to Edgecast's authoritative nameserver. Without EDNS edgecast doesn't get any information about me; it just knows the request came from Google on the west coast, so it gives out the IP address of their west coast server. With EDNS, Edgecast's gets enough of my IP address from Google to know that I'm on the east coast, so it gives out their east coast server's IP address.

AAaaahhhh... THIS makes sense. SO it's not the actual web server that's getting my truncated IP, it's the web server's provider's NAMESERVER. So if I'm hosting a website, but not its nameserver (say I'm using godaddy or whathaveyou for that), only godaddy's nameserver would get the truncated IP if my site shows up on google's search page; not my actual web server.