Re: [dnsext] bitmap inference was Re: ... - NXDOMAIN for emptynon-terminals

[Brian Dickson <[e-mail]>]

On Wed, Mar 30, 2011 at 8:10 AM, Edward Lewis <[e-mail]> wrote:
> It's going to happen.  Even if we throw out the "tailored responses" issue,
> there's the element of time.  Although the DNS protocol does not integrate
> time into the data model, there's the real world that does.  Zones get
> updated and reloaded, so a cache will have to deal with inconsistent NSEC/3
> bitmaps.

It might be worth discussing how caches could/should handle NSEC/3
responses when time and/or bitmaps change.

The idea is, to find a happy balance between caching NSEC/3 responses,
associating those with bitmap bits, and limiting cache bloat.

When a cache has no entry for a given tuple (name, class, type),
obviously it has to then query the auth server. If it gets an answer
where the name exists but type doesn't, it should get an NSEC/3 record
as well.

The cache should only return that cached NSEC/3 when it sees queries
that match already-answered (by the auth server) queries, and new
types should result in new queries to the auth server.

The questions that arise are:
- What if the same NSEC/3 answer is returned for the new type?
- What if a different NSEC/3 answer is returned, but which is
consistent with previous NSEC/3 answer(s) already cached for other
types?
- What if a different NSEC/3 answer is returned, but which is not
consistent with previous NSEC/3 answer(s) already cached for other
type(s)?

My suspicion is that:
- It would be reasonable to keep a bitmap of queries/answers for which
a given NSEC/3 has been returned. E.g. If the NSEC/3 has bits clear
on, for example, SOA and NS, and has been returned along with empty
data on queries for SOA and NS for a given name and class, then it
would be reasonable to associate the same NSEC/3 with those types, and
return it for subsequent queries for those tuples.
- It would be reasonable to replace older NSEC/3 answers with newer
NSEC/3 answers, if the type associations (of previous queries/answers
that generated the cached entry) and bitmap of the newer NSEC/3 were
consistent (and thus also implicitly consistent with the bitmap of the
older NSEC/3)
- It would be necessary to retain multiple NSEC/3 answers if there
were inconsistencies between types and bitmaps across those answers

The benefit is, even if the time changes, if the bitmap doesn't
change, or doesn't change in a manner that is inconsistent, that the
number of NSEC/3 records doesn't have to increase, even if additional
queries to the auth server are needed because the particular type's
NSEC/3 hasn't been cached (or associated with the cached entry yet).

A secondary benefit is that a rolling window of TTLs resulting in
refreshing of NSEC/3's rather than expiry of NSEC/3's, can have some
beneficial effect on the auth server(s) without introducing
inconsistencies. A newer NSEC/3 (with newer signature) essentially
restarts the TTL clock when it replaces the older NSEC/3.

Or, the cache could decide to re-query candidate NSEC/3 records for
the types with the older NSEC/3 entries, and only if the new NSEC/3 is
returned, do the replacement. It is a time/space/bandwidth trade-off.

Brian