apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCarthaigh <c...@stdlib.net>
Subject Re: cvs commit: apr configure.in CHANGES
Date Fri, 29 Aug 2003 09:26:09 GMT
On Thu, Aug 28, 2003 at 09:56:14PM -0700, Justin Erenkrantz wrote:
> --On Thursday, August 28, 2003 10:54 AM +0100 Colm MacCarthaigh 
> <colm@stdlib.net> 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 
into 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;


In the case of an IPv4 mapped address; ::ffff: would
be mapped to :


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

> 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: colm+pgp@stdlib.net
colm@stdlib.net					  http://www.stdlib.net/

View raw message