Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer

fujiwara@jprs.co.jp Thu, 05 November 2020 08:26 UTC

Return-Path: <fujiwara@jprs.co.jp>
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 3DBB73A0CED for <dnsop@ietfa.amsl.com>; Thu, 5 Nov 2020 00:26:40 -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 3hOC2ABJUn-e for <dnsop@ietfa.amsl.com>; Thu, 5 Nov 2020 00:26:38 -0800 (PST)
Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (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 72D353A0C8B for <dnsop@ietf.org>; Thu, 5 Nov 2020 00:26:38 -0800 (PST)
Received: from off-sendsmg31.osa.jprs.co.jp (off-sendsmg31.osa.jprs.co.jp [172.23.8.161]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id 0A58QaKa002244; Thu, 5 Nov 2020 17:26:36 +0900
Received: from off-sendsmg31.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss91 (Postfix) with ESMTP id E75606024593; Thu, 5 Nov 2020 17:26:35 +0900 (JST)
Received: from localhost (off-cpu08.osa.jprs.co.jp [172.23.4.18]) by off-sendsmg31.osa.jprs.co.jp (Postfix) with ESMTP id D250A6024592; Thu, 5 Nov 2020 17:26:35 +0900 (JST)
Date: Thu, 05 Nov 2020 17:26:35 +0900 (JST)
Message-Id: <20201105.172635.572683028769863094.fujiwara@jprs.co.jp>
To: marka@isc.org
Cc: dnsop@ietf.org
From: fujiwara@jprs.co.jp
In-Reply-To: <844BBE85-AB62-485D-BD13-B40730462492@isc.org>
References: <484191FC-B161-4AC3-9A4A-538BEDA3BA6E@isc.org> <20201105.134945.746830416880055656.fujiwara@jprs.co.jp> <844BBE85-AB62-485D-BD13-B40730462492@isc.org>
X-Mailer: Mew version 6.8 on Emacs 24.5
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSS-9.1.0.1231-8.6.0.1013-25768.005
X-TM-AS-Result: No--1.994-5.0-31-10
X-imss-scan-details: No--1.994-5.0-31-10
X-TMASE-Version: IMSS-9.1.0.1231-8.6.1013-25768.005
X-TMASE-Result: 10--1.994100-10.000000
X-TMASE-MatchedRID: NRXckK99gg9CXIGdsOwlUu5i6weAmSDKYawhvkuLgj6qvcIF1TcLYOUf NhOSN2u8Ja+j7uN5ofaDNcz/VLysaEM+/sRSQraK34b00P59ZxmxQtRrr9ApRTxZFF39deGHezK Bji0+3F7eK42qKT00vJR+htnBy9ATMpC7OW35IMeeAiCmPx4NwLTrdaH1ZWqCuNQM32UkivJ54U BAehU1km8XPK8AH+KO3QfwsVk0UbvqwGfCk7KUs7k9Qtvna4s+IYmuegT1rvLVJgzI4sOxKZk0I /ffswroO6Ly6X67P3eoSxhtTBVH3kbadzl4Zutch+RglCPthX2bb9BXHDBXNIEGQQV+y2bVeD2h JOXWM08R4nsj8/4aDLrZY9sudARIftwZ3X11IV0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gm93YJDKBLsMnP8nq2Y91Iku8PQ>
Subject: Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
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, 05 Nov 2020 08:26:40 -0000

> From: Mark Andrews <marka@isc.org>
>>> One problem with DiS is that assumes that address records in the additional
>>> section *always* come from the delegating zone (see how the hash is created).
>>> This is not how DNS works.  Address records can, correctly, come from other
>>> sources, even when the name is *below* the zone cut.
>>> 
>>> Take a server that serves example.net and sub.child.example.net.  That A record
>>> comes from sub.child.example.net not example.net when the name of the server is
>>> a.sub.example.net.
>>> 
>>> 	child.example.net NS a.sub.example.net
>>> 	a.sub.example.net A 1.2.3.4
> I ment
> 	child.example.net NS a.sub.child.example.net
> 	a.sub.child.example.net A 1.2.3.4
> 
> (which should have been obvious from the paragraph above)

Do you mean these 2 lines in example.net zone ?
> 	child.example.net NS a.sub.child.example.net
> 	a.sub.child.example.net A 1.2.3.4

Then, we can generate DiS RR.
  hash ( child.example.net NS | a.sub.child.example.net A).

DNSSEC validators can get both "child.example.net NS a.sub.child.example.net"
and glue "a.sub.child.example.net A 1.2.3.4",
and validate child.example.net DiS RR.

--
Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>