Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

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

El 7/2/22 a las 1:38, Klaus Frank escribió:
> 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.
>

I guess one operative question is whether this issue can be dealt with 
an errata or should require an update in the spec.

Regards, marcelo



> 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
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave