Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

Dave Lawrence <> Tue, 26 March 2019 13:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA068120004 for <>; Tue, 26 Mar 2019 06:19:14 -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 JUQOTcjGwTub for <>; Tue, 26 Mar 2019 06:19:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E3297120003 for <>; Tue, 26 Mar 2019 06:19:11 -0700 (PDT)
Received: by (Postfix, from userid 102) id E203F8F69D; Tue, 26 Mar 2019 09:19:10 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Tue, 26 Mar 2019 09:19:10 -0400
From: Dave Lawrence <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Archived-At: <>
Subject: Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
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: Tue, 26 Mar 2019 13:19:15 -0000

On Tue, Mar 26, 2019 at 12:48 PM Tony Finch <> wrote:
>> I think the suggested max stale timer of 7 days is excessive. The aim is
>> to cope with an outage, so I think 1 day is much more reasonable (though I
>> have configured my servers with a 1 hour limit).

Olli Vanhoja writes:
> I agree. At least based on my own experience, all the network or other
> downtime issues I have experienced last only few minutes. 

Okay, I agree a little that 7 days is probably excessive as a
recommendation, though not harmful.  I also agree that in most
instance where serve-stale has already proven itself to be useful, 
the events are fairly short-lived.

On the other hand I have direct operational experience that says if a
problem is being caused not by a generalized DOS or other transient
network issue, then it can indeed take multiple days to resolve.
Start of a long weekend?  Trying to reach the right people to fix it?
Surely you've experienced customers not responding quite as quickly to
fix their problems as you'd like.

So I'm not so keen on one day, but could see dropping the
recommendation to 3.  It is, after all, still just a recommendation
and one that should be configurable.

> If there is a downtime longer than that and it's only affecting DNS,
> I would seriously consider changing my service providers and
> vendors, whatever is the issue.

Right!  But in the meantime, until that change is done ...