Re: [DNSOP] Is DNSSEC a Best Current Practice?

Grant Taylor <gtaylor@tnetconsulting.net> Thu, 10 March 2022 19:59 UTC

Return-Path: <gtaylor@tnetconsulting.net>
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 B3A0E3A1B92 for <dnsop@ietfa.amsl.com>; Thu, 10 Mar 2022 11:59:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.111
X-Spam-Level:
X-Spam-Status: No, score=-2.111 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=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net
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 91MBF8_zQ5ch for <dnsop@ietfa.amsl.com>; Thu, 10 Mar 2022 11:59:42 -0800 (PST)
Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (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 2FA933A1B7C for <dnsop@ietf.org>; Thu, 10 Mar 2022 11:59:37 -0800 (PST)
Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id 22AJxZ0H021304 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dnsop@ietf.org>; Thu, 10 Mar 2022 13:59:36 -0600
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2019; t=1646942376; bh=1UV6U1x42KO8W/7QeR80/okUpMVLE5qFCx5vGGR89e0=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=UVMqSyB2fMNB//xu5G2FR1Z89ED0ZJLRW4fALBW8F9uxhE5dE8c0YKRJ87TgJDQOg nhbXBWF/PQ8I++EHM2zEC3LLbnN5WSQCwpqbmG2/0g/fC79zxQSBZ8Gzu5P0gbErId GJe5QFYIpgAc9X/PTpy9PDrNnsocVfm/oliTgwRI=
To: dnsop@ietf.org
References: <88A0AA7A-01B8-4C7E-9A9A-1FB29C9FB18B@icann.org> <98EAB1A0-9746-4BAF-8865-1F28A3CBB6A4@nohats.ca>
From: Grant Taylor <gtaylor@tnetconsulting.net>
Organization: TNet Consulting
Message-ID: <198e1c3b-d48f-7cbd-d2d7-b5ba94244968@spamtrap.tnetconsulting.net>
Date: Thu, 10 Mar 2022 12:59:58 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <98EAB1A0-9746-4BAF-8865-1F28A3CBB6A4@nohats.ca>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030507050707000002050809"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uclXePGkVSWOhPhUCqFGx1Fig-4>
Subject: Re: [DNSOP] Is DNSSEC a Best Current Practice?
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: Thu, 10 Mar 2022 19:59:47 -0000

Hi,

+10 to aggregating current documentation into one place.

On 3/10/22 12:04 PM, Paul Wouters wrote:
> Even better if we would clarify DNSSEC is not an optional part of DNS, 
> but I don’t think you are volunteering for that discussion 😀

Eh ... I'm more interested in aggregating current documentation into one 
place than I am trying to alter the status quo.

I say this because I believe that aggregation / collation of already 
agreed upon (read: published) /current/ standards is a relatively simple 
thing and should have minimal objections.  Conversely, trying to change 
/ update anything will likely garner (non-trivially) more objections.

Perhaps there should be a statement speaking to aggregation / collation 
as opposed to updating in said document.

Aside:  Maybe it's just me, but I feel like there is more perceived 
value in clarifying existing documentation, in the hopes that others 
will be more likely to adopt current best practices, than there is in 
updating things.  Dare I say it, but I feel some urgency to do this.



-- 
Grant. . . .
unix || die