Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Paul Vixie <[e-mail]>]

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