Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

[Cameron Byrne <cb.list6 at gmail.com>]

On Mon, Nov 9, 2009 at 7:18 AM, Andrew Sullivan <ajs at shinkuro.com> wrote:
> On Mon, Nov 09, 2009 at 02:52:15PM +0100, mohamed.boucadair at orange-ftgroup.com wrote:
>
>> authoritative servers. In the draft an authoritative server will
>> generate A64 records for IPv4-embedded IPv6 addresses but will not
>> generate AAAA records for these addresses. So a host or a resolver
>> needs to ask first for AAAA records. If an AAAA record is received
>> there is no need to ask for A64 records. Moreover, with A64 records,
>> IPv6-only hosts will generate exactly the same load on DNS server as
>> dual-stack hosts. Dual-stack hosts ask first for an AAAA record. If
>> they failed they ask for an A record. With A64 records, IPv6-only
>> hosts ask first for an AAAA record. If they failed they ask for an
>> A64 record.
>
> Then your other criterion fails: in order for this to work, all the
> resolvers in the entire world need to be updated.  Otherwise, how does
> a host that needs v6-only access to a v4-only host reach that host?
>
> If your answer is that you put an A64-enabled recursor in front of the
> authority server, this is no help: as far as anyone else in the world
> can tell, you're just server DNS64-generated AAAAs.  In such a case,
> A64 is a wheel that does no work.
>
>> Med/Eric: but draft-behave-dns64 describes in appendix B cases where
>> both IPv4-mapped IPv6 address and native IPv6 can be returned in
>> AAAA records. Then you need a "hint" for the selection of the
>> appropriate record otherwise you will overload the translators even
>> if native communications can be supported.
>
> The draft also says, "Don't do that."  I don't think people should do
> it.  And indeed, part of the reason not to do it is because you might
> cause people to use NAT64 when they shouldn't.  But note that the
> alternatives I suggest would work just as well in this case.
>
>> -       In a second step: A64 records will be introduced in
>> -       Authoritative DNS server and they can be used by DNS64
>> -       resolvers from step 1. The main benefit of this second step
>> -       is that theses IPv4-embedded IPv6 addresses (i.e., A64) have
>> -       a global scope and may be exchanged in referral (i.e., by
>> -       applications).
>
> To give you some understanding of the requirement you're imposing
> here, there's currently a dispute going on over in DNSOP about whether
> it is safe to introduce DNAMEs at the root.  One of the arguments
> against them is that they're too new.  The DNAME specification,
> RFC2672, dates from 1999, and DNAME has a backward compatibility mode
> where CNAMEs are synthesized in order to deal with clients that don't
> know about DNAME.  A64 doesn't offer such a compatibility mode, so it
> will simply break for such users.
>
> The basic problem you have here is that you want to solve a backward
> compatibility problem (make v6-only hosts talk to v4-only hosts) by
> introducing a new feature.  But the very fact that you want backward
> compatibility means in itself that you can't just upgrade all the
> hosts.  That means a new RRTYPE will not solve your problem, because
> the only people who can use it are the ones who can upgrade.  If they
> can upgrade, why not just move them to v6?

Agreed


>
>>
>> Med/Eric: I'm afraid to not agree with this conclusion. Please see below an excerpt form the draft:
>
> I _know_ that's what your draft says.  I claim you're wrong.  There's
> no way to make the scheme actually work with the deployed software and
> still achieve the goal of not having to upgrade everyone on the
> Internet unless you sometimes hand a synthetic AAAA to someone who
> asked for a AAAA.  You suggest that you'll reply with an A64 record to
> a AAAA query; but that's no good, of course, because the client asked
> for a AAAA and if it gets something else in the answer it's as likely
> as not to throw it away as malformed.  So, you admit that you're going
> to convert that A64 to a AAAA in the answer.  From the point of view
> of a querying agent, there is actually no difference here between the
> synthetic AAAA that comes from a DNS64 synthesizing from an A recor,
> and the A64-munger that synthesizes the AAAA from the A64.  It's still
> a AAAA record.
>
>> Med/Eric: This is the aim of section 4.7. We think that a new query
>> type would be useful to avoid this issue. This new query would be
>> used to retrieve both A64 and AAAA records. A more generic proposal
>> as currently discussed in dnsext mailing list would be solve this
>> issue.
>
> This is again the "upgrade everyone" answer in disguise.  Changing all
> the DNS software on the Internet so that it can query for more than
> one RR at the same time using an as-yet-unspecified mechanism is not
> the way to quick deployment of cheap solutions intended to paper over
> the fact that IPv6 deployment has not happened in time for v4
> exhaustion.  The point of the work we're doing is supposed to be fast
> and fairly easy deployment with few barriers.  Deploying a new query
> type that likely requires server-side processing (and to work out the
> not insignificant problem of what the caches do when they have a
> partial answer) does not meet that requirement.
>
>> Med/Eric: Why? for A64-compliant recursors, the behaviour is as follows: a
>>    DNS64 recursor may return an A64 record as a response to AAAA query
>>    if no AAAA record is available for the specified resource (A64
>>    records are converted to AAAA records in the answer).
>
> All you're doing here is moving around who has to make the
> A64-in-case-AAAA query decision.  The DNS64 recursor needs to
> instead.  _Someone_ has to.
>
>>   If it has only A64 records, then it either has to do special processing when it receives a AAAA query, and convert the AAAA into an A64 query; or it has to return NOERROR with an empty answer for the AAAA query, and simply not get the communication benefit of NAT64 that was the whole purpose of the exercise in the first place.
>>
>>
>> Med/Eric: The draft says that at a first stage, an A64 can be returned when a AAAA query is received (only when no AAAA is stored).
>
> Yes.  So "special processing".  The first state will, I predict, never end.
>
>> I haven't really thought through the security implications of any of
>> this, but at first blush it seems to me that the A64 record is going
>> to offer another opportunity to inject DNS poison, since an attacker
>> is going to know something about the capabilities of a querying host
>> and will also automatically know what query is coming next.
>>
>>
>> Med/Eric: This is valid for all query types, right?
>
> How?
>
>> Med/Eric: We have two parts here: the problems to be solved and the
>> solution space. The current draft describes both the problem and a
>> solution candidate. Should we separate both parts and lets agree
>> first on the issues, then analyse the solutions candidates?
>
> I'm reasonably content with the problem you described: I get why it's
> a problem, and you're putting a finer point on my original impulse
> that whenever you have funky data in the DNS you want to be able to
> identify it in case it's relevant.  In this case, it turns out for
> some applications it _is_ relevant, so the only question is how one
> identifies the data, especially since part of the problem to be solved
> is that the whole thing works without anyone else doing any upgrades.
> A new RRTYPE doesn't solve that latter problem, so I think it has to
> be discounted as a solution.
>
> A
>
> --
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
> _______________________________________________
> Behave mailing list
> Behave at ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>