Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

On 2022-02-10 16:35, Christian Huitema wrote:
>
> 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.
And how would you push that change down the line via e.g. DHCP, mDNS or 
similar? That's what you can do with DNS64 servers but not with "NAT64 
wareness in code"
>
> -- Christian Huitema
>
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave