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

> -----Original Message-----
> From: dns-privacy <dns-privacy-bounces@ietf.org> On Behalf Of Neil Cook
> Sent: Wednesday, November 27, 2019 3:35 PM
> To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
> Cc: dns-privacy@ietf.org; Phillip Hallam-Baker <phill@hallambaker.com>
> Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
> 
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> > On 26 Nov 2019, at 18:04, Stephane Bortzmeyer <bortzmeyer@nic.fr>
> wrote:
> >
> >> Of these three models, I have always considered (1) to be a security
> >> hole.
> >
> > I fully agree. *All* "automatic discovery of the DoH resolver" schemes
> > are broken by design and I really wonder why people keep suggesting
> > them.
> 
> Resolver discovery schemes allow a client to ask the local resolver to provide
> information about the resolver, such as DoH info, as well as potentially other
> information about the resolver. I don’t see why they’re broken by design;
> yes they add no security properties on top of the (insecure) DHCP
> mechanism used to contact the resolver in the first place, but how clients use
> that information is up to them. They may or may not decide to trust that
> resolver, 

The problem with DHCP is the client has no way to know whether the DoT/DoH server is indeed hosted by the local network or by an attacker. For example, consider a network using Quad9/OpenDNS to perform malware filtering but attacker spoofs the DHCP response to convey the network is using CloudFlare DNS server. Chrome would establish DoH with CloudFlare, and the attack is successful. It is also easy for the attacker to get a domain name, and get the certificate signed by the CA (domain validate certificate).

-Tiru

> they may have a preconfigured list of trusted DoH servers, they
> may use it only to bootstrap connections to other servers, as suggested
> below. You may for example prefer your _doh.MYDOMAIN.example/SRV
> request to be sent over an encrypted connection.
> 
> Also without a discovery protocol, the only way to use an encrypted DNS
> connection would be to manually enter it , or use a pre-configured
> centralised DNS service using the Mozilla model. I’d much rather see all those
> existing non-encrypted connections moved to encrypted connections (using
> DoT or DoH) by default - it doesn’t preclude anything else you’ve suggested.
> It also doesn’t means that users who are depending on services provided by
> their local resolver (such as malware filtering, parental controls), would
> continue to be able to make use of them.
> 
> >> 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.
> >
> > I agree too. A simple _doh.MYDOMAIN.example/SRV request would
> suffice.
> > (Even better, HTTP should support SRV, but I digress...)
> 
> 
> Neil
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy