This is an update of my previous messages. The generic DNS confidentiality problem can be divided into 3 cases:
1- stubs <-> local resolver 2- stubs <-> remote open resolver 3- resolver <-> auth. servers In the first case the local resolver is in the same security area (I use "area" to avoid to overload "domain" or "zone") than clients/ stubs (and the infrastructure between them two). This covers the case where the resolver is physically local and the one where a mobile client is securely connected to the local network, so the usual perimeter/VPN/etc including nomadic VPNs. As DNS is in the 1- case only one of the services to protect I consider without a strong argument for the opposite the security will be provided by a general (vs. a DNS one) mechanism so doesn't need a DNSE solution. BTW usually in the 1- case the resolver is dual headed so authentication and authorization are already required/provided. 2- is about a very low number of remote open resolvers so again without an explicit request I suggest we consider it is a private issue between the open resolver service and its customers. Note the environment is very different than 3- so even it has to be addressed 2- should lead to a different solution too. So we have to address 3-, and to begin by qname minimization (which is also minimal on many aspects :-). Regards francis.dup...@fdupont.fr _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
