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

Mark Andrews marka at isc.org
Sat Oct 31 04:44:27 UTC 2020


I actually think it is time that DNS64 should be formally declared historic.   It does not work with DNSSEC.  It is NOT needed for 464XLAT.  Configuring ipv4only.arpa zones on recursive servers provides the necessary mapping information to configure a CLAT.  Almost all cellular devices have CLAT or equivalent.  Similarly almost all dual stack CPE devices have CLAT.

I argue that there is no need to run DNS64.   The arguments for DNS64 are no longer valid. 
-- 
Mark Andrews

> On 31 Oct 2020, at 12:38, Mark Andrews <marka at isc.org> wrote:
> 
> 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 <philip.homburg at ripe.net> 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
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations





More information about the dns-operations mailing list