Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

You left out the other half of Section 6.2 where it says:

    Alternatively,
    the validating host may establish a trusted connection with a DNS64,
    and allow the DNS64 recursive resolver to do all validation on its
    behalf.

Which is allowing the DNS64 server to rewrite the SPF record...

On 2022-02-07 03:13, Christian Huitema wrote:
>
> On 2/6/2022 5:52 PM, Keith Moore wrote:
>> On 2/6/22 19:58, Dan Wing wrote:
>>
>>> A problem with rewriting SPF records within DNS64 is that other IPv4 
>>> addresses may well appear in TXT records, throwing a loop to 
>>> applications which won't know if the DNS64 has done rewriting or if 
>>> the application needs to do rewriting.  A long-standing problem with 
>>> NAT "support" for applications since the days of FTP PASV.
>>
>> +1
>>
>> In general the problem with NATs is that they try to hide what 
>> they're doing from applications.   But they are never completely 
>> successful at that, and they cannot be.    And it's often difficult 
>> for the application to work-around the damage caused by the NAT.  In 
>> hindsight, it would have been far better for NATs to always be 
>> explicitly visible to applications; then at least the applications 
>> and NATs wouldn't be trying to second-guess one another.
>>
>> But that's water under the bridge.   At this point the best thing 
>> that can be done is to transition to IPv6 only (except for some 
>> legacy hardware on local networks), and eradicate NATs as soon as 
>> possible.
>
>
> DNS64 is a kludge. It looked like a good idea at the time, but there 
> are many corner cases. For example, it is well known to not be 
> compatible with specifications like DNSSEC. DNS64 also breaks 
> completely is the local host uses an encrypted DNS connection (e.g. 
> DoH) to a secure DNS resolver. Klaus raises yet another issue: the 
> local SMTP server will see incoming connections from an IPv6 address 
> that bears no relation to what is in the SPF record of the remote 
> source. This is pretty much the same problem as DNSSEC, and the 
> solution is pretty much what is defined in Section 6.2. of RFC 6147: 
> "the validator must know how to perform the DNS64 function itself". 
> That means the SMTP server should:
>
> 1) Know the local NAT64 prefix
>
> 2) Recognize that the incoming connection is from the local NAT64 prefix,
>
> 3) Perform the reverse translation to retrieve the original IPv4 address,
>
> 4) Acquire the original version of the SPF record, either through the 
> DNS64 server or through a secure server,
>
> 5) Check that the original IPv4 address matches.
>
> Of course, doing that require special code in the SMTP server to 
> handle NAT64. But that's pretty much the only solution.
>
> -- Christian Huitema
>