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.
- snarls in real life Michael Thomas
- Re: snarls in real life Keith Moore
- Re: snarls in real life Bron Gondwana
- Re: snarls in real life Brian E Carpenter
- Re: snarls in real life Michael Thomas
- Re: snarls in real life Michael Thomas
- hampering progress Michael Thomas
- Re: hampering progress Joel M. Halpern
- Re: snarls in real life Christian Huitema
- Re: hampering progress Keith Moore
- Re: hampering progress Michael Thomas
- Re: snarls in real life Michael Thomas
- Re: hampering progress Phillip Hallam-Baker
- Re: hampering progress Keith Moore
- Re: snarls in real life Keith Moore
- Re: snarls in real life Christian Huitema
- Re: snarls in real life Michael Thomas
- Re: hampering progress Michael Thomas
- Re: hampering progress Brian E Carpenter
- RE: hampering progress Larry Masinter
- Re: snarls in real life Bron Gondwana
- DNSSEC in real life (was: snarls in real life) Keith Moore
- Re: snarls in real life Viktor Dukhovni
- Re: snarls in real life Bron Gondwana
- Re: snarls in real life Viktor Dukhovni
- Re: snarls in real life Bron Gondwana
- Re: snarls in real life ned+ietf
- Re: DNSSEC in real life Viktor Dukhovni
- Re: snarls in real life Mark Andrews
- Re: snarls in real life Viktor Dukhovni
- Re: DNSSEC in real life ned+ietf
- Re: snarls in real life Brian E Carpenter