[time] More fun with Geo DNS
Fri Nov 10 14:36:29 UTC 2006
In the last few months, I spent a couple nights playing with geographic
DNS resolution for the pool.ntp.org project.
Some of you may remember that I made a prototype that used BGP tables to
resolve the closest servers to each client. It didn't work so well,
because BGP doesn't take latency into consideration.
I decided to try something else this time and go with IP to lat/lon
conversion and return the closest servers geographically. At first, this
doesn't seem like a good idea since nothing guarantees that two servers
in the same city will be at a short network distance from each other. In
practice, however, it seems that most cities have route exchange centers
so this works pretty well -- at least in my limited testings.
You can try it out, the addresses are:
ntp-pool-test.logidac.com will return the closest servers in random order.
Of course, please post your comments, suggestions and ideas to the list.
If you're getting inaccurate results, please post the output from the
following command to the list or directly to me:
dig debug.ntp-pool-test.logidac.com txt
Please refrain from using ntp-pool-test.logidac.com in an actual NTP
server, since I'm playing a lot with that server and you could get bad
data or no data at all.
Right now the prototype is using the HTTP Geo City Service from MaxMind
(http://www.maxmind.com/app/web_services_city_usage), so every DNS query
generates a HTTP query to MaxMind. I've implemented a caching mechanism
to reduce the number of HTTP queries, but in production this would need
to be improved.
Because it uses geographic instead of network coordinates, this system
will inherently never be perfect, but if a client tries to reach three
or four servers, there's a good chance that there will be a least one or
two good ones.
I don't see a better way of doing it that is viable for this
project. The OASIS project (http://oasis.coralcdn.org/) has a script
running on each one of their servers that does a traceroute toward the
client to figure out on what part of what network the client is on. I
don't think that this is something that we can do.
Well, I think that's about it. Let me know how it works for you.
Guillaume Filion, ing. jr
Logidac Tech., Beaumont, Qu?bec, Canada - http://logidac.com/
PGP Key and more: http://guillaume.filion.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://fortytwo.ch/mailman/pipermail/timekeepers/attachments/20061110/1eec8059/attachment-0001.pgp
More information about the pool