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

神明達哉 <> Fri, 17 November 2017 18:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0CE8126BF6 for <>; Fri, 17 Nov 2017 10:46:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KjJJnCJXSKHC for <>; Fri, 17 Nov 2017 10:46:36 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE08E124C27 for <>; Fri, 17 Nov 2017 10:46:35 -0800 (PST)
Received: by with SMTP id p96so2890991wrb.7 for <>; Fri, 17 Nov 2017 10:46:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Bzngmfd50x1gGcLrS4v22jNvWPEeX6tu9gnxczvUiTE=; b=feszZD25kYexUsOWForqyvlPze8PPlRlULh5iFhFP/5CPc7aH97xU5CyzWrfG/hN1j PVD1O9CUDQqgWVFsLRMToIDew6M7EPy9vPm1u6bDzBfBIp/GWvnO4oC2sf0yPDH1uPVv KHwbJi2+ykXr5jSl9ZtlW6+yjJOmUxpj7bEC5Q/PZAtBHD8BTeoJgMScYy6evSq9/toR tuSUFeVqqfnU9pHbp7j6n3nYkc61cHarpP+21JAgK10q8evD7EpYJxRPYpHURYD4bhrg hlFGvaYhX28TWyhFhWKxlD7u/6AFXYdUZJiUvGhCQe3mNIgfa+VoSNbiibSkrtuDlzto WbiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Bzngmfd50x1gGcLrS4v22jNvWPEeX6tu9gnxczvUiTE=; b=ZboPX9oGVkFJ9hWn4oUuKK6cuKoM5h03G4zr50UvLRPLLJwDqaVYiwJqx+kAVz446o IsZNU0XVjQPlOrZaslV2XMc8KNGAYCjvrNd6UwgrHhZsf9fjH5hnVlrA80836AieZ3pX SHvAQ/AUupNoEVkO5lL4q9zGbtgAgbh9KszxEmMQiVq2GSHAL4iS7Jay4bTLKxrsgIec fvxhGLIhsOgu2Mi/XvG0oRbIJtyMtofkDUYF+nPSRicSlydsvEeug5vwKOqZQwWUn++X aXbhCbMQHc2vICf+hhFV13q3ZlODjuNLilFEEtgMlXO8Aun/odf1ZkFNpufWQtXqZ+iA Ef2Q==
X-Gm-Message-State: AJaThX6OJQmCluVMQo51LsoQ65nljkn6spBloHzSIxPlAtfA/QtJccMM YbsaDhDbgJswIFVE2D12qgdj6nml/TKb9fEyB3OyHPHO
X-Google-Smtp-Source: AGs4zMa5ggil+lsvW1pyF4iaLl3DYAn40VaDfyupyEkqBWRk4pVWuwCByrXIJPao7LRtTrP3bPA3KKSDpXJCuJc958o=
X-Received: by with SMTP id g95mr4991137wrd.53.1510944393893; Fri, 17 Nov 2017 10:46:33 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 17 Nov 2017 10:46:33 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: 神明達哉 <>
Date: Fri, 17 Nov 2017 10:46:33 -0800
X-Google-Sender-Auth: URZMH_eiMGS-NT5GDDruTMQVUp0
Message-ID: <>
To: Paul Vixie <>
Cc: IETF DNSOP WG <>, Dave Lawrence <>
Content-Type: text/plain; charset="UTF-8"
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 18:46:38 -0000

At Thu, 16 Nov 2017 22:02:33 -0800,
Paul Vixie <> wrote:

> > Realistically, I expect virtually everyone will implement 3, given how
> > this kind of feature is sold in the marketing context.  ,,,
> me too. that's why, in:

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

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?

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

JINMEI, Tatuya