Re: [DNSOP] How Slack didn't turn on DNSSEC
Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 02 December 2021 06:30 UTC
Return-Path: <ietf-dane@dukhovni.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 245393A0B31 for <dnsop@ietfa.amsl.com>; Wed, 1 Dec 2021 22:30:21 -0800 (PST)
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, 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 ZGOYGlUa1u7U for <dnsop@ietfa.amsl.com>; Wed, 1 Dec 2021 22:30:16 -0800 (PST)
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 240943A0B29 for <dnsop@ietf.org>; Wed, 1 Dec 2021 22:30:15 -0800 (PST)
Received: from smtpclient.apple (unknown [192.168.1.159]) (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 C7194EDF3A for <dnsop@ietf.org>; Thu, 2 Dec 2021 01:30:14 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <dc10891c-8e4e-31bd-bab1-57ae36c2b3d9@redbarn.org>
Date: Thu, 02 Dec 2021 01:30:11 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: dnsop@ietf.org
Message-Id: <321906C3-25B1-4E2C-B27D-DFA26EADC463@dukhovni.org>
References: <20211130183809.04E8230CA390@ary.qy> <3F49C6AE-D270-4EF5-996B-26B808753350@dukhovni.org> <20211201184909.32rsf3aopxpedh2j@crankycanuck.ca> <D6858547-9D32-4990-807F-01C22F2B8B3C@rfc1035.com> <E6A484B5-4276-4CA6-B441-43A8AD4D36AA@dukhovni.org> <dc10891c-8e4e-31bd-bab1-57ae36c2b3d9@redbarn.org>
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/k0L4BtetCnogDhnWfsWv6qaqXzY>
Subject: Re: [DNSOP] How Slack didn't turn on DNSSEC
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: Thu, 02 Dec 2021 06:30:22 -0000
> On 1 Dec 2021, at 4:19 pm, Paul Vixie <paul@redbarn.org> wrote: > > ... but if you're Slack or similar (cloud provider, ISP, MSSP, social network, > xAAS provider), no automation will ever be good enough by itself (wizards will > be needed.) With that qualification, I think we're much less far apart. Yes, the operations team in a complex environment needs to be more highly skilled, and not just in DNSSEC. However, I do think that the skill level required need not always be or remain "wizard". They had some bad luck running into a not fully baked stack on the provider end. Unless of course the complexity of what's being attempted will always rise to near or just past the skill level of the team, boldly going to where no team has gone before. In that case, even wizards will at times out-wizard themselves, and this is then no longer about DNSSEC really. Just that as tools get better we're never content to keep solving the old problems more reliably, we start to feel cocky about tackling new bigger problems... -- -- Viktor.
- [DNSOP] How Slack didn't turn on DNSSEC John Levine
- Re: [DNSOP] How Slack didn't turn on DNSSEC Viktor Dukhovni
- Re: [DNSOP] How Slack didn't turn on DNSSEC Philip Homburg
- Re: [DNSOP] How Slack didn't turn on DNSSEC Mark Andrews
- Re: [DNSOP] How Slack didn't turn on DNSSEC Mark Andrews
- Re: [DNSOP] How Slack didn't turn on DNSSEC Vladimír Čunát
- Re: [DNSOP] How Slack didn't turn on DNSSEC Philip Homburg
- Re: [DNSOP] How Slack didn't turn on DNSSEC libor.peltan
- Re: [DNSOP] How Slack didn't turn on DNSSEC Tim Wicinski
- Re: [DNSOP] How Slack didn't turn on DNSSEC Mark Andrews
- Re: [DNSOP] How Slack didn't turn on DNSSEC Vladimír Čunát
- Re: [DNSOP] How Slack didn't turn on DNSSEC Mark Andrews
- Re: [DNSOP] How Slack didn't turn on DNSSEC Vladimír Čunát
- Re: [DNSOP] How Slack didn't turn on DNSSEC Mark Andrews
- Re: [DNSOP] How Slack didn't turn on DNSSEC Paul Vixie
- Re: [DNSOP] How Slack didn't turn on DNSSEC Andrew Sullivan
- Re: [DNSOP] How Slack didn't turn on DNSSEC Jim Reid
- Re: [DNSOP] How Slack didn't turn on DNSSEC Viktor Dukhovni
- Re: [DNSOP] How Slack didn't turn on DNSSEC Paul Vixie
- Re: [DNSOP] How Slack didn't turn on DNSSEC Viktor Dukhovni
- Re: [DNSOP] How Slack didn't turn on DNSSEC John Levine
- Re: [DNSOP] How Slack didn't turn on DNSSEC Petr Špaček
- Re: [DNSOP] How Slack didn't turn on DNSSEC - is … Petr Špaček
- Re: [DNSOP] How Slack didn't turn on DNSSEC Philip Homburg
- Re: [DNSOP] How Slack didn't turn on DNSSEC Mark Andrews