Anthony Towns writes ("Re: glibc's getaddrinfo() sort order"): > On Fri, Sep 07, 2007 at 01:06:06AM +0200, Kurt Roeckx wrote: > > It's atleast in the spirit of the rfc to prefer one that's on the local > > network. It might be the intention of rule 9, but then rule 9 isn't > > very well written. > > Rule 9 seems perfectly well written, it just does something you > (reasonably) consider undesirable.
Should I take that as agreement with Steve's and my view, that we should by default not apply rule 9 to IPv4 ? Your opinion seems unclear to me. We haven't heard from the rest of the committee. Does anyone have an answer to my point that application of rule 9 changes the long-established meaning of existing DNS data ? (In ways, I would add, which have proven to cause significant operational problems in practice.) As I say, I think that point is unanswerable and leads inevitably to the conclusion that we should disable this behaviour by default. The rest of your (AJ's) mail seems to be getting bogged down a bit. I'll try to answer what I see as the key aspects. > In addition, I think there's two different aspects here: the first is > "should getaddrinfo() return results in random order to aid in load > distribution?" and the second is "is prefix matching a reasonable way > to determine a good host to use?" I disagree with your answer to that first question. gethostbyname returns results in random order. getaddrinfo should do the same. ("random" isn't quite true but it's true enough in the usual case.) > AFAICS, the answer to the first question is simply "no, it shouldn't" -- > randomised load balancing like that needs to be done at the application > level, You are mistaken. Randomised load balancing like that is _already done_ using multiple IPv4 addresses in the DNS. It has been done this way for nearly two decades. > [stuff] > Doing it by changing Rule 9 to: I don't think this kind of complexity is warranted here. Even if it were, you seem to be proposing a strategy which depends on guessing whether communication with a particular destination address would involve NAT, which would be fragile. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]