Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09

[Mark Andrews <[e-mail]>]

Firstly this draft will not work with a non DNS64 aware intermediate
name servers as it will not understand the CD signaling.  This goup
needs to accept that intermediate name servers will need to be DNS64
aware and go back and redo RFC 6147 accepting that.

DNSSEC made the same mistake of trying to make a change work through
non DNSSEC aware servers.  We gave up trying to do that and accepted
that intermediate servers needed to be DNSSEC aware.

This working group has continually failed to understand how DNSSEC
works.  It wanted DNS64 to work with existing DNSSEC aware infrustucture
which was specifically designed to defeat what DNS64 does.

Instead of saying "We need to make intermediate resolvers DNS64
aware" and accept that DNS64 won't work until those servers are
upgraded the same way as dnsext said "We need to make intermediate
resolvers DNSSEC aware" it tried to do the impossible.

Sending a synthesised response to a DO=1 query is *insane* if the
NO DATA response is signed but that is what RFC 6147 says to do.

A sane thing to do would have been to add a EDNS extension which
returned the synthesised addresses along with the NO DATA response
to DNS64 aware clients (signalled by the presence of the option in
the query).

For non DNS64 aware clients you synthesis unless the synthesis can
be detected (DO=1 + a signed NODATA response) in which case you
send the signed NO DATA response.

The intermediate DNS64 aware recursive server would cache both the
NO DATA response and the synthesised addresses from the returned
option data.  For non DNS64 aware clients the synthesised responses
would be returned to clients that can't detect the synthesis and
NO DATA would be returned to those that can.  For DNS64 aware client
the full response would be sent.

The EDNS option could also be used to discover prefix information
if in addition to the addresses to also sent prefix length data.

Query:
	<code><opt-length=0>
Response:
	<code><opt-length=0>
or
	<code><opt-length><ttl>[<prefixlen><synthesised-address>]+

If the client has a trust relationship with its recursive server
to can trust the answer returned and use that to set AD as
appropriate to down stream clients.

EDNS support is manditory for IPv6 nodes.  There is no reason to
avoid using it.

Go back and fix RFC 6147 to work properly with DNSSEC.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]