Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

The DNS64 server could be this secure DNS. Also for providers (esp. 
cloud providers) that want to deploy provider level NAT64 support and 
provide a DNS64 server to allow customers to build ipv6 only networks 
(with additional IPv4aaS) would also benefit from this. Also the noted 
"smtp server and DNS may not be under the same management" is also one 
of the reasons why it should be within DNS64. It is fair to assume that 
when providing a DNS64 service that all parties would assume full 
rewrite of the DNS to support the NAT64. But with SPF being the only 
standard that writes IPv4 addresses into the DNS that is currently *NOT* 
rewritten and by the RFC also stating that "*All other RRs MUST be 
returned unchanged*" it also prevents anyone that want to follow the RFC 
from rewriting the SPF themselves.

On 2022-02-07 03:30, Christian Huitema wrote:
> On 2/6/2022 6:20 PM, Klaus Frank wrote:
>
>> 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... 
>
> Yes, but doing that requires updating the code on the DNS64 server, 
> which may or may not be under the same management as the SMTP server. 
> The DNS64 update would  also will still break if the SMTP server is 
> configured to access a secure DNS server using encrypted DNS -- DoH, 
> DoT or DoQ. Turns out that "use encrypted DNS" is one of the 
> recommendations pushed for network security, because it prevents DNS 
> spoofing and DNS monitoring attacks. Overall, it is probably easier 
> and more robust to deploy a change in the SMTP servers.
>
> -- Christian Huitema
>