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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 01 December 2021 06:39 UTC

Return-Path: <ietf-dane@dukhovni.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 9EB6B3A05A1 for <dnsop@ietfa.amsl.com>; Tue, 30 Nov 2021 22:39:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 MJ_MSG8yIfDp for <dnsop@ietfa.amsl.com>; Tue, 30 Nov 2021 22:39:22 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 945863A059F for <dnsop@ietf.org>; Tue, 30 Nov 2021 22:39:22 -0800 (PST)
Received: from smtpclient.apple (unknown [192.168.1.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id CFBFEED4B9 for <dnsop@ietf.org>; Wed, 1 Dec 2021 01:39:20 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <20211130183809.04E8230CA390@ary.qy>
Date: Wed, 01 Dec 2021 01:39:19 -0500
Content-Transfer-Encoding: 7bit
Reply-To: dnsop@ietf.org
Message-Id: <3F49C6AE-D270-4EF5-996B-26B808753350@dukhovni.org>
References: <20211130183809.04E8230CA390@ary.qy>
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/AehiCpJ57iSKwUGEREXjmG3XykA>
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 06:39:26 -0000

> On 30 Nov 2021, at 1:38 pm, John Levine <johnl@taugh.com> wrote:
> 
> Can or should we offer advice on how to do this better, sort of like
> RFC 8901 but one level of DNS expertise down?

The main advice that comes to mind is to use a DNS hosting provider
with a proven (multi-year) record of doing DNSSEC reliably.

If the DNS hosting provider where Cloudflare, Google, OVH, one.com,
TransIP, ... the implementation would have been correct.

Clearly Route 53 wasn't quite ready for prime time.  It is not clear
how we can help customers know which providers have solid implementations.
I don't know of any mainstream certification programs that would do the
job.

-- 
	Viktor.