At 14:12 +0100 1/26/07, Alexander Gall wrote:
What strategies to deal with unreachable servers do common implementations use? I would have thought that most of them prefer the servers with the lowest RTT, like BIND does. Unreachable servers would have an infinite RTT and should only be queried occasionally to check whether they have become reachable again. Either this is not true and the number of misbehaving servers is large or a relatively small number of misbehaving servers generates the bulk of these queries.
Have you heard of ISC's Operation and Analysis Research Center (https://oarc.isc.org/)? That is one forum for questions like this.
There is no standard defined for the behavior of iterating servers. There is also no standard practice. There was an interesting paper by the Cooperative Association for Internet Data Analysis (http://www.caida.org/home/) that illustrated this, the paper might be a bit dated now.
The paper measured the name server selection of different implementations when no servers were reachable. That sounds like a crazy measurement, but it revealed tendencies. Arguably the most logical were results that showed an even distribution among all of the unreachable servers, the least logical were servers that would try only some. (You'll have to consult the paper to fill in the details.)
I have seen situations where other factors have played a role in the behavior of iterating servers, usually involving firewalls, load balancers, routing tricks, etc. When you have two ends of a protocol each trying to figure out how to deal with the other by interpreting what and how things are being said instead of being open about it, well, divorces and alimony are the results. Ummm, what I mean is, the resolvers are trying to sense the best way to deal with the name servers. Name serves are trying to sense what is the best way to scale to meet demand. In all the dancing about the issue, toes get stepped on.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Dessert - aka Service Pack 1 for lunch. _______________________________________________ DNSOP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dnsop
