On Wed, 1 Sep 2004, Steve Francis wrote:
Paul Vixie wrote:
not only is it bad dns, it's bad web service. the fact that a current routing table gives a client's query to a particular anycasted DNS server does not mean that the web services mirror co-located with that DNS server is the one that would give you the best performance. for one thing, the client's dns forwarding/caching resolver might have a different position in the connectivity graph than the web client. for another thing, as-path length doesn't tell you anything about current congestion or bandwidth -- BGP is not IGRP (and thank goodness!).
I'm aware that web clients are not colocated with the client's name server, and that BGP does not attempt to optimise performance.
However, I suspect that in most cases, the client is close enough to the name server, and the BGP best path is close enough to the best path if it were based on latency, that most clients would be happy with the result most of the time. I'm not aiming for 100%, just Good Enough.
This is not always a good assumption: 1) dial clients sometimes get their DNS info from their radius profile (I believe) sometimes that dns server isn't on the same ASN as the dialup link. 2) many people have hardcoded DNS servers over the years, ones that have drifted from 'close' to 'far' 3) corporations with multiple exit points and larger internal networks might have DNS servers that exit in one country but are queried internally from other countries/states/locations. I think Paul's partly pointing out that you are using DNS for the wrong thing here, and partly pointing out that you are going to increase your troubleshooting overhead/complexity... Users on network X that you expect to use datacenter Y are really accessing datacenter Z because their dns cache server is located on network U :( I'm glad to see Joe/Paul/Bill jump in though... they do know quite a bit more about the practice of anycasting services on large networks.