Re: [DNSOP] How Slack didn't turn on DNSSEC

Viktor Dukhovni <> Thu, 02 December 2021 06:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 245393A0B31 for <>; Wed, 1 Dec 2021 22:30:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZGOYGlUa1u7U for <>; Wed, 1 Dec 2021 22:30:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 240943A0B29 for <>; Wed, 1 Dec 2021 22:30:15 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C7194EDF3A for <>; 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.\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Thu, 02 Dec 2021 01:30:11 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20211130183809.04E8230CA390@ary.qy> <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [DNSOP] How Slack didn't turn on DNSSEC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Dec 2021 06:30:22 -0000

> On 1 Dec 2021, at 4:19 pm, Paul Vixie <> 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...