Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[marcelo bagnulo braun <[e-mail]>]

below...

El 6/2/22 a las 23:18, Keith Moore escribió:
> 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.)
>

My guess is that NAT was done wrong because the IETF decided against 
standardizing NATS in due time because it was a kludge that should not 
be done, maybe?

NATs are reality (I hope we all agree with that). I guess it is more 
productive to try to provide guidance about how to make them as harmfull 
as possible rather that ignore them, provide no guidance and end up with 
all possible version of NATs, including the worst possible ones.

Regards, marcelo

> 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