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

Paul Vixie <> Fri, 17 November 2017 23:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2561B120724 for <>; Fri, 17 Nov 2017 15:06:22 -0800 (PST)
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 Td30oFbpFDQv for <>; Fri, 17 Nov 2017 15:06:20 -0800 (PST)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F347B124217 for <>; Fri, 17 Nov 2017 15:06:19 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:cd10:acfb:3707:f2f1] (unknown [IPv6:2001:559:8000:c9:cd10:acfb:3707:f2f1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id B259061FA3; Fri, 17 Nov 2017 23:06:19 +0000 (UTC)
Message-ID: <>
Date: Fri, 17 Nov 2017 15:06:20 -0800
From: Paul Vixie <>
User-Agent: Postbox 5.0.20 (Windows/20171012)
MIME-Version: 1.0
To: 神明達哉 <>
CC: IETF DNSOP WG <>, Dave Lawrence <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Fri, 17 Nov 2017 23:06:22 -0000

神明達哉 wrote:
> At Thu, 16 Nov 2017 22:02:33 -0800,
> Paul Vixie<>  wrote:
>> ...i wrote:
>>> therefore a "serve stale" team within IETF-DNSOP was convened, to try to
>>> standardize the methods and signal patterns necessary to extend the
>>> usability lifetime of records when their authority servers are not
>>> reachable at the time of normal TTL-based expiry. most of us recognize
>>> that TTL's will continue to be stretched no matter what changes are or
>>> are not made to the specification, and so we expect the resulting RFC to
>>> document current practice _without recommending it_ and to also document
>>> a new practice _with recommendations_ as to its proper uses.
> This (including the entire message) looks reasonable to me, as long as
> we mean it, i.e., we actually seriously work on the "new practice" as
> a followup wg task, rather than just using it as an excuse to publish
> the current serve-stale draft.

later in [ibid], i wrote:

> this system would allow gradual insertion of the new state management
> logic on an opportunistic basis -- motivated authority and recursive
> server operators, which would include CDN operators who must perform
> both services perfectly -- would be early adopters, and like ECS before
> it, the "hot" part of the community would be upgraded years earlier than
> the last outlier.

i think that it's in the large RDNS operators' interests, and in the 
large authority operators' interests, and in CDN and proxy operators' 
interests, to deploy these new protocols -- and that once they see 
positive results, they will find it in their best interests to turn off 
the older pre-standard TTL stretching logic that should be described, 
but _not recommended_, in the TTL-stretch specification.

if i could not visualize a fully interest-aligned deployment path for 
the operators who most need TTL stretching, then i would agree with your 
concern that we might not "mean" it.

> But I'd note there might be some confusion here (perhaps only for me,
> though).  I've been having the impression that we are talking about
> "signalling" between the stub and caching (usually recursive) server,
> perhaps because it's a followup of this message:
> But your suggestion is signalling (mainly) between caching and
> authoritative servers, right?

yes. i don't think anything that requires end-system upgrades is going 
to answer the market need for TTL stretching. even "happy eyeballs" took 
five years to be adopted and another two years to stabilize.

> I thought recommending to allow fallback to stale
>>>> 1) when the request explicitly signals it is ok;
> between stub and caching wasn't realistic, as I didn't see a strong
> incentive for the developers and users of stub (except for
> protocol-savvy kinds).  That's why I was pessimistic in my previous
> message.  I see more reality if it's about signalling between caching
> and authoritative since, as you pointed out, there may also be
> incentive for authoritative operators to adopt the "new practice".

the TTL stretching specification should ideally introduce new stub 
signalling to turn off stretching, so that those of us using "dig" in 
diagnostic mode, can learn more about the TTL-state of the RRset in our 
local RDNS.

P Vixie