I hand-waved the question about DNSSEC and DNS64 in my talk
The full answer is in
Extracting the main bits:
1. If CD is not set and DO is not set, vDNS64 SHOULD perform
validation and do synthesis as needed.
2. If CD is not set and DO is set, then vDNS64 SHOULD perform
validation. Whenever vDNS64 performs validation, it MUST
validate the negative answer for AAAA queries before proceeding
to query for A records for the same name, in order to be sure
that there is not a legitimate AAAA record on the Internet.
Failing to observe this step would allow an attacker to use DNS64
as a mechanism to circumvent DNSSEC. If the negative response
validates, and the response to the A query validates, then the
vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
answer to the client.
3. If the CD bit is set and DO is set, then vDNS64 MAY perform
validation, but MUST NOT perform synthesis. It MUST hand the
data back to the query initiator, just like a regular recursive
resolver, and depend on the client to do the validation and the
The disadvantage to this approach is that an end point that is
translation-oblivious but security-aware and validating will not
be able to use the DNS64 functionality. In this case, the end
point will not have the desired benefit of NAT64. In effect,
this strategy means that any end point that wishes to do
validation in a NAT64 context must be upgraded to be translation-
aware as well.
Existing DNSSEC validators (i.e. that are unaware of DNS64) will
reject all the data that comes from the DNS64 as having been tampered
with. If it is necessary to have validation behind the DNS64, then
the validator must know how to perform the DNS64 function itself.
Alternatively, the validating host may establish a trusted connection
with the DNS64, and allow the DNS64 to do all validation on its