On Tue, Nov 26, 2019 at 9:35 AM Phillip Hallam-Baker <[email protected]> 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
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
