On Sun, Nov 01, 2020 at 03:23:14PM +0100, Philip Homburg wrote:
RFC 6147 is standard track. Unless there is another standard track RFC that requires validating resolvers to clear CD, it seems best for interoperability to send packets with CD=1. I just checked unbound and it seems to send packets with CD=1.
There isn't any way for a DNS64 resolver to require others to do anything to CD, which is part of the problem. DNS64 has pretty clearly bad interactions with DNSSEC, as is outlined pretty extensively I think in RFC 6147 section 3. Mark's position was always clear, which was that everyting needed to be done twice. As a practical matter, nobody was willing to do that, so his approach failed to garner consensus. There are, as a result, definitely cases where DNSSEC won't work. If your connectivity is via NAT64, my opinion was in 2010 and remains today that DNSSEC just won't work reliably on your node and you have to give it up. You basically have two choices: do DNSSEC validation on your endpoint and probably fail some of the time, or find connectivity that doesn't depend on NAT64. Note that as far as I can tell 464XLAT doesn't need DNS64, and I would urge people not to use DNS64 unless it's absolutely necessary.
I agree with you that DNS64 is bad. But currently it is a standard track RFC, and the DNS64 behavior can be disabled by setting CD and DO. So it is hard to say that it gets in the way of DNSSEC validation.
Yes, if you know how to generate the correct Pref64::/n, you can mark the data valid, then synthesize your own answers and hand those to the application, thereby reproducing the function in question. Best regards, A (speaking only for myself) -- Andrew Sullivan [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
