Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

> On 27 Nov 2019, at 14:09, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@mcafee.com> wrote:
>> 
>>> On 26 Nov 2019, at 17:35, Phillip Hallam-Baker <phill@hallambaker.com>
>> wrote:
>>> 
>>> So what I see is a requirement for DNS resolver configuration. We already
>> have rfc6763 to tell us how to get from a DNS label to an Internet service.
>> Albeit one that presupposes the existence of a resolution mechanism. I don't
>> see it being problematic to use the local DNS to do this resolution provided
>> that 1) we have the means to authenticate the connection and 2) we only
>> use this mechanism once, to perform initial configuration.
>>> 
>> 
>> How will the connection to the local resolver be authenticated? Also,
>> presumably this mandates the use of DNSSEC by the client?
> 
> The client can validate the server certificate signed by a CA, and it will work for Enterprise deployments. However, it will be challenging for the DNS forwarder co-located on the home router to get the certificate signed by CA today but may be possible in future with ACME https://tools.ietf.org/html/draft-ietf-acme-ip-08 and IPv6. 
> 

If the client is connecting to the local resolver in order to bootstrap finding a DoH server, which is what the above proposal says, then it’s talking DNS53 and there’s no authentication. Unless the resolver and client both support DoT, in which case the server is still being contacted via IP address. If the resolver is a forwarder on an RFC1918 IP address, like many/most home routers, then authentication is a non-starter (I don’t see how the above draft helps with that).

So authentication would work in non-enterprise scenarios, assuming both client and resolver/forwarder support DoT, and the resolver/forwarder is not using an RFC1918 address.

> -Tiru
> 
>> 
>> Neil
>> _______________________________________________
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
> 