How to detect network delay between two hosts by DNS protocol?

Question

  H1------------------H2
   \                  /
    \                /
     \              /
      \            /
          x (me)

Suppose I'm in the point x, and there're two arbitrary host points, H1, H2. I can get the delay between H1 and me by ping, same I can also get the delay between H2 and me by ping (because there's time stamp), the question is, how to get the delay between H1 and H2 using DNS protocol?

Answer 1

Her question makes no sense.

DNS is used to turn hostnames (eg, google.com or sstatic.net) into IP addresses (eg, 64.233.169.104 or 69.59.196.213).

It has nothing to do with the physical location or network connectivity of individual servers.

In general, it's not possible to determine the link speed between two arbitrary servers remotely. If you can connect to one of the servers and make it ping the other one directly, you can get their link speed that way, but otherwise, it's impossible.

Answer 2

First off, DNS can absolutely NOT provide any clue here.
Edit: [following Grumdrig's remark] ... other than the the clues associated with the timing of DNS messages to perform a round trip to these servers. What I mean by the original statement is that there is nothing intrinsic to the DNS protocol that makes it more suited for this purpose than say HTTP, ICMP, FTP or whatever protocol may cause the server to return some message.

Second, the easy way to do this is to have software/access, directly on either H1 or H2, but I'm assuming that's the spirit of the question really is:

How can we estimate the delay between H1 and H2, without having direct access to either host?

An estimation can be done, by using the readings (timing and routes) between H1 or H2 and several workstations (not just one). (as well as having the routes between these many workstations).

This process would be akin to triangulating for finding distances or positions in a plain 2D or 3D euclidean space, but of course, remembering that

• network routes are dynamic (unlike segments in geometry)
• distances are not so linear ;-)

Another possible trick to estimate this distance is available, in a special case:
- if H1 or H2 happens to be a server which can be queried from a third location and
- if this server requires the services of the other host to honor such request.

For example if H1 is a web server which uses a webservices located on H2 to produce a particular web page. By taking multiple measurements for such requests to H1, and by deducting the distance/delay between H1 and our workstation, we can probably estimate the distance/delay between H1 and H2. We need to be careful to

• take multiple measurements for the purpose of averaging many factors, including the non-network portions of the this chain (say the time it takes for the web server to parse the request, crunch some numbers whatever...)
• take into various possibilities such as possible caching etc...
• estimate the non-network related portion of the chain

A special case of this special case, is if by chance H1 [or H2] is on the very route between the third point and H2 [or H1]. In that case, and assuming that the ICMP packets associated with traceroute are not filtered/stopped on the way, a simple traceroute would answer the question. This situation is however relatively unlikely...

Answer 3

What about this: define H1 as the authoratative nameserver for some domain, then ask H2 to resolve that domain. Then time the resolve (perhaps with an "I don't know" response) and subtract ping time to H2.

P.S. Tell your friend that cheaters never prosper.

EDITED to remove my claim that this was idiotic. I think this question isn't senseless after all - remember that this is an academic exercise. It may not be very practical, but I think it might be possible, and maybe through my solution. (Triangulating is probably a better idea in general, but it requires machines in the right places.)

Also, yes, I should have mentioned that this requires both machines to be running DNS servers. Probably there's no solution using DNS that does not, however. This question is second-hand and may have originally had that stipulation.