Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

Hi,

I can understand you. I also don't like NAT. And I would also have 
favored different migration paths from IPv4 to IPv6. But NAT64+DNS64 is 
the one we got. I'm sure there have been discussions earlier. I didn't 
want to resume or repeat those discussions. I'm certain there are valid 
reasons for why we have the current migration paths and that the pros 
and cons of different strategies have been covered adequately.

Nonetheless DNS64 is incomplete without also addressing the SPF record.

On 2022-02-06 23:18, Keith Moore wrote:
> 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
>
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave