Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Keith Moore <[e-mail]>]

On 2/7/22 13:37, 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).

No, that just makes the problem worse.  At present, the responsibility 
to deal with SPF records when operating behind a NAT is clearly with the 
consumer of the SPF records.   If the DNS64 engine is allowed to try to 
address that problem instead, then the location of that responsibility 
becomes unclear, and it's likely to change and break things without 
anybody noticing. Consistent behavior is Good; trying to constantly 
change how the network works to solve problems that are unfixable is 
Bad.  It adds complexity with no hope of ever reducing it.

Especially when, in practice, SPF records are likely to be wrong and to 
result in failure of legitimate mail to be delivered, without any 
indication to anyone who can fix it.   So trying to fix the SPF+NAT 
problem is doubly counterproductive.

Want to fix the NAT instead?  Arrange for there to ALWAYS be some 
signaling available to every app behind the NAT as to what the address 
binding is.   Don't make the app try to second-guess the NAT and don't 
have the NAT try to second-guess the app.   That way lies madness, as 
we've seen for 25+ years.

Keith