i object to serve-stale as proposed. my objection is fundamental and
goes to the semantics. no editorial change would resolve the problem.
i would withdraw that objection if this draft incorporates section 2 of
https://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00, to wit:
2. Delegation Revalidation Upon NS RRSet Expiry
2.1. Because the delegating NS RRset at the bottom of the parent zone
and the apex NS RRset in the child zone are unsynchronized, the TTL
of the parent's delegating NS RRset is meaningless. A child zone's
apex NS RRset is authoritative and thus has a higher cache
credibility than the parent's delegating NS RRset, so, the NS RRset
"below the cut" immediately replaces the parent's delegating NS RRset
in cache when an iterative caching DNS resolver crosses a zone cut.
2.2. The lowest TTL found in a parent zone's delegating NS RRset
should be stored in the cache and used to trigger delegation
revalidation as follows. Whenever a cached RRset is being considered
for use in a response, the cache should be walked upward toward the
root, looking for expired delegations. At the first expired
delegation encountered while walking upward toward the root,
revalidation should be triggered, putting the processing of dependent
queries on hold until validation is complete.
2.3. To revalidate a delegation, the iterative caching DNS resolver
will forward the query that triggered revalidation to the nameservers
at the closest enclosing zone cut above the revalidation point. While
searching for these nameservers, additional revalidations may occur,
perhaps placing an entire chain of dependent queries on hold,
unwinding in downward order as revalidations closer to the root must
be complete before revalidations further from the root can begin.
2.4. If a delegation can be revalidated at the same node, then the
old apex NS RRset should be deleted from cache and then the new
delegating NS RRset should be stored in cache. The minimum TTL from
the new delegating NS RRset should also be stored in cache to
facilitate future revalidations. This order of operations ensures
that the RRset credibility rules do not prevent the new delegating NS
RRset from entering the cache. It is expected that the child's apex
NS RRset will rapidly replace the parent's delegating NS RRset as
soon as iteration restarts after the revalidation event.
2.5. If the new delegating NS RRset cannot be found (RCODE=NXDOMAIN)
or if there is a new zone cut at some different level of the
hierarchy (insertion or deletion of a delegation point above the
revalidation point) or if the new RRset shares no nameserver names in
common with the old one (indicating some kind of redelegation, which
is rare) then the cache should be purged of all names and RRsets at
or below the revalidation point. This facilitates redelegation or
revocation of a zone by a parent zone administrator, and also
conserves cache storage by deleting unreachable data.
2.6. To make the timing of a revalidation event unpredictable from
the point of view of a potential cache-spoof attacker, the parent's
delegating NS RRset TTL should be reduced by a random fraction of its
value before being stored for use in revalidation activities.
in other words, we'd be negotiating for the right to re-interpret
existing signaling (the authority's TTL no longer purely governs the
data's lifetime) by insisting that the parent zone's delegating TTL be
given absolute power for revocation.
vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
