Paul Vixie wrote: > Ted Lemon wrote: > > On Mar 26, 2015, at 1:26 AM, Paul Vixie <paul at redbarn.org> wrote: > >> you make an excellent point. so, the spec might ask for repeatability, but > >> not specify how that's to be achieved. it's still an information leak > >> since the preferred type may have timed out of the cache, in which case an > >> rdns would have to return the next thing on its priority list. (refetching > >> should NOT be done!) > > > > I don't think you need a priority list--any deterministic mechanism will > > do. I'd suggest using the numerical RRtype code, and choosing the highest > > number. This will not always return the smallest RR, but it has the > > virtue of preferring AAAA to A, but quite possibly sending neither (which I > > think is even better). > priority list is an example of determinative. so is sorting by numeric > rr type value. but in either case, as those rrsets expire, others will > be exposed -- an information leak. or if a certain type is preferred, > then when that rrset expires, re-fetching will occur -- another > information leak. > what we should say in the spec is "determinative, and > non-information-leaking", and let implementers scratch their heads about how > to do that. we should not try to invent it here, or specify it in an ietf > document.
I think there is still value in providing ideas to implementors, e.g. in an Appendix. And, to that end, I have the following suggested algorithm. It may or may not work, but has the potential to reduce leakage. It involves two parts, that mesh nicely. The first is: explicitly cache "ANY" answers (per the second item's rules). The second is: populate the "ANY" cache entry _at query time_, with "whatever will expire latest". Even if subsequent RRs show up at the name, and would expire after the _current_ "ANY" entry, they don't displace it. And if no subsequent RRs arrive, after the "ANY" expires, there will be no answers present, "ANY" or otherwise. This way, until the "ANY" cache entry expires and is evicted, the _same_ answer will be given. (Picking the last one at query time is an optimization, and roughly corresponds to the Unix "copy on write" method of handling memory pages during a "fork()".) Once the "ANY" cache is empty, the next "ANY" query causes it to re-populate appropriately. (I'm not sure, but I think this may be an unbeatable info-leakage solution.) BTW - I also like the NSEC/NSEC3 suggestion. Maybe handle it similar to the DNAME/CNAME-synthesis mechanism? Return the NSEC or NSEC3, and its RRSIG, plus the "ANY" cached RR (and RRSIG). If the answer set gets sent to an original querier who did DO=0, they get the contents of the "ANY" cache. If the answer set goes to a recursive caching resolver with DO=1, they also get the NSEC/NSEC3, and can use that to optimize subsequent queries if they like. $0.02, Brian _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
