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

Tim Wicinski <> Wed, 01 December 2021 11:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 217023A00E0 for <>; Wed, 1 Dec 2021 03:08:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LNcJwxuJQ3Gr for <>; Wed, 1 Dec 2021 03:08:03 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 041933A00AE for <>; Wed, 1 Dec 2021 03:08:02 -0800 (PST)
Received: by with SMTP id 207so47300809ljf.10 for <>; Wed, 01 Dec 2021 03:08:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4bUr0vJvA++bC/jtT/HbyIeatzguQBZblAdkbgdMK7s=; b=L2Bxg+4bMmOAfDsryL/2uUSTqwCW9QtgfS8pO8fcLYvGpuAeergM1ypZp6G6E6RuI7 YtbSk72BfihONi+FDhbRrkO48avJDAnt2rumCHSneYgSz4py/eFGkojyqKufmBj/56Ur /uqbmoDFm25C22isMFxKV8gm3yAgwE+ZGeh0uxCxGjToAlwW7TIsxIt5JIUbRyyiGa2i 6hWPBTU/GAYYqdrAWx30/ptsp1vtPMEU7Q5TlOsQ150xhBr9fNIpOkrvE3atYYjVUwFb imYCRJc2QYB7+F6f3D6Vfwaj9n4A2Vn2EkzDmsOI1zBeDeIxoavx95YivYjNzri8Hm1k +4UQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4bUr0vJvA++bC/jtT/HbyIeatzguQBZblAdkbgdMK7s=; b=tIAuYv/xAkzZYgnccdlWA7lZmtQpQg9oNGecKwsmVrBgsbdSaf4WkIEjpSjNjE9sIT sh02Bg64wDVidY+RgFbe2UaeyvV6Tdx6KYKLi8/czVmo7xmthgovmbTn8L2zVVK4cRge nBpbJUncammTVoqypCpkZjQy+P7CbsGgpD+bedugyp/CHCIJwMmQV0yip1J3dpWEmtAh LH5H4WUoSgMpi2QnSw4CHv5u9dYEyWw86kRrKK07WkRv1fbie4un1weLTZN1RU6/ZhJE g3mQHOfG6s5dI5YF39jj+kBwDQ90TKVlabBbyLTFxldFYghsqmYN0ROSBwRa7mGABGCn oI0Q==
X-Gm-Message-State: AOAM531ZwvZdGcFNOjEUOT7VnCT7P8OY9BXRT04YvGd5NkXqbRDZyopb byK5jaNTUVLSdVdfu3Oimbd2nAzOl4xXn+NjaYulRS71Lfg=
X-Google-Smtp-Source: ABdhPJy2fBVHcROJA38iZ0pHqGhnMgTHoe5RE4LSrUbinGLD5t0MvZCCg74mAy+jbh12ZcVmug+p49cnXU0gg65IUYY=
X-Received: by 2002:a2e:a375:: with SMTP id i21mr4800375ljn.449.1638356877955; Wed, 01 Dec 2021 03:07:57 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tim Wicinski <>
Date: Wed, 01 Dec 2021 06:07:47 -0500
Message-ID: <>
To: dnsop <>
Content-Type: multipart/alternative; boundary="000000000000b9d57c05d213af0f"
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: Wed, 01 Dec 2021 11:08:08 -0000

What I noticed in reading this nice write up was the warning image they
missed in the Route53 console
because of the automation they use.  But most folks use
automation/tooling/etc in their workflow, and
catching those warnings via automation is a bit tricky.

Right after this happened several different teams looking to sign their
zones got a little nervous.
This writeup helps to show people how things can break, but also, there is
a great set of testing
methods to assist others.

Mark's comments about adding tests in DNSVIZ would be pretty great.


On Wed, Dec 1, 2021 at 5:47 AM Philip Homburg <>

> > Also stop hiding this
> > breakage. Knot and unbound ignore the NSEC records which trigger
> > this when synthesising.  All it does is push the problem down the
> > road and makes it harder for others to do proper synthesis based
> > on the records returned.
> I'm confused what this means. In the report from Slack about the incident
> I found that the problem started with a bad NSEC record, shown in their
> debug output as:
>   2370    IN      NSEC    \
> This is returned in response to a AAAA query. The intent was that the NSEC
> record should have the 'A' bit as well.
> What exactly do Knot and Unbound ignore in this case?
> Is it that they should have special processing for an NSEC that has only
> RRSIG and NSEC and nothing more?
> _______________________________________________
> DNSOP mailing list