Because for DNSSEC to actually work though a forwarder you need to send both CD=0 and CD=1 queries.
Always send CD=1 is broken. I said it at the time. This is noted in the write up on the draft. The working group chairs failed in letting this go through. Logic showing the decision was broken should have trumped misguided wishes to not have intermediate resolvers perform validation. It was never to late to revisit a wrong decision. DNS64 also requires the validator to discover the DNS64 parameter for which there isn’t a reliable well developer solution. And after discovering them enabling there own DNS64 algorithm. I blame the IESG for letting this past. This result was predicted when DNS64 was a I-D. -- Mark Andrews > On 31 Oct 2020, at 05:48, Philip Homburg <[email protected]> wrote: > > On 2020/10/30 18:38 , Phil Pennock wrote: >> On a laptop, you discover when roaming that suddenly you're on a network >> where the only DNS upstreams are doing 464XLAT and all DNSSEC >> verification breaks, so you need to be able to handle that _sometimes_ >> DNSSEC is just not viable. > > I'm confused. Why does 464XLAT break DNSSEC? The idea is that a DNSSEC > validating resolver sets the CD bit (in addition to the DO bit). This > causes the DNS64 resolver to stop doing synthesis (RFC 6147, Section 5.5). > > This would normally cause NAT64 to fail. However, in the case of > 464XLAT, synthesis is not needed, so everything should be fine. > > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
