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

Philip Homburg <pch-dnsop-4@u-1.phicoh.com> Wed, 01 December 2021 07:35 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.com>
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 79D643A0163 for <dnsop@ietfa.amsl.com>; Tue, 30 Nov 2021 23:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 VMYeA1l4S6g5 for <dnsop@ietfa.amsl.com>; Tue, 30 Nov 2021 23:35:57 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:981:201c:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BD93A02D0 for <dnsop@ietf.org>; Tue, 30 Nov 2021 23:35:55 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1msK9b-0000HrC; Wed, 1 Dec 2021 08:35:47 +0100
Message-Id: <m1msK9b-0000HrC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
Cc: John Levine <johnl@taugh.com>
From: Philip Homburg <pch-dnsop-4@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
In-reply-to: Your message of "30 Nov 2021 13:38:07 -0500 ." <20211130183809.04E8230CA390@ary.qy>
Date: Wed, 01 Dec 2021 08:35:47 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/191EgCFKy8lkGTFAQcT2IOtz-jg>
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: Wed, 01 Dec 2021 07:36:00 -0000

>It is clear from the blog post that this is a fairly sophisticated
>group of ops people, who had a reasonable test plan, a bunch of test
>points set up in dnsviz and so forth.  Neither of these bugs seem
>very exotic, and could have been caught by routine tests.

It not clear to whether or not they did ZSK and KSK key rollovers
on test zones and on minor zones. If they didn't, thats a good way to
get in trouble later on.

The main lesson learned from this incident seems to be to always create
a test zone with content identical to that of the main zone and fully
test that zone.

A common lesson, also not mentioned, is to have low TTLs for stuff you
control. It would not have helped with the DS record. But the discussion
about the ZSK being lost would have been helped with a low TTL in the DNSKEY
RR set.