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

Dave Lawrence <> Wed, 15 November 2017 05:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5BE571271DF for <>; Tue, 14 Nov 2017 21:13:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6WwsLMhTeJPY for <>; Tue, 14 Nov 2017 21:13:31 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F326A127058 for <>; Tue, 14 Nov 2017 21:13:30 -0800 (PST)
Received: by (Postfix, from userid 102) id E39A03F442; Wed, 15 Nov 2017 00:13:29 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Wed, 15 Nov 2017 00:13:29 -0500
From: Dave Lawrence <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Nov 2017 05:13:33 -0000

Paul Vixie writes:
> i'm of the opposite view. we should not change behaviour without 
> explicit signaling. if that means it takes 10 years to reach 50% 
> penetration, like EDNS did, then that's the cost of doing business.

Just so I'm clear, am I understanding correctly from this that you
believe a recursive server should only fall back to stale data from
cache if the request explicitly included a staleness option?

I ask because Bob's comment that started this thread was exploring
being able to signal staleness back when OPT was included in the
request but the option being defined by the draft wasn't included.

To me this makes three different positions we're trying to reach
consensus about, for allowing fallback to stale either:

1) when the request explicitly signals it is ok;
2) when the request groks EDNS but might or might not understand
   a staleness option; or
3) in all cases.

My current understanding is that you and Paul are of position 1, while
I'm at 3.  At first glance 2 would appear to be pretty nearly the same
as 3 as far as its permissive toward unaware clients, but
significantly it does at least provide signal you could still access
via protocol debugging (dig, tcpdump, etc).