Subject: Signing an opt-in zone

From: Ed Lewis <[email-masked]>
Date: Wed, 15 May 2002 16:31:24 -0400 (EDT)

I was thinking about how one would go about signing an opt-in zone.

Assuming opt-in is restricted to delegation points, it would seem that the
signer would sign any name with a DS set.  There are two other cases,
delegations that are unsigned but in the NXT chain and opt-in "out"
delegations.  How would a signer know how to treat an un-DS'd delegation?
Do we need to resurect the $SIGN directive, or is this an issue not
germaine to DNSEXT?

For non-delegations (assuming opt-in is made applicable here) the same
problem applies, without the "certainly sign this name" case of the DS
record.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Brian Wellington <[email-masked]>
Date: Wed, 15 May 2002 15:43:57 -0700 (PDT)

> Do we need to resurect the $SIGN directive, or is this an issue not

I would expect the signer to generate the DS set in the first place, so it
couldn't use that as an indication of anything.  The method I've used is
to load the 'secure' and 'unsecure' parts of the zone separately. This
conveniently allows provably insecure delegations (by checking for
existence of zone keys) as well as opt-out names.

I don't really think this is a protocol issue, though.

> problem applies, without the "certainly sign this name" case of the DS

The above method works here too.

Brian

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 16 May 2002 08:39:00 -0400

----- Original Message -----
From: "Brian Wellington" <[email-masked]>
Subject: Re: Signing an opt-in zone

> existence of zone keys) as well as opt-out names.

So the signer utility looks for the KEY record, or a K.+00X.key file?  I
remember some discussions about how and what a subzone will give it's parent
zone:  a premade DS key or a KEY record and have the parent construct the DS
RR.  I guess BIND's tools look for a KEY record and constructs the DS record
from there?

> I don't really think this is a protocol issue, though.
Neither do I - a related question - should we regard how a subzone gets the
DS record made/placed in the parent zone a protocol issue as well?

Scott