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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Brian,

Yes, the client needs to discover the privacy policy information of both the forwarder and recursive resolvers, and if the DNS messages are encrypted between the forwarder and recursive resolver. Further, the forwarding DNS server can be configured with both primary and secondary resolvers as a backup mechanism to handle primary server failure.

You may want to look into privacy information claim discussed in https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-01#section-6.2.2. It includes the upstream servers privacy claims and if DoT or DoH is used to encrypt the DNS messages exchanged between the local DNS server and recursive resolver.

Cheers,
-Tiru
From: dns-privacy <[e-mail]> On Behalf Of Brian Dickson
Sent: Tuesday, November 26, 2019 11:21 PM
To: Phillip Hallam-Baker <[e-mail]>
Cc: [e-mail]
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 Tue, Nov 26, 2019 at 9:35 AM Phillip Hallam-Baker <[e-mail]<mailto:[e-mail]>> wrote:
This notion of DNS resolver discovery seems very strange to me.

The larger issue (and the one I am interested in finding solutions for) is that what is configured as a 'resolver', might actually be a 'forwarder'.

I.e. the path is generalized as client -> forwarder* -> resolver (zero or more forwarders).

Any DNS client, and any DNS server, when communicating, are unable to distinguish whether the other is (respectively) a resolver or forwarder, or a client or forwarder.

For the DPRIVE use case, it is hopefully clear that the path from the client to the (ultimate) resolver, needs to be encrypted in order to achieve privacy.

However, if the only place the client is able to establish an encrypted path to is a forwarder, this leave open the possibility that the forwarder->(forwarder->[...])->resolver might involve one or more unencrypted connections.

Depending on the network(s) and presence of NAT(s), it may or may not be possible for the client to communicate directly with the (ultimate, actual) resolver.

It is also a potential issue in addressing this issue with any mechanism(s), that intermediate forwarders and the resolver itself, may not have FQDNs of any sort, may not have NSIDs configured, and may not have public (globally unique) IP addresses.

So, the 'discovery' can involve any or all of, some naming method (for things without FQDNs), path discovery, address discovery, and address scope conflict detection, with the preferred result of client->resolver direct connection with encrypted transport.

Brian