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

Tony Finch <dot@dotat.at> Fri, 08 September 2017 14:16 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 E2A0313291C for <dnsop@ietfa.amsl.com>; Fri, 8 Sep 2017 07:16:56 -0700 (PDT)
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 U_PvTwtAh163 for <dnsop@ietfa.amsl.com>; Fri, 8 Sep 2017 07:16:54 -0700 (PDT)
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 B4083132153 for <dnsop@ietf.org>; Fri, 8 Sep 2017 07:16:54 -0700 (PDT)
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]:41566) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dqK5U-00006o-0d (Exim 4.89) (return-path <dot@dotat.at>); Fri, 08 Sep 2017 15:16:52 +0100
Date: Fri, 08 Sep 2017 15:16:52 +0100
From: Tony Finch <dot@dotat.at>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
cc: tjw ietf <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
In-Reply-To: <20170907154234.3z2zbju2sciiy7wr@nic.fr>
Message-ID: <alpine.DEB.2.11.1709081459550.2676@grey.csi.cam.ac.uk>
References: <CADyWQ+FHDHcmq-mr0BCHS5A8yvaOQmhTjve1_DmZN6vAc=BKyA@mail.gmail.com> <20170907154234.3z2zbju2sciiy7wr@nic.fr>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/r6gIQxUUmQAhib1il11HFZXXzUM>
Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 08 Sep 2017 14:16:57 -0000

Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
>
> I'm not enthousiastic. We should focus on making the DNS infrastructure
> more reliable, not on adding something to a pile of already fragile
> protocols.

I like this draft because it should help if we lose off-campus
connectivity. We've had a few incidents in recent years such as flooded
comms rooms and DDoS attacks on our providers. Those problems have been
addressed at the network layer, but if we have another outage for whatever
reason I would like our recursive servers to be able to handle it more
gracefully.

We have set things up so it should be possible to resolve on-site names in
our own domains when there is an outage - but not if the client does
DNSSEC validation. It isn't possible to distribute trust anchors to BYOD
clients with validating stubs, so the only way to keep going through an
outage is to retain the DS/DNSKEY chain in the cache.

It's also mildly annoying that loss of connectivity often looks like a DNS
problem, since client software never gets as far as trying to connect off
site. I would selfishly prefer it if our users would blame the network
rather than the DNS :-)

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Shannon: Northwest 5 to 7, occasionally gale 8 later. Rough or very rough.
Showers. Good.