Tim Shoppa wrote:
Others have approached the issue of geographically-based servers where requests are routed to a nearby (not necessarily as the bird flies, but more as the network packet flies) server whenever possible and load balancing is done. Akamai, google, etc. do this quite effectively, but not using only DNS. They do it through colating (colocating?) servers at every network hub and doing funny tricks in the routers, mostly. But DNS is involved too.
Yeah. The problem with bind and other "normal" DNS software is that they really are not designed for what we would like to have: a huge ever-changing pool of ip addresses being load-balanced with a certain weighting criteria. And possibly geographically as well. The biggest problem with the pool at the moment is the load balancing. Being geographically aware and returning servers that are close to the client is not as crucial, but would be a nice feature.
With BIND and other regular DNS software you have to resort to all kinds of tricks and still the balancing act is not very good. Of course there is DNS client/server software around that disregards the TTL in replies and caches one response for a long time, thus skewing load balancing made by a pool DNS server, but I still think there would be value in running a special DNS server software for the pool.
As a non-commercial and very distributed project, I guess we can forget even thinking about the routing tricks commercial providers use for load balancing / geographically aware services and just stick with the DNS. I can provide a (secondary) server for the pool for use with a custom DNS server software if/when the time comes.
Tapio _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
