Re: [BEHAVE] [Francis.Dupont@fdupont.fr: [dnsext] DNS64 and lying cache servers]

Hello folks,

There is a reference below to a disaster that can occur
when DNS64 encounters mobility.  Is there something
more I can read about this?

Thanks in advance for any pointers to reading
material.

Regards,
Charlie P.

Brian E Carpenter wrote:
> It's an interesting point but it misses the point IMHO:
> we *have* to lie to classical IPv6-only hosts.
>
> I've always preferred the stub resolver approach, right back
> to draft-van-beijnum-v6ops-mnat-pt-00.txt, but that preference is
> useless if the real world contains classical IPv6 hosts.
>
>    Brian
>
>
> On 2009-07-31 19:44, Andrew Sullivan wrote:
>   
>> Dear colleagues,
>>
>> Some of the participants in dnsext are reluctant to join another
>> mailing list the subject of which is mostly not of interest to them.
>> I have offered to accept comments from those participants and forward
>> them to behave when appropriate and if asked.  Attached is one such
>> example.
>>
>> A
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> [dnsext] DNS64 and lying cache servers
>> From:
>> Francis Dupont <Francis.Dupont@fdupont.fr>
>> Date:
>> Wed, 29 Jul 2009 14:28:26 +0200
>> To:
>> namedroppers@ops.ietf.org
>>
>> To:
>> namedroppers@ops.ietf.org
>>
>>
>> [Please forward this to the behave mailing-list]
>>
>> [I use the term "cache server" as a synonym of "recursive DNS server"]
>>
>> DNS64 (draft-ietf-behave-dns64-00.txt) is usually presented with
>> a cache server serving a lot of NAT64 IPv6-only clients and performing
>> AAAA RR synthesis from A RRs to make external IPv4-only servers
>> reachable through a NAT64 translator.
>>
>> So this is essentially a lying cache server: this is *bad* for the
>> usual reason (it breaks DNSSEC). Worse, its lie is very location
>> dependent, so it has very bad interaction when the DNS is assumed
>> to be location independent, for instance with Mobility.
>>
>> But as explained in the draft at the end of the section 2 Overview
>> this is not the only way to deploy DNS64: in the "DNS64 in stub-
>> resolver mode" the synthesis is done as close as possible to the
>> client so there is no longer lying issues.
>>
>> Note this doesn't extend to some other lying DNS proposals from
>> NAT based IPv6/IPv4 transition mechanisms because DNS64 uses a
>> small set of static parameters (mainly the Pref64::/n) which is
>> the only state of the synthesis process.
>>
>> So I recommend the DNSEXT WG to advise to put more work into
>> the sub-resolver mode (producing DNS64 capable stub-resolvers,
>> which should be very easy, and solving the DNS64 parameter
>> distribution issue) than into the DNS server mode which should be
>> recognized as an example of a false good idea.
>>
>> Regards
>>
>> Francis.Dupont@fdupont.fr
>>
>> PS: Acknowledgments to Mark Andrews who introduced the strong but
>> correct "lying" term, and to Wassim Haddad who remarked DNS64 and
>> Mobility together can easily lead to disasters.
>>
>> --
>> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/namedroppers/>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
>>     
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>   