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

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