This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: getaddrinfo and AF_UNSPEC w/ IPv4/6 messes up ai_canonname?
- From: Pekka Savola <pekkas at netcore dot fi>
- To: Ulrich Drepper <drepper at redhat dot com>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Mon, 26 Aug 2002 08:45:20 +0300 (EEST)
- Subject: Re: getaddrinfo and AF_UNSPEC w/ IPv4/6 messes up ai_canonname?
On Sun, 25 Aug 2002, Ulrich Drepper wrote:
> Pekka Savola wrote:
> > 1) with PF_INET, this does not happen (CNAME entry is returned, not
> > addresses -- at least as far as I could see): thus the current behaviour
> > does not seem the same between address families.
>
> I don't really know what you mean. For PF_INET no IPv6 addresses are
> returned so you cannot mean this. The code used is the same if PF_INET
> or PF_UNSPEC is used and so numeric addresses would also be returned if
> the internal gethstbyaddr calll fails.
What I mean is if I modify the test code to set 'hints.ai_family =
PF_INET', the code does not return numeric _IPv4_ addresses but only the
name.
In the contrary, with 'hints.ai_family = PF_INET6' or PF_UNSPEC, the code
returns first IPv6 addresses and then the name (with PF_UNSPEC).
So it appears with PF_INET6 does not return a name at all. It appears to
me that CNAME is associated with PF_INET here.
The name should always be returned first, if addresses should be returned
at all. (At least intuition tells me the the user is looking for a
canonical *name* not addresses).
> > 2) (not really motivation, but still..) e.g. BSD libc does not return
> > addresses (the test works as "expected"); I haven't checked other
> > implementations.
>
> That's indeed no motivation. But you could do one thing: look at the
> entire list of records returned on a BSD system. Is the one you expect
> really the only one? Or is it just a matter of ordering.
On BSD system, the output of the modified code is:
host: ftp.kame.net, canon (if any): kame220.kame.net
host: ftp.kame.net, canon (if any): kame220.kame.net
host: ftp.kame.net, canon (if any): kame220.kame.net
On Glibc 2.2.5, it was:
host: ftp.kame.net, canon (if any): 2001:200:0:4819:210:f3ff:fe03:4d0
host: ftp.kame.net, canon (if any): 3ffe:501:4819:2000:210:f3ff:fe03:4d0
host: ftp.kame.net, canon (if any): kame220.kame.net
I don't know whether this behaviour is standardized or in the process of
being done at the moment.
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords