IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Wed, 01 December 2021 12:43 UTC

Return-Path: <marka@isc.org>
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 5D7063A080D for <dnsop@ietfa.amsl.com>; Wed, 1 Dec 2021 04:43:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=isc.org header.b=lzF6dD/w; dkim=pass (1024-bit key) header.d=isc.org header.b=ciumpBkf
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 r2V7LfpEXrb5 for <dnsop@ietfa.amsl.com>; Wed, 1 Dec 2021 04:43:41 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 A45573A0805 for <dnsop@ietf.org>; Wed, 1 Dec 2021 04:43:41 -0800 (PST)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 5095443593D; Wed, 1 Dec 2021 12:43:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1638362619; bh=Lo5txG0M7dkIkmJnwflOau5pHLx+2saLNa63poHESVI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=lzF6dD/wYIUPheqLfuh/vbmOzdBeWPdmNNDPAcMOvLTu9MZwggFWslrmAUo++ubDd ajQqJZ7RUhHjICQwJ4jXyL3SHKwfaZxeJiGfAZWqJrV2Y4mx41zHQZjmX+ZygUU6NO t9PfVseqf1/yqPtCLVfE6pgf3m3q8DWD6D4wuuFg=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 44703F0385E; Wed, 1 Dec 2021 12:43:39 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 177D2F04682; Wed, 1 Dec 2021 12:43:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 177D2F04682
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1638362619; bh=UoUpbAKFsi78/i6Vj72Vr/ynKqtOIkHXd2HeM7PtAzU=; h=Mime-Version:From:Date:Message-Id:To; b=ciumpBkfjmAp8XXOpI/+TV5exfUY6VASfbKJBFmx5IbVxthKohP40vPS3EKEdSR/0 CXiKHgl9C4RZYAbfrdg+SmaZdrl7FrKvzTeOMQWgnl0vZRhYoE/Q4IoxJHw5KtBC2U 1WnAbJRuagwhOYOTOVdTqQoDrN5c8YV1ZLsVdvX0=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id v_G8iv-msP_b; Wed, 1 Dec 2021 12:43:38 +0000 (UTC)
Received: from smtpclient.apple (n114-74-30-70.bla4.nsw.optusnet.com.au [114.74.30.70]) by zimbrang.isc.org (Postfix) with ESMTPSA id 5BFF3F0385E; Wed, 1 Dec 2021 12:43:38 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <5f987ab1-c28a-b169-becf-1c44bdac60f4@nic.cz>
Date: Wed, 01 Dec 2021 23:43:36 +1100
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B12FC011-582F-46BC-BDEC-23AB45D33932@isc.org>
References: <m1msK9b-0000HrC@stereo.hq.phicoh.net> <C3D5AC3A-CA5A-4F33-8BDA-DDFADD23649C@isc.org> <5f987ab1-c28a-b169-becf-1c44bdac60f4@nic.cz>
To: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xPCxGYlZ1dL1xAJp6sbd9bjVF8M>
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:43:47 -0000


> On 1 Dec 2021, at 19:54, Vladimír Čunát <vladimir.cunat+ietf@nic.cz> wrote:
> 
> 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 cache-searching.
> 
> [black-lies] https://blog.cloudflare.com/black-lies/

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.

The existing synth-from-dnssec code in BIND doesn’t treat this pattern as special.  I’m arguing that special code for this isn’t needed and if it put in it would be removed in the next production release cycle.

As for F5 we had been reporting issues like this as well.  That said I believe they now have published work around instructions for the old servers (add A and/or AAAA records to the backing zones to generate the correct NSEC typemap) and the new code you specify the type list for NSEC / NSEC3.  Presumably F5 add A and AAAA as appropriate
to this if they are missing.  Hopefully HTTPS soon.

The issues with zone enumeration have been grossly exaggerated.  For most zones on the Internet there is no benefit in preventing enumeration and only costs as you leave yourself exposed to reflected random subdomain attacks.

> --Vladimir
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email