Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer Thu, 12 November 2020 09:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 116253A1527 for <>; Thu, 12 Nov 2020 01:31:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RSMsYdVAIzU6 for <>; Thu, 12 Nov 2020 01:31:36 -0800 (PST)
Received: from ( [IPv6:2001:218:3001:17::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41B503A1520 for <>; Thu, 12 Nov 2020 01:31:36 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 0AC9VXwW026399; Thu, 12 Nov 2020 18:31:34 +0900
Received: from (localhost []) by postfix.imss91 (Postfix) with ESMTP id 41A706026BA0; Thu, 12 Nov 2020 18:31:33 +0900 (JST)
Received: from localhost ( []) by (Postfix) with ESMTP id 363C46026B9D; Thu, 12 Nov 2020 18:31:33 +0900 (JST)
Date: Thu, 12 Nov 2020 18:31:33 +0900
Message-Id: <>
In-Reply-To: <> <>
References: <> <>
X-Mailer: Mew version 6.8 on Emacs 24.5
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-7"
Content-Transfer-Encoding: base64
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--0.176-5.0-31-10
X-imss-scan-details: No--0.176-5.0-31-10
X-TMASE-Version: IMSS-
X-TMASE-Result: 10--0.176300-10.000000
X-TMASE-MatchedRID: mJt40tgS0QBCXIGdsOwlUu5i6weAmSDKYawhvkuLgj6qvcIF1TcLYBGG Vq+vrXC00FapvW9Wa3wHw+xBOsu3ZGfnvkmgPyIGB7MHoYnrMyHdXhRKGhNdp2JVYqWo4Zy765m RKMzHDn80ZWFmFCJaP4pLoUtG9D43QF8QVwjLuHKYvybQm0otU+Jc6hKWj0C15DjmdW0+qbHzfq AOKCG9XfjJU0Xm/BNSmGZTCDzzVEDezO9WekFnOCknxKlVP07/z3/zJxxP73sjwEWouQA/dQu8A oAyfG3RWreLugY4Oic8C+4NdSiMTcXKkE46+T28OEqbf6/UkFAr9gVlOIN/6gbYcy9YQl6eNrF+ UQD5ZgiCC1NBFWplHcvIiJdnnBTK3Ayno6rm2KzsDsv6raIUIQeCHewokHM/uM5RdaZDc5YJKq/ MwbHq8ZX5xrPIzzPckZOl7WKIImrFNZytR+M1BDDOIqGspeLdedU6lNdjG9rpaGIM46J67MZW5a i5WKlywww3Op5QOBhQofTCNET9Ub/sBNg/c+9CJzT9qDYbWmLeJO8vkH8lX1ihpNpeb3nSPXHMO qac+K1x4aW2omd9xVmuSJlhU93iSnpi4agO1o5uAyCT8Ps7ntT3kfR1lgqUzCeW4U43i9U+P6dy zNguJw==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Nov 2020 09:31:38 -0000

> From: Mark Andrews <>
> DNS is loosely coherent. DiS does not work when the sources of data are not coherent. 

Do you mean that the glue is not uniquely determined because the
authoritative server merges multiple zone information or the data
cached by the resolver part of the DNS server ?

> From: Mark Andrews <>
>> I have a question why we did not include signature validation function
>> to delegation information ?
> Delegating NS records because the zone would become big and people didn’t
> want to have TLD zones have signatures for each delegation.

  In case of TLDs with many signed (with DS) delegations, the increase
  of DiS RR is not a problem because DiS is a part of DS RRSet.

> We could sign
> delegating NS records as you can determine delegating vs top of zone by
> looking at the signer field of the NS RRset.  You would then have to deal
> with the case where you have signed parent and unsigned child and a referral
> to the grand child.

Do you mean that digest calculation is difficult because RRSets with
the same name come from servers in multiple layers and are mixed?

> You would have to stop following the referral, verify
> the child is unsigned, then restart following the referral.  This is a lot
> of work for very little benefit.

many domains are 3 layered.

root: signed  (with signed referrals)
TLD:  signed  (with signed referrals) unsigned (no referral)

Then, can't be validated, but at least it's nice to know
that the referral from the TLD is correct?

> Glue records would need a different signature type and would need to compute
> the signature differently to prevent it being used in a replay attack when
> the RRset differ.

I would like to read such draft (idea).

> I suppose you could use the same algorithm as it would
> encourage people to keep data coherent. You would still have the parent,
> child, grandchild issues from above.

If they don't share authoritative servers,
referrals (NS RRSet and glue) are uniquely determined.

>> And the idea may offer the signature for root priming data.
> It can’t.  There is no requirement for addresses records for nameservers
> for a zone to exist in the zone, as glue or not, even if the nameservers
> are below top of zone.  Glue is only required for delegations.

Yes. I agree. It's another discussion.

Kazunori Fujiwara, JPRS <>