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:

  1. Ask opendns what yahoos address is.
  2. Opendns returns:
  3. Hey, Verizon. Send/Request data from

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= Desire: verizon ISP>>>>open yahoo.com >> get dataX ~Lookup Yahoo.com >>>> Cache>>>"empty">>>Hosts File /Filter etc..."found">> (fake yahoo.com IP actually my ISP/)

I send: ~ hidden dns req:Please find yahoo.com and get dataX

ISP Smart server looksups Yahoo.com in the hidden header request: yahoo.com = 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: get dataX and send to

Next run:

yahoo.com get dataY DNS Cache yahoo.com Lookup (found) = 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.

  • 3
    Because that isn't they way the Internet works. Take some time and seriously study how routing and DNS works, and how it is used. It should become obvious to you that what you are asking is silly. – Zoredache Jun 7 '12 at 16:49
  • 1
    The traffic/packet sizes wouldn't change, it would still go through Verizon/ISP. It wouldn't save any time and just add to the complexity. – TheCleaner Jun 7 '12 at 16:54
  • @TheCleaner actually, to speak in defense of a hypothetical person who would design such a protocol and think it was a good idea, it would save time: it would save one RTT over the end user's Internet connection, which is very likely to be much longer than an RTT inside the ISP's core. – Celada Jun 7 '12 at 17:35
  • @Celada It would trade that off for forcing all traffic from the ISP to funnel through one choke point that would be doing the name-to-destination-route mapping. Your hypothetical person needs to take a hypothetical engineering course in scalability :-) – voretaq7 Jun 7 '12 at 18:43

Please feel free to design a protocol along the lines you are thinking of. Just remember that it will bear very little resemblance to IP, the protocol that is used on the Internet in reality.

Actually, what you are talking about is making the endpoints dumb and the network intelligent. This is the direction that was taken by the telephone network. The intelligent network design philosophy is generally cited as the reason why there is so little innovation that takes place on the telephone network. A dumb network allows end users to innovate in ways that were never foreseen by the protocol designers and make it difficult for the network infrastructure operators to stand in the way of such innovation.

| improve this answer | |

Please gain an understanding of the history of the Internet, how things work, and why they were implemented that way before proposing radical architectural changes. I suggest acquiring and reading a copy of DNS and BIND as well (any edition).

The DNS is an elegant solution to a complex problem -- What you are proposing is architecturally broken.

First Problem:
Words like "yahoo.com" have no meaning in terms of internet addresses and routing - Only IP addresses matter.
DNS takes care of turning those words into addresses, which the network then knows how to route from point A to point B. Storing routing tables for arbitrary text (as opposed to the relatively rigid structure of IP networks/subnets) would be an enormous task - totally impossible in the 1960s-1970s when this technology was born, and even with today's technology it's infeasible.

Second Problem:
What you are proposing would require every ISP to keep a complete list of every host on the internet (either in the form of the above routing table, or as a hosts file which is what you appear to be suggesting.
Way back in the stone age there was THE Hosts File, which listed every single host on the network. You would get an updated copy of THE Hosts File (via mail, UUCP, or someone bringing you a printout and you typing it in). This was back when there were about 50 machines connected to The Internet.
Now there are billions. It doesn't scale (which is why DNS was created!).

Third Problem:
What you propose adds more inefficiency than what is already in place.
Currently a you ask a DNS server for the address that goes with a name, and then you talk directly with the server you were looking for after that, with "routing magic" happening behind the scenes to get the data from your machine to its destination and back.
Your proposal requires the funneling of all traffic through a "smart" server at the ISP with a full textual routing table (replacing DNS), and never tells my machine who it should be talking to -- so that poor "smart" server at the ISP has to handle traffic from everyone at the ISP.
Again, back in the 1960s-1970s this was totally impossible. Today it's infeasible -- the workload would crush the server and internet access would cost thousands of dollars per month to pay for the infrastructure.

The brokenness I've identified is just what has occurred to me between projects while doing actual work -- I'm sure there's a litany of other reasons why this idea is ill-conceived...

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.