IETF Logo Mail Archive

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

Philip Homburg <pch-dnsop-4@u-1.phicoh.com> Wed, 01 December 2021 10:47 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 DB1433A097E for <dnsop@ietfa.amsl.com>; Wed, 1 Dec 2021 02:47:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 XcuXKnUJe-iT for <dnsop@ietfa.amsl.com>; Wed, 1 Dec 2021 02:46:58 -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 4F4FE3A0963 for <dnsop@ietf.org>; Wed, 1 Dec 2021 02:46:56 -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 m1msN8S-0000HPC; Wed, 1 Dec 2021 11:46:48 +0100
Message-Id: <m1msN8S-0000HPC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
From: Philip Homburg <pch-dnsop-4@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <m1msK9b-0000HrC@stereo.hq.phicoh.net> <C3D5AC3A-CA5A-4F33-8BDA-DDFADD23649C@isc.org>
In-reply-to: Your message of "Wed, 1 Dec 2021 19:35:52 +1100 ." <C3D5AC3A-CA5A-4F33-8BDA-DDFADD23649C@isc.org>
Date: Wed, 01 Dec 2021 11:46:47 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DiRgr_cVr4dNG6VhE7s7aHQz1lM>
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 10:47:03 -0000

> 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:

qqq.slackexperts.com.   2370    IN      NSEC    \000.qqq.slackexperts.com. RRSIG 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?

v2.30.2 | Report a Bug | By Email | System Status