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

Puneet Sood <> Mon, 25 March 2019 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85142120407 for <>; Mon, 25 Mar 2019 08:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.502
X-Spam-Status: No, score=-17.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kubf9zIlzaiO for <>; Mon, 25 Mar 2019 08:08:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC55D1203FF for <>; Mon, 25 Mar 2019 08:08:00 -0700 (PDT)
Received: by with SMTP id c4so7270290ywa.11 for <>; Mon, 25 Mar 2019 08:08:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1TCR74Rz60ZEpqX4ThTvwrEDpLQk0mnFf6aLVIqNyOs=; b=ASPgpbTUCsv1ev6/g/8qSs9Rp4n1brhWNdZpQKcfzFE9CxIzLCsTu8XJxxlNz0iO9S +Tu+AGSF8MjYSYeTX72iQGXQglOIETEtt49VSNS73FcxRbI9mu2bXCJpHcoAKGXrsbv3 bb+plPSRAKxK3XQdjW1JU6kVxk+6oO10f4i1Cfc7mP3gNr7m+HmHgNJqsw3sS77KUkhO 0lZErVffTguxtfnULPLM/OHoH9KLZS3TPpuRUa3oVLqPe7wyqUN0Z4A2mIGI+xyfqucm Otsq6/b36jtyfYOREqUmdSXvQ7/1nbo6WFJFa11i8oGW9WQUDQEnn/qm1hRd34F2dfhr /abg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1TCR74Rz60ZEpqX4ThTvwrEDpLQk0mnFf6aLVIqNyOs=; b=Gs1VI1ifVGfS0jZmZ7Ks3G84N/e37/DLA+cecHUxMBpzpPQyJniekSzEJHq/hLF7/A zhLEsG6x9ifcR5MhIz+jRSnEQZiwiKEEXOMA1MMmgFrqPNnMPoIs3WT6tAfsSNssNxxo AQJam4+T2SfGLBTJp/pmAkF8c7jh3otf2TWvaF53QVehITohyKXMFS2p0FnGiYAXCTXE I6GZ7KWmNddcfmNR2RQvBOqciumtJMOUBZuzVyRuSCXrQtfG2AdbtYGWxqjlxeRwuXgk G4YyG2/vBdfOM7aSj1L77pCqn5LvTqQYNb0kuVqb1X3w5/DvWs7MORgnQpfluxwN4C36 rRAw==
X-Gm-Message-State: APjAAAVi+rxb5zC+sBZpeOEaYTwZLyzFTi0iGEOqnXwULGUfmyOsIOq2 8/2z7z9lTn3i4M8seG/w6gH8Z5oostaf7i0cfzTDOA==
X-Google-Smtp-Source: APXvYqwKUxpDMOANSEsqIsN9t2pQNeHwuVXf3tA1jDde2ig4vlT3CxUfikWMBMhUQL45RIiHytQwevpckzqvRbLh2bw=
X-Received: by 2002:a81:2807:: with SMTP id o7mr21082344ywo.300.1553526479589; Mon, 25 Mar 2019 08:07:59 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Puneet Sood <>
Date: Mon, 25 Mar 2019 16:07:48 +0100
Message-ID: <>
To: Paul Vixie <>
Cc: Benno Overeinder <>, IETF DNSOP WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Mar 2019 15:08:08 -0000

Hi Paul,

On Sun, Mar 24, 2019 at 12:37 PM Paul Vixie <> 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
>, 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. 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