[dns-operations] which breakage is this? FreeBSD.org / systemd-resolved

[Mark Andrews]

> On 2 Nov 2020, at 03:55, Andrew Sullivan <ajs at anvilwalrusden.com> 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
> ajs at anvilwalrusden.com
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> 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: marka at isc.org