Re: [DNSOP] draft-tale-dnsop-serve-stale

Paul Vixie <> Tue, 28 March 2017 17:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C14C128854 for <>; Tue, 28 Mar 2017 10:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id REcp6HrLOeux for <>; Tue, 28 Mar 2017 10:20:45 -0700 (PDT)
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 9DF041296D1 for <>; Tue, 28 Mar 2017 10:20:41 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:50e4:c235:dee1:8442] (unknown [IPv6:2001:559:8000:c9:50e4:c235:dee1:8442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 84C4C61F9C; Tue, 28 Mar 2017 17:20:41 +0000 (UTC)
Message-ID: <>
Date: Tue, 28 Mar 2017 10:20:40 -0700
From: Paul Vixie <>
User-Agent: Postbox 5.0.12 (Windows/20170323)
MIME-Version: 1.0
To: Warren Kumari <>
CC: Pieter Lexis <>, dnsop <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] draft-tale-dnsop-serve-stale
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: Tue, 28 Mar 2017 17:20:51 -0000

Warren Kumari wrote:
> ... I think
> that the actual algorithm specified is a secondary consideration --
> first we need to agree on if the concept / idea is good for general
> use.

that will depend on the algorithm. for example if it's only stretchy for
timeouts and servfail, but nxdomain is authoritative as before, then the
best-case and worst-case outcomes are suitable for eachother, and
general use could not be worse than googledns, opendns, and akamai all
doing it with apparent success.

since it allocates no code point and the method requires no interop,
this draft feels a bit like resimprove, which died on the vine for no
reason i can now recall. it's harmless as an FYI, but does not belong on
the standards track.

speaking of resimprove, i hope you'll include in this draft the idea of
using delegation-TTL as a delegation-recheck interval, and using an
authoritative NXDOMAIN from the delegator as proof that you need to run
an "rm -rf" in your cache.

i bring this up because we need to be able to kill more cached data
faster-- the opposite of stretchiness-- for abuse control reasons. if
you're going to soften the signaling for cache expiration, you really
ought to balance that out with this simple method of also hardening it.

P Vixie