Hi Daniel On Thu, Dec 13, 2018 at 02:32:41PM -0500, Daniel Kahn Gillmor wrote: > The degenerate scenario i'd painted on the call was: > > * consider a DPRIVE-capable DNS resolver; for whatever reason, only a > single request has been made to it since it booted. > > * a new cleartext (non-private) request comes in for foo.example, and > it does the lookups it needs to do, all in the clear. (private > queries to authoritatives would have worked, but they weren't tried > since the initial request was in the clear anyway). > > * a subsequent private request comes in to the resolver, and the > resolver responds without doing any upstream lookup. > > in this scenario, a passive observer of the resolver's traffic can infer > that the private query was likely also for foo.example (or at least, for > one of the names that needed resolution in order to get an answer for > foo.example, like NS records).
Ah.. I follow it now, and why you think it is a leak. :) A resolver can respond to several queries without performing any upstream queries. As an example, take RFC 6761. Nothing can be inferred about a query simply because it didn't result in resolution. > > So this is a privacy leak, which could be mitigated by treating the > cache of RRs-accessed-in-the-clear as invalid for retrieval of the > private query unless private authoritative DNS is confirmed to be > unavailable. > > There might be other effective mitigation besides a split cache, > though. for example, preferring private queries upstream in the first > place for every query might offer some mitigation. > > what do you think? > > --dkg Mukund _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy