Why do we make DNS requests separately when an ISP could also be handling the DNS request along with HTTP data simultaneously.
So rather than:
- Ask opendns what yahoos address is.
- Opendns returns: 184.108.40.206
- Hey, Verizon. Send/Request data from 220.127.116.11.
Why wouldn't the protocol just request data from "yahoo.com" and verizon interprets the yahoo.com as a split DNS request. This would lower latency for sure as it cuts out the time required for the dns server to call back the IP to then be sent AGAIN when it could just be handling the entire request theoretically.
Couldn't this be managed via a host file change on the client side and make compatible servers?? So much like a proxy.
Thanks Celada; interesting analysis.
Thanks, I will grab that info. This is completely theoretical. & in the meantime.
Why do you hint at text/url to IP being so Herculean to then offer DNS which does exactly that as the solution.
Why must ONE server route all data? Isn't that akin to saying we all hit one server when we talk to the singular/few US google search IP or two Google DNS IPs?? Couldn't the same "first in path" proto be used for these "smart servers". You would get the real DNS servred IP before the data actually arrived so YOU could route it (and where I find my chief complication next to this being essentially a MITM attack.)
I don't want to do away with DNS. Simply make the initial server do data and locate the IP before it's sent along. The "real IP" of yahoo.com would be updated in the DNS cache after the first request.
Generic: Hello I'm on my sofa @ IP= 18.104.22.168 Desire: verizon ISP>>>>open yahoo.com >> get dataX ~Lookup Yahoo.com >>>> Cache>>>"empty">>>Hosts File /Filter etc..."found">> 22.214.171.124 (fake yahoo.com IP actually my ISP/)
I send: ~126.96.36.199 hidden dns req:Please find yahoo.com and get dataX
ISP Smart server looksups Yahoo.com in the hidden header request: yahoo.com = 188.8.131.52 via the same DNS req I would have normally made myself>>>>send that real IP to me to update cache and continue to simultaneously finish dataX request: 184.108.40.206 get dataX and send to 220.127.116.11
yahoo.com get dataY DNS Cache yahoo.com Lookup (found) = 18.104.22.168 get dataY (no lookup local or ISP)
So you still get the DNS request for yahoo.com; however, your first dump of data from yahoo.com arrives just after it--reduced latency. So it is satisfying your hidden dns request at the same time your req is being sent to yahoo or better: the request sent back to you. The first ISP hop just needs to split the request. I'd rather look at it as the first hop as a smart DNServer that handles requests.