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

Mark Andrews <> Thu, 05 November 2020 23:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8288F3A0799 for <>; Thu, 5 Nov 2020 15:39:29 -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 wrE1MSuAxwm0 for <>; Thu, 5 Nov 2020 15:39:27 -0800 (PST)
Received: from ( [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C1A6D3A0779 for <>; Thu, 5 Nov 2020 15:39:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B18893AB001; Thu, 5 Nov 2020 23:39:25 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTPS id A742B160046; Thu, 5 Nov 2020 23:39:25 +0000 (UTC)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9547916007E; Thu, 5 Nov 2020 23:39:25 +0000 (UTC)
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id zEwRiCwEZCmT; Thu, 5 Nov 2020 23:39:25 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPSA id 04AEE16007D; Thu, 5 Nov 2020 23:39:24 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Mark Andrews <>
In-Reply-To: <>
Date: Fri, 06 Nov 2020 10:39:22 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.3445.9.7)
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, 05 Nov 2020 23:39:29 -0000

> On 4 Nov 2020, at 15:31, wrote:
> I submitted draft-fujiwara-dnsop-delegation-information-signer-00.
> Name:		draft-fujiwara-dnsop-delegation-information-signer
> Revision:	00
> Title:		Delegation Information (Referrals) Signer for DNSSEC
> Document date:	2020-11-03
> Group:		Individual Submission
> Pages:		6
> URL:  
> DNSSEC does not have a function to validate delegation information.
> I think it is a large missing peace of DNSSEC.
> 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.  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.  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.

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 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 one wants to stop spoofed referrals being accepted do something like
well known TSIG which will stop off path spoofed traffic dead.  It will
also stop off path reassembly attacks dead as the spoofed reassembled
packet will be rejected.  On path attackers can just race the server
without DNSSEC.

Chairs, can you issue a call for WG adoption of my well known TSIG
draft please.
> Probably, because it is non-authoritative information.
> Or, because it was difficult to define the necessary and sufficient
> delegation information.
> It is now widely agreed (although not explicitly documented) that the
> delegation information is the information used for name resolution and
> does not result in name resolution.
> We have a word "in-domain" glue which is the necessary and sufficient glue.
> 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.

> If someone interested the document, I would like time slot at dnsop WG
> meeting.
> Regards,
> --
> Kazunori Fujiwara, JPRS <>
> _______________________________________________
> DNSOP mailing list

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: