Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Any latency based DNS?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Any latency based DNS?

dnwkdnwk Member
edited September 2013 in Help

Besides Amazon, is there any other latency based DNS service? I tried Rage4. But its GeoDNS not always work well. Sometimes, it will provide an incorrect IP to one location far away. I guess IP location database does not always correct. At this moment, Amazon's Latency based DNS is pretty accurate in taking user to the correct location. However, there are such a few locations available in Amazon and is difficult if you need to find tune the routing. So I am looking for alternative.

Comments

  • OliverOliver Member, Host Rep

    Sorry I can't offer suggestions for alternate services but I suggest you contact Rage4 about the problems you have because I am sure if you help them to resolve the problems it'll help you in the long term. After all if everyone reports such errors then they can best tune their databases to provide better results for all who use their service. :-)

  • @Oliver said:
    Sorry I can't offer suggestions for alternate services but I suggest you contact Rage4 about the problems you have because I am sure if you help them to resolve the problems it'll help you in the long term. After all if everyone reports such errors then they can best tune their databases to provide better results for all who use their service. :-)

    I think I can figure out why. I am using service like just-ping or ping.ms to figure out what ip is given to what location. But IPs, especially IPs for those used on server doesn't usually have a good GeoLocation information. I remember once I get a HK VM from EDIS, but IP was identified as a EU ip. Any that might be a reason rage4 did not deliver a correct IP for that region. If that's the case, rage 4 cannot do anything about it. @gbshouse

  • OliverOliver Member, Host Rep

    Well that's an EDIS problem if the geolocation with the provider is wrong and not with Rage4 I think. ;-)

  • Basically what @Oliver said.

    @dnwk: Yes, you're right this should be mostly caused by some kind of wrong Geo IP information. In general, there isn't really anything to do about it (I mean, from where should the service know it better?) - but if send in a support ticket with some ranges that aren't correct, it might be possible to manually adjust the Geo settings for that :)

    To be honest, it's extremely hard to build a global solution that works for every IP range / transit provider, with Anycast you sometime have a similar issue, too. If you take a deeper look at Cloudflare, they also have these issues...

    So show some understanding and give the right people a talk, that's the best you can do about it!

  • @Amfy @Oliver
    I believe that AWS is actually ping the IP to determine where is closest. They did not use Geo Info for a IP. I believe that's a superior solution as Geo Info always changing and not always accurate.

  • avelineaveline Member, Patron Provider

    @dnwk said:
    Amfy Oliver
    I believe that AWS is actually ping the IP to determine where is closest. They did not use Geo Info for a IP. I believe that's a superior solution as Geo Info always changing and not always accurate.

    Nope, AWS won't ping the IP.
    It depends on BGP route.

  • @aveline said:
    It depends on BGP route.

    Either way, they are depending on network situation not IP Info

  • @dnwk said:
    Either way, they are depending on network situation not IP Info

    Exactly! Rage4 has geo issues that need addressing. Their "Closest First" works by longitude/latitude, not network routes/peering. So to Rage4, Sao Paulo is closer to Cape Town than New York City. :-(

    Further, Rage4 doesn't have a "Default" catchall like a Bind9 Default View. The impact of this is that client IPs, that don't match any user defined geo settings, are returned empty results. Of course you could always "double up" by adding a Global record, but then Rage4 will return BOTH the "First Closest" AND the Global records... causing clients to round-robin between the IPs.

    Rage4 is also slow at improvements and addressing customer Feedback:
    http://gbshouse.uservoice.com/forums/173911-general

  • Maybe EdgeDirector? They seem to add in the responsiveness of the server into their calculations (sort of a "closest, most responsive/readily available first"), BUT they are more costly than Rage4. Other DNS hosting options are here

  • gbshousegbshouse Member, Host Rep
    edited September 2013

    The problem with Route53 approach is that they provide latency based GeoDNS but only to their DC (it hard to measure AS path/latency between two remote IPs [server and client]). We can do the same but for example for some regions of US it can be tricky (we will have to assume that all DCs in let's say LA have the same latency/AS paths as our DC) so in my opinion it makes no sense. We are trying hard to make our GeoDNS as good as possible. It's possible to "hack" the latitude and longitude attached to record so for @jimpop problem it's enough to create A records with geographical coordinates of the center of South America and NY's IP address. Regarding geolocation database quality - we are working on new version of our databases and soon it will be possible to adjust the setting if necessary from your Rage4 account.
    "Rage4 doesn't have a "Default" catchall like a Bind9 Default View" - yes we have.

  • @gbshouse said:
    It's possible to "hack" the latitude and longitude attached to record so for jimpop problem it's enough to create A records with geographical coordinates of the center of South America and NY's IP address.

    Interesting approach, but that assumes that South America is, or particular areas in South America are, round. Let me offer you a specific case for you to comment with a specific solution:

     Route clients in Argentina, Brazil Chile, Uruguay, and Peru to a datacenter in Sao Paulo at 189.1.170.36.
    
     Route all other South American countries to a datacenter in Miami at 192.73.243.101.
    

    What A records do you propose?

    "Rage4 doesn't have a "Default" catchall like a Bind9 Default View" - yes we have.

    Bind9's Default View exists to provide DNS records when NO OTHER View matches. Rage4 have Global and First Closest which will respond with ALL records that match (Global records AND the First Closest), AS WELL AS any additional "records with geographical coordinates of ..." , such as you describe above.

  • gbshousegbshouse Member, Host Rep

    @jimpop - create "First closest server" entry for each of those countries with specific IP.

    Of course that there are limitations and South America is not the best example as geolocation data for this continent is extremely poor even with most expensive, commercial databases. The same is for Africa, most of the India etc.

  • jimpopjimpop Member
    edited September 2013

    First Closest works by radius, no? Countries, and thereby network OPs in those countries, aren't circular (like this conversation seems destined). Further, in order to completely cover South America, I would have to establish dozens of "circles" of coverage, and there would be many that overlapped.... This would lead to Rage4 returning multiple records for those overlapped radii. No thanks.

    Edit: IP space in South America and Africa is very well defined by Maxmind.

  • gbshousegbshouse Member, Host Rep
    edited September 2013

    Regarding "First closest server": only first, best record is returned; the distance is calculated using Haversine formula. Since latency based GeoDNS is out of option, the two current GeoDNS modes are the best we can provide.

    Regarding MaxMind take a look at http://www.maxmind.com/en/city_accuracy

    If you have any idea how to calculate latency between two remote IP let me know, for sure we will add support for it.

  • Regarding "First closest server", how does Rage4 handle situations where Sao Paulo is geographically closer to Cape Town than to New York? "First closest" is hardly the fastest once you leave USA and Europe.

    As for Maxmind City... well, you don't need City level accuracy. Rage4 could benefit greatly by accurate Country level (Globally throughout the world) groups. I've been evaluating EdgeDirector all morning, they do Country level, not to mention Regional level (APIC, ARIN, RIPE, AFNIC, etc), groupings quite well. I don't understand why it's a problem for Rage4.

  • gbshousegbshouse Member, Host Rep

    @jimpop - but you can do the same with georegion mode, maybe not on country level, but regions are pretty well defined. We can add more for Africa and South America.

    Regarding "Rage4 is also slow at improvements and addressing customer Feedback" - we have limited resources and few ongoing projects. This autumn we are going to release new version of DNS service which will include many new features and improvements including those from feature request list

  • jimpopjimpop Member
    edited September 2013

    Rage4 georegion modes do work good, but country level is very much necessary in Africa and South America. The problems arise when trying to mix georegion modes with First Closest, you end up with some clients getting multiple records. It would be ideal to be able to route all of South America to Miami, except for Brazil, Argentina, Peru, and Chile. Of course, those exceptions are specific to me and my needs, the next person that comes along may desire other exceptions.

    Also worth mentioning, about Rage4, is their awesome 2-factor authentication.

  • DylanDylan Member
    edited September 2013

    @gbshouse said:
    The problem with Route53 approach is that they provide latency based GeoDNS but only to their DC

    I guess you may see that as a problem, but I don't because AWS has enough regions that it works pretty well. If someone's lowest latency is to AWS East, I can send them to my New York server; if someone's lowest latency is to AWS EU, I can send them to my Italy server; if someone's lowest latency is to AWS South America, to my Miami server.

    It's not perfect, no, but even an imperfect latency-based system is in my view better than the alternatives.

  • @gbshouse said:
    The problem with Route53 approach is that they provide latency based GeoDNS but only to their DC (it hard to measure AS path/latency between two remote IPs [server and client]). We can do the same but for example for some regions of US it can be tricky (we will have to assume that all DCs in let's say LA have the same latency/AS paths as our DC) so in my opinion it makes no sense.

    Point. Seen differences in pings to different DC's in same US city of 10ms on 40-50ms latency. But I don't agree this translates to "makes no sense". From my own experience and reading all the comments here, this makes a helluva more sense to me than using MaxMind or any geographically (long/lat) arrived at database.

  • gbshousegbshouse Member, Host Rep

    @andrzej - there is one problem with latency based GeoDNS and anycast networks. With anycast your network provider picks the shortest BGP path to our DNS server but it's shortest from network point of view and it doesn't mean that's the closest one by distance - client from Asia can be served by DNS PoP in US because of ISP peers. In this case we will return false positives if there are records located in Asia. That's why we decided to use georegions/distance based solution and that's why the clients are moving to us from Route53.

    Thanked by 1jmulvany
  • aglodekaglodek Member
    edited September 2013

    @gbshouse: as with most things, I'm pretty sure some kind of hybrid solution will prove most effective here; not one big lever, but rather many small levers. Call it a "Thinking DNS" ;)

    EDIT: it's been my experience that physical location sometimes (not always) means very little on the internet. And what's wrong with a "false positive" if it means better service/faster download - to Hong Kong, for example - from the US, rather than slower from Asia, pray tell?

    Last but not least, there is the speed of light to consider. Can't really see many such false positives between continents ;)

Sign In or Register to comment.