Re: snarls in real life

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 22 April 2021 00:23 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2613A3CD3 for <ietf@ietfa.amsl.com>; Wed, 21 Apr 2021 17:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Wu1Seh8peTUt for <ietf@ietfa.amsl.com>; Wed, 21 Apr 2021 17:23:54 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 504983A3CD0 for <ietf@ietf.org>; Wed, 21 Apr 2021 17:23:54 -0700 (PDT)
Received: from [192.168.1.177] (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id E19E1C138C for <ietf@ietf.org>; Wed, 21 Apr 2021 20:23:52 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Subject: Re: snarls in real life
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <efacee7c-bb7d-4861-9037-4c122d3e28ca@dogfood.fastmail.com>
Date: Wed, 21 Apr 2021 20:23:52 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: ietf@ietf.org
Message-Id: <4AF10FFE-0045-4776-B4DD-CE0FD9084F88@dukhovni.org>
References: <93fedaa0-5ad0-dcc0-ff01-43b8e1c97989@mtcc.com> <19f2b2e1-6365-480a-86f2-111377cac2de@www.fastmail.com> <7c77e401-4703-3921-d15d-6d69b74df488@mtcc.com> <914f3492-d56b-40ca-b7e0-bbbc65603dfa@dogfood.fastmail.com> <YIC5jFjv/Q7ehujw@straasha.imrryr.org> <efacee7c-bb7d-4861-9037-4c122d3e28ca@dogfood.fastmail.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/hAhC5g6Tt0fvtsFXMKeUGW6T8I0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Apr 2021 00:23:59 -0000

> On Apr 21, 2021, at 8:00 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
> 
> That's you - you're an expert in this field.  Most people aren't.  And yet - as you mention,
> you had a bug with automated re-signing failing and had to add monitoring.

No, I did not have to add monitoring, the monitoring came first!
If it isn't monitored, it is not a critical service.  I never had
an outage, just had to fix some long ago resolved bugs.

> Also, I suspect that the content of your zone is managed by... you.

The zone content is largely irrelevant for signing, DNSSEC signing
just covers whatever is found in the zone.

> Extrapolating from that to assume that everyone else in the world will have
> the same experience... maybe the tooling has become heaps better than when
> we looked in 2016, but the list of DNSSEC failures hasn't exactly trickled
> to zero - cdc.gov in the year 2021 being a nice example case.

The tool has gotten heaps better, but some folks haven't upgraded, and have
poor operational discipline.  They likely have many other failures that
people just don't write about, because they're less popular punching bags
than DNSSEC.  It takes just a grain of competence and attention to detail,
as with any production technology.  What doesn't work is neglect, and that
also goes for unsigned DNS, with parent NS records going stale, replication
failing, ...

I am suggesting that Google can easily do DNSSEC for google.com, they likely
face non-trivial adoption barriers with global DNSSEC load-balancing, and
other specialised tech.  I am just saying the old excuses are tired out, we
can and should move on.

-- 
	Viktor.