Subject: Re: [DNSOP] another way to minimize ANY responses

From: Brian Dickson <[email-masked]>
Date: Thu, 26 Mar 2015 17:37:37 -0700

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