It is something like the Gmail prefetching feature.
If that's what you're suggesting, it won't work. Many links need hostnames, because the same IP might be addressed as more than one different host (think load-balancing and VPS hosting) and those names resolve to completely different websites.
If that's not what you mean, maybe say how what you mean is different from that. I'm not sure what else could mean.
That's what I'm not understanding. It could alter the href, but then you lose any information from the hostname.
Is there some service I'm not aware of for passing DNS results back to the browser in the document? Something like that seems like it would make the user vulnerable, how does your browser know your local network doesn't have its own DNS server that blackholes advertising domains, etc.
I understand the why, but I don't see any potential answer for how. There is no standard way to "Slipstream" DNS resolution into an HTML document or HTTP response body that I know of. Nothing stopping Google from building this into Chrome, but they would have to break dozens of standards in order to do it.
It doesn't need to change the browser or anything else.
No, that's the problem. They can't. Links have one target, an address of either a remote hostname or an IP address. The browser would need to change to accommodate passing them back separately, because that's not something that current browsers do.
The problem is that a URL in an HREF has either an IP or a hostname, and there are more hostnames than IP addresses by some orders of magnitude. So, when running a web server, we will conventionally map more than one hostname to a single IP address, leading to several different hostnames that all have separate potentially unrelated content trees.
So, if Google will be pre-fetching DNS queries and passing the results onto clients, how? What I'm saying is, <a href="something", the form of links, and you have to set that href to something specific and concrete, and the browser is going to honor it and send the client request there. That's how web links work. You're suggesting the server should tell the browser what hostname to send in the server request (so the server knows what content to provide), but give it also (unchecked) a pre-calculated IP address to send the request to, so the client saves time looking up that result in DNS. How? And how should the browser client know to trust it?
You can't make the browser check if the mapping is valid, or you lose the speed benefit that you hoped to achieve. Also, browsers don't have a pathway to receive this information separately or out-of-band. So, where does it go in-band? The standards weren't written to pass this information apart from each other, the answer is that doing it that way would present a new threat vector and there is no place for it in any standard that exists. (Correct me if I am wrong.)