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

Mime
View raw message