On Dec 4, 2014, at 9:00 PM, Mark Andrews <marka(_at_)isc(_dot_)org> wrote:
In message <74DF5B53-055C-4235-A8FA-E8B38E007F45(_at_)nominum(_dot_)com>, Ted
Lemon writes
:
On Dec 4, 2014, at 10:02 PM, George Michaelson <ggm(_at_)algebras(_dot_)org>
wrote:
Hang on.. the deployment of DNSSEC backed applications is a bit iffy if
we depend on deployment of DNS based tricks to cover for V4/V6
interoperation surely?
DNS64 can be done by the client, in which case DNSSEC validation can be
performed _before_ translating the IPv4 address from the A record into an
IPv6 address in the NAT64 prefix.
Which requires every DNSSEC aware client to also be DNS64 aware.
I though we were trying to remove NAT kludges requires that they
be kept forever.
The BEHAVE working group was unable to find any other approach to get DNSSEC
and NAT64 to work together. If you have a proposal, please share.
RFC 6147 also get DNSSEC signalling completely wrong. There is NO
combination of bits that indicates validation will / will not occur.
Yes, you reported that as an errata on 2012-05-30. It was rejected on basis of
"Changes that are clearly modifications to the intended consensus, or
involve large textual changes, should be Rejected.",
http://www.rfc-editor.org/errata_search.php?rfc=6147.
Additionally the discover mechanism for the DNS64 parameters is to
say the least baroque. It would have been much simpler to add a
EDNS option so the nameserver could actually return them or the
addresses it would have otherwise returned if DO=1 is set. These
could be cached along with the NODATA response by intermediate
nameservers.
That does appear a nice approach for a DNS64-aware client to learn the NAT64
prefix.
-d