pick closest IP or DNS send send fastest route

Question

Background

I have a router (Linux node) connected with multiple ISPs. For e.g.

ISP1 90.90.90.90 ISP2 80.80.80.80 ISP3 70.70.70.70

At present DNS A records reports all 3 IPs. DNS is used to balance network load and for fail-over. References - Using multiple A-records for my domain - do web browsers ever try more than one? and http://blog.engelke.com/tag/browser-retry/

These 3 ISPs are the 3 major ISP located in my country.

Question

Users should pick their own ISP network to reach to my server OR users should pick fastest path OR my DNS should send 3 IP's sorted (by fastest route) to user. There could be more ways but I guess you now understand what is required.

Even if sensing best route by DNS takes some time and it makes DNS reply slow it is OK. I can compensate this by setting high TTL.

NOTE: I cannot use GEO data, this is because all these 3 ISPs are in almost every state of my country.

Update 1: Need to put question clearly.

What application/software services can be used to calculate route with least response time so that DNS response can be sorted by response time with respect to every user?

Answer 1

Using the shortest path etc is regulated by routers used by the ISP. There isn't any way you can change the effects of this.

Your traffic makes up a small fraction of the traffic going through these routers. These routers are already configured to get the traffic to the end point using the best means possible.

If there was a way of you choosing your traffic to use the shortest path then this opens up the issue of if a router or a link on this path goes down. All your traffic has been designed to go through that path, and if the path is incomplete then your traffic can't go anywhere.

Answer 2

AFAIK, there's no easy way to do this. The obvious method is using ping or tracert, but this can only be done from your IP.

There are public lists of servers that allow you to perform traces from other locations, but, even if you can find one for each location you want, unless they're on the same ISP/network as your server, the path they take might not reflect the path taken by your servers, which can greatly affect response time. Network unreliability can also skew results unless you take multiple measurements.

I suppose you could set up a service on each of your servers that could be triggered to ping or tracert the client IP and report the time. But the client could have ping replies disabled by firewall and block tracert echo requests.

Really, your best bet would be to just use GeoIP to guess the nearest server location (your ISP servicing multiple locations is irrelevant). Given you only have 3 servers and not a CDN with extensive edge coverage, trying to measure the latency for the actual routes is overkill.

Edit:

Assuming you're right about same ISP servers delivering such significant latency redunctions, then—since you're only dealing with 3 ISPs—you should be able to check if the user is on one of the 3 ISPs you're using and override the GeoIP-based rule and use the server on the user's ISP instead. You can do this by matching the hostname of the client with the servers.