I am concerned that the "lazy" method would leak more than we think. We are thinking of a "cold cache" as a one-time event, but I think it happens more than we realize. Cache entries will regularly time out and we then leak data to refill the cache. This leaked data, sent at regular intervals, reveals a sampling of our data that is probably sufficient over time to discover a large percentage of what would be found with all the data. Thus there is little privacy gain. I would say we only promote the "aggressive" strategy.
The "aggressive" strategy will need to deal with broken name servers (those that do not return proper NS records). If an NS query fails or returns NXDOMAIN, it should probably be followed by a query for the original query type (likely A or AAAA), and then if needed by a query for more (or all) of the original query name. As long as the extra packets are only for "broken" name server, perhaps slower response is acceptable, or gives them some reason to fix their servers. I would remove the sentence about "legal responsibility". -- Bob Harold hostmaster, UMnet, ITcom Information and Technology Services (ITS) [email protected] 734-647-6524 desk On Wed, Mar 4, 2015 at 8:02 AM, Stephane Bortzmeyer <[email protected]> wrote: > On Sat, Feb 28, 2015 at 05:46:46PM +0100, > Stephane Bortzmeyer <[email protected]> wrote > a message of 18 lines which said: > > > I do not ask immediately a slot for > > draft-ietf-dnsop-qname-minimisation > > Well, I changed my mind, I would like a slot to discuss two issues: > > * it has been said > < > http://blogs.verisigninc.com/blog/entry/minimum_disclosure_what_information_does > > > that qname minimisation minimises the amount of data sent. That's of > course the goal. Privacy, like every security feature, is always a > compromise. The negative consequences are today presented at the > beginning of section 3 of the draft. Is this mention sufficient or > should we add something? > > * two algorithms are sketched in the current draft but only the > aggressive one is really detailed. The lazy one seems > under-specified. Should we keep two algorithms (plus other possible > optimisations like treating the root and the TLDs in a special way) or > should we simplify? > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
