Subject: [dnsext] DNS64 and lying cache servers

From: Francis Dupont <[email-masked]>
Date: Wed, 29 Jul 2009 14:28:26 +0200

[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/>

---

From: Florian Weimer <[email-masked]>
Date: Wed, 29 Jul 2009 13:09:22 +0000

> recognized as an example of a false good idea.

Stub behavior is out of the scope of the DNSEXT and DNSOP WGs, see the
discussions about address selection.  And DNS64 appears to be just
another form of address selection.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Francis Dupont <[email-masked]>
Date: Wed, 29 Jul 2009 15:46:01 +0200

In your previous mail you wrote:

   * Francis Dupont:

=> no, DNS64 is about AAAA RR synthesis from A RRs when there is no AAAA,
this is fully orthogonal to address selection (which is no more in
the BEHAVE WG charter than in DNS* WGs').
To summary there are two possible places where to perform the synthesis,
my concern is about to do at the right place and not at the place which
seems easy.

Regards

---

From: Florian Weimer <[email-masked]>
Date: Wed, 29 Jul 2009 14:05:43 +0000

> the BEHAVE WG charter than in DNS* WGs').

Address selection is about suppressing address records so that they
are never used by the application (unless special conditions, like
unreachable servers, are met).

> my concern is about to do at the right place and not at the place which

The right place is inside the stub (or in close cooperation with the
stub), and that seems to be out of scope to me, based on prior
discussions.

(It also suffers from the "not b****y likely" problem because as I
understand it, BEHAVE aims at not requiring far-reaching client-side
changes.)

---

From: Francis Dupont <[email-masked]>
Date: Wed, 29 Jul 2009 17:23:43 +0200

=> I used another definition of address selection but mine or
yours are not related to DNS64.

   
=> I agree the DNS64 details are not in the scope of DNS* WGs but
to avoid spurious deployment of lying cache servers *is*.
So as BEHAVE people'd like to know what we (DNS people) think about
DNS64 I can't see a reason to not explain we prefer stub-resolver mode.

=> DNS64 proposes the two modes but seems to prefer the DNS server one.
Our role should be to explain that from the DNS point of view this mode
has many critical issues so the preference should be reconsidered
(to summarize the stub-resolver mode should be investigated too and
not kept only on paper. For instance the stub-resolver mode should be
supported as the default mechanism and the DNS server mode used as the
fallback for nodes which are not DNS64-aware, i.e., which don't ask
for DNS64 setup by DHCPv6).

Regards

PS: what is exactly your concern? Not give advise to BEHAVE? Another
recommendation?