Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

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

El 7/2/22 a las 3:48, Klaus Frank escribió:
> The DNS64 server could be this secure DNS.

This would consistent with the deployment scenario presented in section 
7.1 of RFC6147.

Regards, marcelo





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