Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Christian Huitema <[e-mail]>]

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