Re: IP addresses sorted in reverse order
> On Thu, Jun 01, 2006 at 11:54:59AM +0200, Matus UHLAR - fantomas wrote:
>
> > Nothing "relies". It's just if you will receive addresses in some order, you
> > should not reorder them unless you know what order they should be delivered
> > in (e.g. ordering via RFC3484)
On 02.06.06 14:37, Gabor Gombas wrote:
> RFC3484 has _nothing_ to do with the NSS. If you are using the glibc
> interfaces, then you should only consult the relevant standards (POSIX,
> SUS, whatever). And those standards do not contain ordering constraints.
It's glibc that folows the RFC 3484 convention when sorting addresses, look:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/NEWS?rev=1.147.2.13&content-type=text/x-cvsweb-markup&cvsroot=glibc
Version 2.5
* For Linux, the sorting of addresses returned by getaddrinfo now also
handles rules 3 and 7 from RFC 3484. Implemented by Ulrich Drepper.
> If you want to rely on the address ordering in the DNS reply,
and when I said "nothing 'relies'", I meaned that nothing relies on the
order of hosts provided and I still mean it.
I just said that the order provided by nameserver is sorted so the host
closest to requester should be listed as first, so different requesters get
addresses of their closest servers according to the network topology.
> then you
> should not use the generic NSS interface (like gethostbyname() or
> getaddrinfo()) but you should use the resolver directly instead (see
> resolv(3)).
So you are saying that since glibc mixes order of replies, developers should
quit using glibc functions because they will still uselesly sort addersses?
What I want to get, is glibc behaving the same way as libresolv, unless it
may provide better services.
> > I'm afraid this is not applicable and also you probably did not understand
> > me.
> >
> > If there are clients on network A and network B and servers on network A and
> > network B, DNS server may sort replies to clients so client A would get
> > address of server A first, server B next. Client B would get addresses of
> > server B first, server A next.
>
> I'm perfectly aware of that and it seems you are the one who do not
> understand me. If you are already able to generate different DNS replies
> for A and B, then the SRV records should look like:
and I also said that using SRV is not applicable, because this is name-to
address mapping, not explicit sorting of services in any order.
This is about the main functionality of gethostbyname() or getaddrinfo(),
and for MX and SRV it's the same - in what order to provide records with the
same priority/weight setting? To sort them or not to sort them internally?
> (Note the difference in the Priority field). This does _exactly_ what
> you want and is standard-compliant. You just have to modify your ssh
> client to query the SRV records for "_ssh._tcp" when it wants to connect
> to "server.dom.ain" (and likewise for any other services).
The priority is not designed to be configured by dns servers, it's meaned to
be set up by DNS admin. It's something like MX, which definess the same
priority for all hosts.
> > > An other option would be to play with routing instead of the DNS to
> > > direct your clients to the nearest server.
> >
> > Pardon? If one of servers is in our company's network and other is in
> > differet network, company, town, how do you imagine this?
>
> Certainly you can only do this if you control the routing decisions of
> the clients.
They are not, but since my DNS servers are under my control, I would like to
provide my clients addresses
> But since you filed this bugreport I assume you have full
> control of the clients, otherwise the bugreport has no sense. And yes,
> messing with the routing is always tricky, but on intranets it is
> sometimes more efficient than DNS games.
I only may repeat, you completely do NOT understand what I am talking about
and you are still messing up with different things.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
He who laughs last thinks slowest.
Reply to: