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

Paul Wouters <> Wed, 06 March 2019 02:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B55D212F1AB for <>; Tue, 5 Mar 2019 18:55:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GtRufDyYcWsi for <>; Tue, 5 Mar 2019 18:55:09 -0800 (PST)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C7791277CC for <>; Tue, 5 Mar 2019 18:55:09 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 44DdfL08mQz35K; Wed, 6 Mar 2019 03:55:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1551840906; bh=fjs+73000PswQZE/tfHsFvlr0iNXcMSJGNBUeaQcN04=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=W7WciKUi+m24AdN35wInYMmpl/OR2llkHh58e3GKc0Eaage8odW0H30izsUruFQF8 ohfJPl47ZvRfiwxQEsfYfDTXi6UhmuqVn9b0kIhxr92O9mTANxyfnIKLklDdn9+7Ai 1j2SPYG9FkeoMe82HIEkTMoSCG84GiIL2lvD0XaE=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wW20SB8HRqia; Wed, 6 Mar 2019 03:55:05 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Wed, 6 Mar 2019 03:55:04 +0100 (CET)
Received: by (Postfix, from userid 1000) id 196A939A5BC; Tue, 5 Mar 2019 21:55:04 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 196A939A5BC
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E7A1411602B; Tue, 5 Mar 2019 21:55:04 -0500 (EST)
Date: Tue, 5 Mar 2019 21:55:04 -0500 (EST)
From: Paul Wouters <>
To: Dave Lawrence <>
cc: dnsop <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <4253851.Zqd2zPpPcC@linux-9daj> <> <> <> <> <> <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
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 02:55:12 -0000

On Tue, 5 Mar 2019, Dave Lawrence wrote:

> I can sort of see how someone might infer from "It is predicated on
> the observation that authoritative server unavailability can cause
> outages ..." that it means this whole idea is constrained to DDoS, and
> presumably you would include as well other network and server outages
> not caused by DDoS.  It doesn't only mean that though.  The intention
> is that this applies to any inability to get a proper authoritative
> response, one which has AA set in a protocol-meaningful way.
> This can be edited to be clearer, perhaps as simply as changing
> "authoritative server unavailability" to "authoritative answer
> unavailability".  We'd be happy to consider alternative text.

Ok, then that needs to be clarified in the draft. And you should discuss
exactly which kind of failures are valid for extending the TTL and which
are not and which should still try another auth server.

> ServFail is a clear signal that something is going wrong with the
> authoritative server itself has something going wrong.  If you send a
> ServFail then AA is completely irrelevant.
> 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.  In that administrative denial case
> it'd be better to issue NXDomain anyway, which is exactly what split
> horizon authorities do.
> Other lesser seen rcodes are largely similar in not indicating
> anything at all about the legitimacy of the name and whatever data you
> might have previously associated with it.  Only the dynamic update
> rcodes come close to being relevant, but they are not part of the
> resolution process covered by serve-stale.
> Despite the unfortunate RFC 1035 nomenclature of NXDomain as "Name
> Error" it is called out explicitly because it isn't really an error,
> not in the database lookup sense.  There's no way of knowing whether
> the NXDomain is happening because of operator fault or the far more
> likely case that it just doesn't exist.  That's why it is called out
> separately in the doc, with an explicit note about why it has to be
> treated as replacing any stale data associated with the name.

So put some text similar to this in the draft.