Re: [DNSOP] data at delegation points

John Levine <johnl@taugh.com> Wed, 15 April 2020 15:16 UTC

Return-Path: <johnl@iecc.com>
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 6FCA73A0A3D for <dnsop@ietfa.amsl.com>; Wed, 15 Apr 2020 08:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.852
X-Spam-Level:
X-Spam-Status: No, score=-1.852 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, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=tt+1dkM9; dkim=pass (1536-bit key) header.d=taugh.com header.b=e02pyi8Y
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 TLQOpzy4LXFk for <dnsop@ietfa.amsl.com>; Wed, 15 Apr 2020 08:16:23 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 71D353A0A31 for <dnsop@ietf.org>; Wed, 15 Apr 2020 08:16:23 -0700 (PDT)
Received: (qmail 31643 invoked from network); 15 Apr 2020 15:16:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=7b99.5e972545.k2004; bh=Nav6cwZYreR3s8k/zL8PJPQC7BuKzwyWWZCrp9wsm/k=; b=tt+1dkM9iw8sS+kr8yqo5ZqiW3gIG81+I15AKwyQojOslK/MTky9Y/Grf8luyAlzjCFglSKOK6nlsRt6ITmVyaVAv16+XOCSx3pcCywGLoXPCie7VHhF2G01hPm3qLldRNATMzHpC5fcZWCGx5XIl8ejcaPcEbKEZ2b9pbRCVLxwR/J3l+J4dfJ9MYLn/ycXGLO4wnOwftqN55rNqBzz5xm3UFa3Gm5e2NH2qiynnHSXr5MISife/9Pb7gn7NmKy
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=7b99.5e972545.k2004; bh=Nav6cwZYreR3s8k/zL8PJPQC7BuKzwyWWZCrp9wsm/k=; b=e02pyi8YFMVMAbpvN/51g8SahQHcAdl7MS6U89/rsIuxNiK9NcRrJAkY3erLAM1Xc8f3t5A67drW9UGmshbL+YB4m0aH2s25EFi+CxWUo8QaTOASw4xotyUWiCuYI4BJnqFubKEZKJCUN/QJHKKp1tRgaOogjM1kBwRAVw9ivbewmgbpsnFwMXja1a18iP+h2fhldpu5+13Ha1zqmHxh6wI37ptwVl96nz+qsk7Ve18ZqKylNx0js8y9n8fAK94l
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 15 Apr 2020 15:16:20 -0000
Received: by ary.qy (Postfix, from userid 501) id DD2EE17A8967; Wed, 15 Apr 2020 11:16:20 -0400 (EDT)
Date: Wed, 15 Apr 2020 11:16:20 -0400
Message-Id: <20200415151620.DD2EE17A8967@ary.qy>
From: John Levine <johnl@taugh.com>
To: dnsop@ietf.org
Cc: paul@redbarn.org
In-Reply-To: <060513e7-742d-6de9-cf16-c367fbb13845@redbarn.org>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/asHQny5VhbK0nMnpOK0qOoAZYK0>
Subject: Re: [DNSOP] data at delegation points
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 15:16:29 -0000

In article <060513e7-742d-6de9-cf16-c367fbb13845@redbarn.org> you write:
>today it was proposed that NS2 be added as a new record-set type that 
>could exist in either the parent or the child, similar to NS, and 
>reminding several of us about the DS debacle. ...

>so instead of example.com DS, it should have been example._dnssec.com DS.

I take your point but I have a question and a half.

The plan in this draft is that NS2 would eventually replace NS
records.  Hence a zone could have a zone cut at a name that has no NS
records, so the server has to do something like scan the zone when
loaded or updated for NS2 records at names like example._ns2.com and
remember that means that example.com is a zone cut.

Adding to the excitement, NS2 in its current kitchen-sink form
replaces both NS and DS, so the name at the zone cut would not exist
at all.  The server would presumably have to synthesize an ENT there.

Does that seems feasible?  Sensible?

R's,
John