Re: [DNSOP] AD review of draft-ietf-dnsop-serve-stale-07
Stephane Bortzmeyer <bortzmeyer@nic.fr> Sat, 14 September 2019 12:33 UTC
Return-Path: <stephane@sources.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDE812008A; Sat, 14 Sep 2019 05:33:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFrEYc7aYfWP; Sat, 14 Sep 2019 05:33:09 -0700 (PDT)
Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5DC120077; Sat, 14 Sep 2019 05:33:09 -0700 (PDT)
Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id B40B3A052F; Sat, 14 Sep 2019 14:33:06 +0200 (CEST)
Received: by mail.sources.org (Postfix, from userid 1000) id 949341908BD; Sat, 14 Sep 2019 14:29:18 +0200 (CEST)
Date: Sat, 14 Sep 2019 14:29:18 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Barry Leiba <barryleiba@computer.org>
Cc: draft-ietf-dnsop-serve-stale.all@ietf.org, dnsop@ietf.org
Message-ID: <20190914122918.oqgl22xzbegajlhw@sources.org>
References: <CALaySJK1kMuOmN-1nXgJKQVvOeF8pvphCJ3sCsyZNbLSANEFng@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALaySJK1kMuOmN-1nXgJKQVvOeF8pvphCJ3sCsyZNbLSANEFng@mail.gmail.com>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 9.9
X-Charlie: Je suis Charlie
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0jyt_gRtQ8g8zsr-JPa_ILOZHnE>
Subject: Re: [DNSOP] AD review of draft-ietf-dnsop-serve-stale-07
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 12:33:13 -0000
On Wed, Sep 11, 2019 at 12:06:23PM -0400, Barry Leiba <barryleiba@computer.org> wrote a message of 75 lines which said: > I wonder if it makes sense to be more explicit here that one isn’t > meant to keep using expired data forever, but is expected to keep > trying to refresh it. So, maybe?: > > NEW > If the data is unable to be > authoritatively refreshed when the TTL expires, the record MAY be > used as though it is unexpired until an authoritative refresh is > successful. > END I think your proposed text is worse since it contradicts the current draft, which limits the time during which you can serve stale answers "The maximum stale timer should be configurable, and defines the length of time after a record expires that it should be retained in the cache. The suggested value is between 1 and 3 days. [Even if you cannot contact the authoritative servers, my note.]" > Is another possible new security consideration that bad actors could > DDoS authoritative servers with the explicit intent of having stale > cached information used for longer, perhaps to extend the life of a > cache-poisoning attack or some such? Yes, seems right. Also reported by Viktor Dukhovni during the last call. May be add at the end of section 10 "Attackers could be incited to dDoS authoritative servers with the explicit intent of having stale cached information used for longer. But if they have this capacity, they probably could do much worse things than prolongating old data."
- [DNSOP] AD review of draft-ietf-dnsop-serve-stale… Barry Leiba
- Re: [DNSOP] AD review of draft-ietf-dnsop-serve-s… Stephane Bortzmeyer
- Re: [DNSOP] AD review of draft-ietf-dnsop-serve-s… Barry Leiba
- Re: [DNSOP] AD review of draft-ietf-dnsop-serve-s… Puneet Sood
- Re: [DNSOP] AD review of draft-ietf-dnsop-serve-s… Puneet Sood
- Re: [DNSOP] AD review of draft-ietf-dnsop-serve-s… Barry Leiba