Re: [DNSOP] How Slack didn't turn on DNSSEC
Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Wed, 01 December 2021 12:57 UTC
Return-Path: <vladimir.cunat+ietf@nic.cz>
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 3C47D3A0839 for <dnsop@ietfa.amsl.com>; Wed, 1 Dec 2021 04:57:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 TEMcrMKRyQ6t for <dnsop@ietfa.amsl.com>; Wed, 1 Dec 2021 04:57:37 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF213A0837 for <dnsop@ietf.org>; 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 mail.nic.cz (Postfix) with ESMTPSA id 03AB0140943; Wed, 1 Dec 2021 13:57:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; 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: <7b446404-65ec-99b8-7485-3b4b7204ebb7@nic.cz>
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 <marka@isc.org>
Cc: dnsop@ietf.org
References: <m1msK9b-0000HrC@stereo.hq.phicoh.net> <C3D5AC3A-CA5A-4F33-8BDA-DDFADD23649C@isc.org> <5f987ab1-c28a-b169-becf-1c44bdac60f4@nic.cz> <B12FC011-582F-46BC-BDEC-23AB45D33932@isc.org>
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
In-Reply-To: <B12FC011-582F-46BC-BDEC-23AB45D33932@isc.org>
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: <https://mailarchive.ietf.org/arch/msg/dnsop/qGQ3sAiCmo2MBalJCOySKONXm-0>
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 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. --Vladimir
- [DNSOP] How Slack didn't turn on DNSSEC John Levine
- Re: [DNSOP] How Slack didn't turn on DNSSEC Viktor Dukhovni
- Re: [DNSOP] How Slack didn't turn on DNSSEC Philip Homburg
- Re: [DNSOP] How Slack didn't turn on DNSSEC Mark Andrews
- Re: [DNSOP] How Slack didn't turn on DNSSEC Mark Andrews
- Re: [DNSOP] How Slack didn't turn on DNSSEC Vladimír Čunát
- Re: [DNSOP] How Slack didn't turn on DNSSEC Philip Homburg
- Re: [DNSOP] How Slack didn't turn on DNSSEC libor.peltan
- Re: [DNSOP] How Slack didn't turn on DNSSEC Tim Wicinski
- Re: [DNSOP] How Slack didn't turn on DNSSEC Mark Andrews
- Re: [DNSOP] How Slack didn't turn on DNSSEC Vladimír Čunát
- Re: [DNSOP] How Slack didn't turn on DNSSEC Mark Andrews
- Re: [DNSOP] How Slack didn't turn on DNSSEC Vladimír Čunát
- Re: [DNSOP] How Slack didn't turn on DNSSEC Mark Andrews
- Re: [DNSOP] How Slack didn't turn on DNSSEC Paul Vixie
- Re: [DNSOP] How Slack didn't turn on DNSSEC Andrew Sullivan
- Re: [DNSOP] How Slack didn't turn on DNSSEC Jim Reid
- Re: [DNSOP] How Slack didn't turn on DNSSEC Viktor Dukhovni
- Re: [DNSOP] How Slack didn't turn on DNSSEC Paul Vixie
- Re: [DNSOP] How Slack didn't turn on DNSSEC Viktor Dukhovni
- Re: [DNSOP] How Slack didn't turn on DNSSEC John Levine
- Re: [DNSOP] How Slack didn't turn on DNSSEC Petr Špaček
- Re: [DNSOP] How Slack didn't turn on DNSSEC - is … Petr Špaček
- Re: [DNSOP] How Slack didn't turn on DNSSEC Philip Homburg
- Re: [DNSOP] How Slack didn't turn on DNSSEC Mark Andrews