Re: [DNSOP] On Powerbind

Paul Vixie <paul@redbarn.org> Wed, 15 April 2020 00:30 UTC

Return-Path: <paul@redbarn.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 1A3283A1369 for <dnsop@ietfa.amsl.com>; Tue, 14 Apr 2020 17:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 JsS1VCXcAETr for <dnsop@ietfa.amsl.com>; Tue, 14 Apr 2020 17:30:01 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD973A1368 for <dnsop@ietf.org>; Tue, 14 Apr 2020 17:30:01 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 2E46FB074A for <dnsop@ietf.org>; Wed, 15 Apr 2020 00:30:01 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop <dnsop@ietf.org>
Date: Wed, 15 Apr 2020 00:30:00 +0000
Message-ID: <4114089.Lb5rXcgMSS@linux-9daj>
Organization: none
In-Reply-To: <alpine.LRH.2.21.2004141951540.5865@bofh.nohats.ca>
References: <CAHbrMsAbHV8M2GR95nyZ-vCZOGghgxrdVD5NaTC=05q16HBd5Q@mail.gmail.com> <CAHbrMsAg4KMmMzntS-sWSeYJ3CWywC=Jv5pqBFdmCFmsY3tjUw@mail.gmail.com> <alpine.LRH.2.21.2004141951540.5865@bofh.nohats.ca>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7SsiAt15EIScAs8AWWgPHotv8vA>
Subject: Re: [DNSOP] On Powerbind
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, 15 Apr 2020 00:30:03 -0000

a bit in the parent (DS RRset) to say this delegation point is itself 
delegation-only would be more interesting. perhaps a way to assure compliance 
with a contract, thus preventing any ambiguity along the lines of 
"sitefinder".

but a bit in the apex (DNSKEY RRset) is still interesting, as a declaration of 
intent, which is easily monitored to find out if that intent changes, and to 
allow widespread alarms if that intent isn't lived. one can imagine breakins 
at the registry or registrar which would have the power to insert new children 
but not the power to change the apex DNSKEY.

a mature system would explicitly support this kind of live second-set-of-eyes.

vixie