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

[Puneet Sood <[e-mail]>]

Hi Paul,

On Sun, Mar 24, 2019 at 12:37 PM Paul Vixie <[e-mail]> wrote:
>
> 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:

I went back and read the discussion on this draft and I could not find
consensus on adopting it at that time. I do not think adding it to the
serve-stale draft will make path for adoption for either the
serve-stale draft or these recommendations easier.

https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-04 section 5
(page 6, paragraph 2) talks about refreshing the delegation. Quote:

+ When no authorities are able to be reached during a resolution
+   attempt, the resolver SHOULD attempt to refresh the delegation and
+   restart the iterative lookup process with the remaining time on the
+   query resolution timer.  This resumption should be done only once
+   during one resolution effort.

Maybe there are fewer, specific bits from your draft which would be
appropriate in the serve-stale context? Would you be willing to
discuss those?

>
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop