Subject: [BEHAVE] [[email-masked]: [dnsext] DNS64 and lying cache servers]

From: Andrew Sullivan <[email-masked]>
Date: Fri, 31 Jul 2009 03:44:43 -0400

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

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

Subject: [dnsext] DNS64 and lying cache servers
From: Francis Dupont <[email-masked]>
To: [email-masked]
Date: Wed, 29 Jul 2009 14:28:26 +0200
List-Id: <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

[email-masked]

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>