Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Andrew Sullivan <[e-mail]>]

Hi,

On Mon, Feb 07, 2022 at 10:37:28AM -0800, David Conrad wrote:
>
>Yes, IPv4 addresses (or what may look like IPv4 addresses) can exist in TXT records arbitrarily, however, IIRC, SPF TXT records are fairly tightly constrained to start with “v=spf1 …” and the content of interest here must be prefixed with “ipv4: “.  Given this, I’d imagine it’d be pretty straight forward for DNS64 to find the relevant IPv4 addresses to do whatever transforms are necessary, leaving other IPv4 addresses embedded in TXT RRs as Someone Else’s Problem (if encountered).
>

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.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]