On Fri, 26 Jan 2007 09:20:46 -0500, Edward Lewis <[EMAIL PROTECTED]> said:
> 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. Yes. The reason I chose to post this on DNSOP is that it might make sense after all to make recommendations for iterative servers with regard to this. Yes, it has probably been declared OT ages ago, but maybe it's time to revisit. An increase of queries by a factor of 3-4 when a server is dead strikes me as pretty bad. If it turns out that many implementations make a bad choice, shouldn't there be some guidance on how to do it better? I agree, though, that OARC might be a better place at least as long as the cause for this effect is unknown. I'm happy to repost the issue to [EMAIL PROTECTED] if the chairs advise me to take it off this list. > 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.) Thanks for the pointer. > 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. In this case, the TLD server is as simple as it can be: no load balancers or routing tricks, just a single unicast host. And all other servers for the TLD appeared to have been working well, at least from the places covered by the RIPE TTM boxes according to <http://dnsmon.ripe.net/>. Any algorithm that results in more queries being sent to the only unreachable server in the set seems severly broken to me. -- Alex _______________________________________________ DNSOP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dnsop
