Re: glibc's getaddrinfo() sort order
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.
Reply to: