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
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
