> On 2 Nov 2020, at 03:55, Andrew Sullivan <[email protected]> wrote:
>
> 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.
More correctly it was you need to retry on error with CD set to the other state.
> 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.
DNS64 also required every validating device to know about DNS64.
464XLAT needs the device to learn the PREF64 mappings. There are several
ways to do this 1) ipv4only.arpa AAAA responses to return mapped address
(DNS64 or serving ipv4only.arpa with the requisite records), 2)
RFC 8781 Discovering PREF64 in Router Advertisements.
>> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
