Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

Vladimír Čunát <> Thu, 07 September 2017 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 355C9132940 for <>; Thu, 7 Sep 2017 11:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 B5EY07sf7iB5 for <>; Thu, 7 Sep 2017 11:32:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2712F13263F for <>; Thu, 7 Sep 2017 11:32:29 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 36CC661109; Thu, 7 Sep 2017 20:32:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1504809147; bh=RuXokHujge6ipxp1cyy59M5vrC5N28IaDB4r6jKS+rI=; h=To:From:Date; b=rkKyNnP/lhFN8q7/P9qfNi8C5X3IRbnSaic+tHt2ROLQw9VaS5QkNgXQpPSTgonv3 CGynI5UQC7feUDMCYBOBSueGEtvKzvqAf24d6gOGTKgJ07zYLMDwG2zMbr9zb1u17F bBkgdWod/dptawe6BYzbS0zTb57KrWYOeCYXyAJ0=
Cc: Joe Abley <>
References: <> <> <>
To: dnsop <>
From: Vladimír Čunát <>
Message-ID: <>
Date: Thu, 07 Sep 2017 20:32:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] DNSOP Call for Adoption - 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: Thu, 07 Sep 2017 18:32:31 -0000

On 09/07/2017 08:25 PM, Joe Abley wrote:
> I also think if a standard specification can be obtained it ought to include appropriate instrumentation to allow a response to indicate whether data is stale or not. This seems to me just one example of a set of additional components we might expect the working group to come up with, which in my mind is a good reason to make it a working group document.

Yes, an interesting idea.  It should be easy to design an EDNS option
that allows to (1) customize some parameters of this (opt-in, opt-out,
request a different client-timeout) and (2) indicate whether some RRs
are stale and perhaps how much stale they are.