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

Vladimír Čunát <> Wed, 01 December 2021 08:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 211B23A0834 for <>; Wed, 1 Dec 2021 00:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.952
X-Spam-Status: No, score=-3.952 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, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N6gtWJTOhA3H for <>; Wed, 1 Dec 2021 00:55:01 -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 20AA23A082C for <>; Wed, 1 Dec 2021 00:55:00 -0800 (PST)
Received: from [IPV6:2001:1488:fffe:6:83f5:63c9:257d:2a29] (unknown [IPv6:2001:1488:fffe:6:83f5:63c9:257d:2a29]) by (Postfix) with ESMTPSA id E4B2F13FAA9; Wed, 1 Dec 2021 09:54:55 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1638348896; bh=mgbZhazJch9HnN4k1xlq8397Du/7AP8er8kg2DlVQr4=; h=Date:To:From; b=J5qgcPhlfyYC75KWzBnFA/fcDQNmwjFqSBl6E1IKShS7oAFE3SVmQEIz2F+3dZWe7 ycTStrZuQI0GDcdkiJ5zcXGj90tCRtVjaeBW38kqHfXAICDOq6lUqbe2iyt6YWLjzL TQlxXobZT3asW4SxnAejgtTcuwIO8V79cSmygaxs=
Message-ID: <>
Date: Wed, 01 Dec 2021 09:54:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
Content-Language: en-US
To: Mark Andrews <>
References: <> <>
From: Vladimír Čunát <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.102.4 at mail
X-Virus-Status: Clean
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 08:55:06 -0000

On 01/12/2021 09.35, Mark Andrews wrote:
> Also stop hiding this breakage. Knot and unbound ignore the NSEC records which trigger this when synthesising.

Knot Resolver stopped treating minimally-covering NSEC* aggressively, 
but there are *two* different reasons.

1) breakages like this.  We hard-enabled aggressivity for NSEC and NSEC3 
in 2018; at that point we felt very much in minority, and it was hard to 
convince others that it's them who's doing it wrong (say, F5 customers).

2) low benefits of aggressive caching in this case.  When the range 
covers basically a single name, the possible positive effect is very 
limited.  There are negative non-breaking effects as well, e.g. caching 
of approaches like [black-lies].  You also need to weight the 
(negligible) benefits against (small-ish) costs of aggressive