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

Mark Andrews <marka@isc.org> Thu, 05 November 2020 22:10 UTC

Return-Path: <marka@isc.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 E9AC93A1A91 for <dnsop@ietfa.amsl.com>; Thu, 5 Nov 2020 14:10:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 XDsrNeokjPzq for <dnsop@ietfa.amsl.com>; Thu, 5 Nov 2020 14:10:45 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 D96813A1AB8 for <dnsop@ietf.org>; Thu, 5 Nov 2020 14:10:45 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id B1CF83AB0C9; Thu, 5 Nov 2020 22:10:45 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 973D7160046; Thu, 5 Nov 2020 22:10:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8477816007D; Thu, 5 Nov 2020 22:10:45 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id E0M1ZAIMloBA; Thu, 5 Nov 2020 22:10:45 +0000 (UTC)
Received: from [172.30.42.84] (n114-75-120-99.bla3.nsw.optusnet.com.au [114.75.120.99]) by zmx1.isc.org (Postfix) with ESMTPSA id 1CC76160046; Thu, 5 Nov 2020 22:10:45 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Mark Andrews <marka@isc.org>
Mime-Version: 1.0 (1.0)
Date: Fri, 06 Nov 2020 09:10:41 +1100
Message-Id: <CE990E49-38B7-4EFD-AB7E-DFA58C96D5D9@isc.org>
References: <20201105.172635.572683028769863094.fujiwara@jprs.co.jp>
Cc: dnsop@ietf.org
In-Reply-To: <20201105.172635.572683028769863094.fujiwara@jprs.co.jp>
To: fujiwara@jprs.co.jp
X-Mailer: iPhone Mail (18A8395)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dE-rY4QEcD83y2hoekKsaLlKN5Y>
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 22:10:52 -0000

DNS is loosely coherent. DiS does not work when the sources of data are not coherent. 

-- 
Mark Andrews

> On 5 Nov 2020, at 19:26, fujiwara@jprs.co.jp wrote:
> 
> 
>> 
>> 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>
> 
>