Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-02.txt

Dave Lawrence <> Wed, 17 October 2018 17:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B972A130E19 for <>; Wed, 17 Oct 2018 10:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e6Tlr_l8ApHE for <>; Wed, 17 Oct 2018 10:45:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2361A130E02 for <>; Wed, 17 Oct 2018 10:45:45 -0700 (PDT)
Received: by (Postfix, from userid 102) id 68DEC491B7; Wed, 17 Oct 2018 13:45:44 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Wed, 17 Oct 2018 13:45:44 -0400
From: Dave Lawrence <>
In-Reply-To: <>
References: <>
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-02.txt
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: Wed, 17 Oct 2018 17:45:47 -0000 writes:
> A diff from the previous version is available at:

Here's a summary of the functional updates:

Puneet Sood @ Google added as co-author in the short-lived -01.

A second, simpler EDNS option for signaling is proposed for
discussion.  That makes:

  * Option 1: Capable of identifying exactly which RRSets are stale so
    that a stub can use that information to handle each exactly as

  * Option 2: Simplified to only indicate that stale data appears in
    the answer, but not where.

A discussion note for the updated TTL definition, that "capping values
with the high order bit as being max positive, rather than 0, is a
change from [RFC2181]. Also, we could use this opportunity to
recommend a much more sane maximum value like 604800 seconds, which is
one week, instead of the literal maximum of 68 years."

Raised the suggested response TTL on stale records to 30 seconds, from
1 second.  That's in the message from the recursive to its client.

Recommended that refresh attempts from the recursive to the
authorities happen no more frequently than every 30 seconds.

One thing I've realized isn't mentioned in the draft but maybe should
be is that even in the absence of an EDNS option stale data can also
be disabled by the client request if it asks without the recurse flag
on (dig +norec).  Since serve-stale as proposed relies on recursion
failing, if there was no attempted recursion that could have failed
there will be no revisiting the cache to find stale answers.