Re: TTLs in QTYPE=* caching

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Thu, 27 Nov 2003 09:34:48 -0600
    From:        "Eric A. Hall" <ehall@ehsco.com>
    Message-ID:  <3FC61998.1020506@ehsco.com>

  | Easiest approach to making these queries cachable is to synchronize the
  | TTLs of all the RRs in the response, and set a flag somewhere that a
  | qtype=* query was made for the owner name. If there's any RRs for that
  | name in memory, then you've got all of the RRs.

Aside from all the extra mechanism you'd have to assume was existing
in the cache, before you could safely use this, this simply does not
work.

Assuming that all TTLs were already the same (the way people used to make 
master files, with the only TTL setting being the copy out of the SOA.minimum
field), so the cache doesn't have to force it, this still doesn't work.

Let that common TTL be 3600.   Do a query at time X, get all the RR's.
At time X+200 the auth servers all add a new RR to the name queried.
Now, at X+500, send a QTYPE=* query (RD=1) (again) to the cache for
the same name.   Is the new RR included in the reply or not?   If not,
does the answer include all the RR's, as has been demanded that it
include?   If it does, how does it get there?

This problem doesn't exist for normal (single type) queries, as the
TTL is a promise (mostly ignored by admins, but that's not the
protocol's fault) that the data will returned will remain valid for
TTL seconds.   It isn't even a problem for negative answers, as those
include the SOA, and the SOA.minimum is supposed to indicate just how
long you can cache a non-existence report.

But here, we get neither - we have no TTL for the RR (RRset) of the
new RR, so nothing to rely upon.   We have no SOA so no information
on how long we can hand out "doesn't exist" information.

kre


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>