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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C47D3A0839 for <>; Wed, 1 Dec 2021 04:57:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Status: No, score=-3.951 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, 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 TEMcrMKRyQ6t for <>; Wed, 1 Dec 2021 04:57:37 -0800 (PST)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2AF213A0837 for <>; Wed, 1 Dec 2021 04:57:36 -0800 (PST)
Received: from [IPV6:2001:1488:fffe:6:235:dd9f:cd8f:bdbd] (unknown [IPv6:2001:1488:fffe:6:235:dd9f:cd8f:bdbd]) by (Postfix) with ESMTPSA id 03AB0140943; Wed, 1 Dec 2021 13:57:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1638363452; bh=aZCy7APn1Bn+JcHk/dzGngIyM57ndj+9idlZAyvj8T4=; h=Date:To:From; b=dprWVytHU0vXpIEgMRl5PCNABlKwSSCGP7e+CIjArwr6m1+jcd/EGoPspDPDPejIj SPs4NJ3twLo+PPQM9wZGr0g/Chasvq9De3N7yUd89kPvC1IlQNmURDpmEtuOqwcK4e n/zr3bSmIaGsS/CvgmMDOScTD44RkFwXGX9tKSIw=
Message-ID: <>
Date: Wed, 01 Dec 2021 13:57:30 +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 12:57:42 -0000

On 01/12/2021 13.43, Mark Andrews wrote:
> Accepting 'QNAME NSEC \000.QNAME NSEC RRSIG’ (and other type maps) protects you from random QTYPE attacks.  It also makes 'black lies' work as intended.

Black lies got bad caching if Knot Resolver accepted this aggressively.  
Asking two different QTYPEs repeatedly got uncacheable, as those answers 
need different NSEC* record contents (for the same NSEC* owner).  Of 
course, with different caching design this might be different, but it 
just didn't seem worthwhile to me.  If someone cares for good caching, 
they shouldn't use minimal ranges.