I hand-waved the question about DNSSEC and DNS64 in my talk just now. The full answer is in http://tools.ietf.org/html/draft-ietf-behave-dns64 Extracting the main bits: (section 5.5) 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 synthesis itself. 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. ... (section 6.2) 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 behalf. -- Regards Brian Carpenter