On Dec 4, 2014, at 9:00 PM, Mark Andrews <marka@xxxxxxx> wrote: > In message <74DF5B53-055C-4235-A8FA-E8B38E007F45@xxxxxxxxxxx>, Ted Lemon writes > : >> On Dec 4, 2014, at 10:02 PM, George Michaelson <ggm@xxxxxxxxxxxx> 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