Re: [DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt

Tony Finch <dot@dotat.at> Mon, 05 November 2018 18:45 UTC

Return-Path: <dot@dotat.at>
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 A7D3D1294D7 for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 10:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 osaAsV2DBDrU for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 10:45:28 -0800 (PST)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 D580D130D7A for <dnsop@ietf.org>; Mon, 5 Nov 2018 10:45:27 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:45238) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gJjsL-000MkP-1z (Exim 4.91) (return-path <dot@dotat.at>); Mon, 05 Nov 2018 18:45:25 +0000
Date: Mon, 05 Nov 2018 18:45:25 +0000
From: Tony Finch <dot@dotat.at>
To: Dave Lawrence <tale@dd.org>
cc: dnsop@ietf.org
In-Reply-To: <23519.58661.219419.142204@gro.dd.org>
Message-ID: <alpine.DEB.2.20.1811051833080.24450@grey.csi.cam.ac.uk>
References: <20181103081228.GA32569@naina> <23519.58661.219419.142204@gro.dd.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/V1ZSIkqVJKvuwGCkIyHRYHEzGcY>
Subject: Re: [DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt
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: Mon, 05 Nov 2018 18:45:29 -0000

A few notes following the presentation and discussion earlier today
(unrelated to Mukund's comments - I'm just stealing a suitable thread)

Re. the EDNS options, if you go for a 1 bit version it should apply only
to the answer section. The only time this will be ambiguous is when there
are CNAME/DNAME chains present.

I was rather disconcerted by the 1 week default serve-stale limit in
BIND's implementation. It seems to me that the value should be tuned to
match typical outage lengths. A day seems to me to be much more reasonable
than a week, though for my servers I have chosen an hour.

Part of the reason I like serve-stale is that I think it will make outages
easier to triage for my IT support colleagues. Network connectivity
problems often look like DNS problems to even fairly knowledgable people.
If the DNS continues to provide answers when the network is a bit broken
then the investigation is more likely to head in the right direction
sooner. (My logic for choosing an hour is that if things are broken for
longer than that then it clearly isn't my fault any more!)

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
disperse power, foster diversity, and nurture creativity