Re: [DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt

[Paul Vixie <[e-mail]>]

Paul Wouters wrote:
> On Mon, 5 Nov 2018, Bob Harold wrote:
>
>> On Mon, Nov 5, 2018 at 1:51 PM Paul Vixie <[e-mail]>
>> wrote: because of deliberate reconfiguration or takedown, i'll hope
>> that serve-stale offers authority operators (both apex and parent)
>> a signalling pattern that says, "actually, i want this dead, NOW."
>>
>>
>> Good point.  I think that would mean that if using all the NS
>> records in the cache fail to get a good response, then the resolver
>> should check the parent domain to see if the NS records have
>> changed or have been removed. (answers or NXDOMAIN being a good
>> response in this case, REFUSED or LAME or timeout being bad
>> responses)
>>
>> Would that work?   Should that be in the draft?

something like it should be, yes.

> Something along those lines should be added. But this particular
> approach might be too simple. What if the parent is also under DDOS
> attack? When can/should you look at the parent's parent (eg think
> Public Suffix boundaries)

eight years ago we said it like this:

> 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.

so what you'd do is revive this part of resimprove and then refer to it 
by saying "before considering the extended publication of stale data, 
first revalidate as in [RESIMPROVE], as if the delegating NS RRset TTL 
had expired".

(https://www.ietf.org/archive/id/draft-vixie-dnsext-resimprove-00.txt)

note that vernon schryver and i implemented this in a from-scratch rdns 
server called "robodns" in the early 2000's, and it worked really well.

-- 
P Vixie