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

Tony Finch <> Wed, 06 March 2019 13:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0303130EDC for <>; Wed, 6 Mar 2019 05:03:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ctiuYigfA0_U for <>; Wed, 6 Mar 2019 05:03:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14F971292F1 for <>; Wed, 6 Mar 2019 05:03:32 -0800 (PST)
X-Cam-AntiVirus: no malware found
Received: from ([]:38806) by ( []:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1h1WCm-000sd9-ej (Exim 4.91) (return-path <>); Wed, 06 Mar 2019 13:03:28 +0000
Date: Wed, 6 Mar 2019 13:03:28 +0000
From: Tony Finch <>
To: Dave Lawrence <>
cc: dnsop <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <4253851.Zqd2zPpPcC@linux-9daj> <> <> <> <> <> <>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
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: Wed, 06 Mar 2019 13:03:35 -0000

Dave Lawrence <> wrote:

> REFUSED is slightly murkier as to its exact meaning, thanks to
> overloading, but in its most commonly seen usage for lameness
> indicates a clear problem with the delegation.  Even in its other use
> cases, notably an EDNS Client Subnet error or an actual "I am
> authoritative for the name but administratively denying your
> resolution of it", I submit that if the resolver has a stale answer
> then serving it is reasonable.

This sounds like it will lead to stale answers being given instead of
re-trying other potentially working servers. I think this is wrong, and
it's inconsistent with your other reply, so I am confused.

I think serve-stale should only cover cases where servers are unreachable
or unresponsive.

If all a zone's servers start to reply REFUSED, that's a deliberate
decision to disable the zone, and resolvers should not try to keep it
alive beyond its TTL. (This is important for the take-down situations that
Paul Vixie is concerned about.)

I'm more ambivalent about the SERVFAIL case but it seems simpler to treat
it the same as REFUSED, i.e. server is working but not for this zone.

There's a big difference between the RFC 4697 (Observed DNS Resolution
Misbehavior) section 2.2 (Repeated Queries to Lame Servers) lame server
cache time of 30 minutes and the serve-stale retry time of 30 seconds,
which makes me think the serve-stale spec should explicitly update RFC

f.anthony.n.finch  <>
Lyme Regis to Lands End including the Isles of Scilly: South, veering west or
northwest 5 to 7, occasionally gale 8 later. Moderate or rough, becoming very
rough for a time in far west. Thundery showers. Good, occasionally poor.