Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Keith Moore <[e-mail]>]

On 2/7/22 18:24, Andrew Sullivan wrote:
>
> I think I pointed this out on the other list, but there's a difference 
> in kind between the two cases.
>
> For A and PTR records, a DNS64 knows that it has work to do because 
> the datatype tells you so.  Part of the problem in SPF's case is that 
> it uses TXT, which can contain any arbitrary text. So, this means that 
> _at the very least_ the DNS64 needs to parse some part of the RDATA 
> before it can decide whether it needs to act.  It's a different model, 
> and there is no reason to suppose that the code path that relies on 
> strongly-typed data will work well for data that is effectively untyped.
>
> Moreover, I think it is really weird to suggest that DNS64 is going to 
> start picking and choosing when it's going to fiddle with the IP 
> literals in the RDATA it is dealing with.  If DNS64 is supposed to fix 
> up IPv4 literals in TXT records when SPF is working, it will be 
> entirely natural for people to generalize that to "DNS64 alters IPv4 
> literals in TXT records" rather than "DNS64 alters IPv4 literals in 
> TXT records where the RDATA starts "v-spf1…."  Then there will be a 
> new surprise when it works for SPF but not for some other case where 
> an IP literal is in a TXT record (which might not, of course, even be 
> aa standard).
>
> When we made DNS64, the DNSSEC handling depended on the idea that, if 
> you're planning to do validation yourself, you'd need to do DNS64 
> yourself too; and if you couldn't, it would break.  I think this is 
> sort of an analagous case: if you need to handle IP literals inside 
> DNS data that is not designed to carry such literals, then you're 
> going to need to be aware of how to handle such literals.  That argues 
> for making the SPF processor DNS64 aware for cases when it's going to 
> be used behind DNS64.  DNS64 was always kinda brittle; this is just 
> another example of it. 

+1