Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Christian Huitema <[e-mail]>]

On 2/9/2022 11:38 PM, marcelo bagnulo braun wrote:
> El 10/2/22 a las 8:27, Christian Huitema escribió:
>>
>> On 2/9/2022 11:07 PM, marcelo bagnulo braun wrote:
>>
>>> El 7/2/22 a las 19:03, Christian Huitema escribió:
>>>>
>>>>
>>>> On 2/6/2022 10:34 PM, marcelo bagnulo braun wrote:
>>>>> 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. 
>>>>
>>>>
>>>> Maybe. But the situation has changed since April 2011. ISPs cannot 
>>>> any more assume that all hosts will be using the resolver embedded 
>>>> in the NAT64 gateway -- some hosts, or some applications, may very 
>>>> well use some alternate encrypted DNS service, e.g., using DoH and 
>>>> connect to Quad9, Cloudflare or Google. The cases describe in 
>>>> section 6 of RFC6147 are going to be more and more frequent. We 
>>>> should make them work, and we should tell application developers 
>>>> about that.
>>>>
>>> DNS64 doesnt have to be collocated withthe NAT64 box.
>>>
>>> The scenario 7.1 still holds in case the user is using an external 
>>> reoslver, such as cloudflare. The thing is that the external 
>>> resolver must then implement the DNS64.
>>
>> How does the external resolver know when it should implement DNS64 
>> and when it shouldn't?
>>
>
> I would assume that the external resolver provider makes public which 
> resolver instances implement DNS64 and which do not and the clients 
> select accordingly?
>
> I guess another alternative would be for the resolver to do dns64 for 
> cusotmers connecting through IPv6 and obtain replies that return only 
> A RR, but this sounds like a bad idea to me....

I agree that having the cloud server try to guess whether the client 
needs DNS64 or not is a recipe for trouble. This means the client will 
have to connect to something like "dns64.example.net" instead of the 
regular "dns.example.net". But then, that requires the client to 
actively change the DNS resolver parameters because it "knows" that it 
is behind a DNS64 gateway. And when we say client here, it may be some 
application, not just the DNS resolver in the operating system. Compared 
to that, changing the SPF code is rather simple: if the SPF code 
complain that the source IP is not in the authorized MTA address list, 
check whether the offending address starts with WKP, and if yes check 
whether the IPv4 address embedded behind the WKP prefix is in the 
authorized list.

-- Christian Huitema