Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Keith Moore <[e-mail]>]

On 2/6/22 13:09, Klaus Frank wrote:

> Hi,
>
> we had some issues with SPF and a mail server that was behind 
> NAT64+DNS64. I at first thought that it was just a misconfiguration. 
> But after the DNS64 server seamed to work as intended I went to the 
> implementation and the RFC. Thereby while reading RFC6147 I stumbled 
> across section 5.3.3 which says "All other RRs MUST be returned 
> unchanged." which is the cause of my issues. This section is basically 
> ignoring SPF records (RFC7208 section 5.6) and also preventing DNS64 
> implementations from addressing this limitation.
>
> Would it be possible to create an extension to RFC6147 that mandates 
> SPF record rewrites as well? Otherwise Mail servers behind NAT64+DNS64 
> in IPv6 only environments won't be able to work as expected.
>
> Like:
> If the DNS64 server receives a SPF-record (within either the TXT-RR or 
> the SPF-RR [RFC4408]) containing the "ip4" mechanism it MUST rewrites 
> the ipv4 address according to the same rules as A-records are and 
> synthesizes a new SPF record within the response that contains 
> additional "ip6" entries. The original "ip4" should not be removed 
> from the response.

PLEASE do not try to make DNS reflect any more NAT alterations to 
reality.  That was ALWAYS a Bad Idea.   If you're going to operate 
application servers behind any kind of NAT, what you need to do is 
arrange for those application servers to somehow get a view of the 
external/global addresses that they're communicating with, even if the 
source IP addresses that they see aren't the real ones.  (If NATs had 
been done "right" there would be an API for this, supported by all 
NATs.   But that ship sailed decades ago.)

More generally, NAT is inherently unfixable, and trying to fix it can 
only result in infinitely growing complexity and brokenness. It's the 
usual problem with telling lies: every lie you tell needs N additional 
lies to cover up the earlier lies and so on recursively.

(also, relying on SPF records is ill-advised, as they're too likely to 
be out-of-sync with reality even without NATs in the picture. )

Keith