Subject: Re: release and A instead of AAAA?

Re: release and A instead of AAAA?

From: Charles Hardin <ckhardin_at_gmail.com>
Date: Wed, 8 Dec 2010 11:23:48 -0800

You can run the policy based off the mapped addressed returned. Since,
you can also have a DNS server return a mapped IPv4 address in a
T_AAAA record anyway. Setup bind to do this, our QA group stumped me
for a bit on that one.

So, where do you make the decision point - a query failure at T_AAAA
and also check for a mapped v4 address? or check the result for a
mapped v4 addr and then do the "right" thing.

Regardless, a decision point is going to be made somewhere in this
code path and since I found a case where a T_AAAA record returned from
a bind setup is a mapped address to deal with it was the same code
path a T_AAAA to T_A fallback code path as well.

Using the address is just a

if (IN6_IS_ADDR_V4MAPPED()) {
}

then do the specific logic in using the socket calls on the system you are on.

Since v4 can always been done this way - like say a code path where
you check a string a convert that to an "address" or do the resolve,
then the code above can still be done if someone does a string based
v4 address as well.

It is just a choice, but I already had to deal with the addresses like
above and so preferred the logic in cares as is.

Charles

On Wed, Dec 8, 2010 at 11:10 AM, William Ahern
<william_at_25thandclement.com> wrote:
> On Wed, Dec 08, 2010 at 08:55:27AM -0800, Charles Hardin wrote:
>> Daniel,
>>
>> Our group took the position that an IPv4 (T_A) record can be
>> represented as an IPv6 address (T_AAAA) record, so a fallback is
>> appropriate and can still return a mapped IPv6 address.
>
> The problem though is that not all systems treat mapped addresses the same
> way. Some will route an IPv4-mapped address through the IPv4 network. Others
> will route it through the IPv6 network regardless. Still others will just
> drop them entirely because of security concerns--on OpenBSD IPv4-mapped
> addresses are rejected immediately inside both bind(2) and connect(2).
>
> So an interface isn't really being helpful in crafting mapped addresses
> because the application still has to deal with all of the policy regardless.
> A better interface would make it easier to deal with policy, not try to
> paper-over the problem. But this usually involves a tie-in with the
> pertinent sockets library, so it can't just occur inside of the resolver.
>
>> We actually added this logic to the another resolver a while back, and
>> if it gets removed from libcares - then, we would just add it back.
>>
>> I don't really think it is a hack, just a choice about do you return a
>> IPv6 address if at all possible for an AF_INET6 query.
>
>
Received on 2010-12-08