Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)

ted@tednet.nl (Ted Lindgreen) Tue, 03 April 2001 16:57 UTC

Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07971 for <dnsext-archive@lists.ietf.org>; Tue, 3 Apr 2001 12:57:34 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1) id 14kTjS-0003dQ-00 for namedroppers-data@psg.com; Tue, 03 Apr 2001 09:32:38 -0700
Received: from 64-214-53-171.dhcp.arin.gblx.net ([64.214.53.171] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14kTjR-0003dH-00 for namedroppers@ops.ietf.org; Tue, 03 Apr 2001 09:32:37 -0700
Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14kTjQ-0004dg-00 for namedroppers@ops.ietf.org; Tue, 03 Apr 2001 09:32:36 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200104030807.KAA25811@omval.tednet.nl>
From: ted@tednet.nl
Date: Tue, 03 Apr 2001 10:07:15 +0200
In-Reply-To: "Brian Wellington's message as of Apr 2, 22:47"
Reply-To: Ted.Lindgreen@tednet.nl
To: Brian Wellington <Brian.Wellington@nominum.com>, Edward Lewis <lewis@tislabs.com>
Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)
Cc: Ted.Lindgreen@tednet.nl, namedroppers@ops.ietf.org
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

[Quoting Brian Wellington, on Apr  2, 22:47, in "Re: Signature at par ..."]

> Given the lack of a defined parent-child communication mechanism, this is
> a problem.  At the workshop, that mechanism was voice, if I recall.  It
> could also be something like NOTIFY, though, which would allow the child
> to take an action and fetch the signed key from the parent.

The issue here is scaling, which already in the workshop (with only
a handfull of children) turned out to be a problem. At CAIRN, this
problem also surfaces. Please give it some thought when a parent
must deal with hundreds of thousands (the average ccTLD) or even
millions (the larger ccTLD and .com for instance) of children.

Suppose the parent want to renew its KEY, and the children hold the
SIGs.  After the parent has notified (be it by voice, telephone,
e-mail, or NOTIFY) its children, these children need to react.  It
is clear, that some of them will not react for several reasons:
network problem, sysadm on holiday, server problem, workoverload,
etc. etc.
So, our poor TLD zoneadministrator must make a choice:
1. Wait for all of them (but he... perhaps the new SIG expires before..).
2. Wait for some percentage of its children to have reacted.
3. Just continue after a specified timeout.

Not only a difficult choice, also non of them is fair (3. perhaps
looks fair "they should have done their thing, if not, it's their
problem"; however, what if none/some of the NOTIFY's reached their
destination due to TLDs fault or a network failure?).
In our opinion, this is not going to work.

However, if we turn it around: the child notifies the parent that
it wants a new KEY:
For ONE key, there is now only ONE notify and only ONE parent-child
relation in play. If the parent does not react, there is ONE sysadm
to complain to ONE other sysadm. This scales.

Regards,
-- Ted.


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.