> I believe Mark is referring to a validating stub (not a full > service resolver) behind a NAT64/DNS64. If such a stub uses the > DNS64 as its upstream resolver, it will encounter a variety of > potential failures with responses that can't be validated because > the DNS64 passed them on without checking (CD=1), and without > retrying other available authoritative servers for the zone (in > case the response was spoofed, or in case some of the servers > gave broken responses while others were working). (Presumably > the validating stub is aware of DNS64 translated responses and > the NAT64 prefix via RFC7050 support, and can thus authenticate > the original response). Shumon.
Just a random thought regarding DNS64. A recursive resolver that does DNS64 synthesizes AAAA records based on A records if no AAAA records are available. A validating recursive resolver processing data in a secure zone knows that AAAA records are not available based on the type bitmap in NSEC or NSEC3 records. So my thought is, what if the DNS64 part returns that NSEC or NSEC3 record along with the synthesized AAAA record. In that case, a validating stub could notive that it cannot validate the AAAA RRset and that there is a valid NSEC/NSEC3 RRset that proves no AAAA records exist. The stub resolver can then conclude a NODATA response for a AAAA query. Obviously, a validating stub resolver may find other way to trigger an NSEC/NSEC3 response if the DNS64 part doesn't include those records. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
