> -----Original Message----- > From: Stephane Bortzmeyer <[email protected]> > Sent: Wednesday, November 27, 2019 7:59 PM > To: Konda, Tirumaleswar Reddy <[email protected]> > Cc: Stephane Bortzmeyer <[email protected]>; Phillip Hallam-Baker > <[email protected]>; [email protected] > 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 Wed, Nov 27, 2019 at 09:07:15AM +0000, Konda, Tirumaleswar Reddy > <[email protected]> wrote a message of 72 lines > which said: > > > > *All* "automatic discovery of the DoH resolver" schemes are broken > > > by design and I really wonder why people keep suggesting them. > > > > Not all discovery mechanisms have security holes, you may want to look > > into > > https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-05. > > It seems to me that this draft has exactly the same problem as every other > "resolver discovery" proposal: it gives complete power to the access network > to indicate the resolver to use.
No, the client makes a decision whether to use the local resolver or not, please see https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-01#section-2 I will update the draft in the next revision to make it more clear. > If you use DoH/DoT, it is because you don't > trust the access network. Relying on it to indicate a DoH/DoT resolver is > pointless. Agreed, the bootstrapping procedure is not implicitly triggered. You may want to look into https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-05#section-11. It is similar to way VPN is enabled implicitly in all networks and the user has to explicitly disable VPN connection in specific network (e.g., Home network with security service to filter malware). Cheers, -Tiru > > For instance, if your access provider has a lying resolver and you want to > escape it with DoH/DoT access to an external resolver, I don't see how this > draft helps you. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
