On Thu, Aug 28, 2003 at 09:56:14PM -0700, Justin Erenkrantz wrote:
> --On Thursday, August 28, 2003 10:54 AM +0100 Colm MacCarthaigh
> <[EMAIL PROTECTED]> wrote:
>
> >If gni_mapped worked for you then something is definitely different
> >anyway.
>
> Well, I did some more tracing of what's going on.
>
> Darwin's getnameinfo() isn't handling the IPv6-IPv4 mapping, so it is
> sending the address to its DNS server to be reversed looked up without
> modification.
Is that a real DNS server, or lookupd ? Am I right in thinking
lookupd is more or less what everone else calls nscd?
> Aren't DNS servers supposed to understand these IPv4-mapped
> addresses too?
Nope :) DNS servers don't even understand IPv4 addresses in that
sense, you can't query a DNS server saying "give me the reverse
of this IPv4 addresss", your resolver has to turn 209.237.227.195
into 195.227.237.209.in-addr.arpa for anything to happen. In the
case of IPv6 there are two reverse zones it should be asking for,
so for 2001:770:18:2:260:CFFF:FE20:F45C it should be asking for;
C.5.4.F.0.2.E.F.F.F.F.C.0.6.2.0.2.0.0.0.8.1.0.0.0.7.7.0.1.0.0.2.ip6.int
and
C.5.4.F.0.2.E.F.F.F.F.C.0.6.2.0.2.0.0.0.8.1.0.0.0.7.7.0.1.0.0.2.ip6.arpa
In the case of an IPv4 mapped address; ::ffff:209.237.227.195 would
be mapped to :
3.c.3.e.d.e.1.d.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.(int|arpa)
And this isnt goign to get very far!
> That is, must the client resolver detect and downgrade
> automatically? (Looking at glibc, that's exactly what it does in
> resolv/nss_dns/dns-host.c.)
Yep :) From RFC3493, section 6.2 :
on getnameinfo;
"If the socket address structure contains an IPv4-mapped IPv6 address
or an IPv4-compatible IPv6 address, the implementation shall extract
the embedded IPv4 address and lookup the node name for that IPv4
address."
> Also, upon review of the manpages and RFC 2553, getipnodebyaddr is the only
> one expliclitly to handle IPv4-mapped addresses.
Yep, this is one of the reasons why RFC2553 needed a good rewrite :)
> So, adding that call to Jeff's gni_mapped.c yields:
>
> look up via IPv4: 0,0/www.ibm.com
> look up via IPv6: 8,0/not found
> look up via IPv6: 0,0/www.ibm.com
>
> where the code looks like:
>
> struct hostent *hptr;
> hptr = getipnodebyaddr(&sin6.sin6_addr, sizeof sin6.sin6_addr,
> sin6.sin6_family, &rc);
> printf("look up via IPv6: %d,%d/%s\n", rc, errno, hptr->h_name);
> freehostent(hptr);
getipnodebyaddr has functionality that pushed into getnameinfo
more recently, and this is one of them. getipnodebyaddr() is deprecated
by RFC3493 and it's use is now discouraged. So I really would recommend
against putting it into APR.
> Also, the BUGS for the Darwin impl say:
>
> The current implementation is not thread-safe.
>
> So, yes, I guess we can step down for the resolver as your patch did. But,
> I'm wondering whether this is really a 'bug' in Darwin. -- justin
Assuming RFC2553; I guess it's technically not a bug. But as far
as the POSIX standard (I believe) and RFC3493 (which obsoletes
2553) are concerned, it's a bug. But that's a bit unfair since those
standards are only 3 months old ;)
It definitely is unusual in the world of getnameinfo() implementations,
everyone else it did the sensible thing.
--
Colm MacC�rthaigh Public Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/
