Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

I think an errata that either changes the "MUST not change" into a 
"SHOULD not change" is enough. As that would provide enough freedom to 
add a feature to update the SPF record without violating the RFC. And 
additionally add a note to that errata that explicitly lists SPF as one 
case where another record may need to be changed.

On 2022-02-07 07:41, marcelo bagnulo braun wrote:
> 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
>
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave