Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt

[Roy Arends <Roy.Arends@nominum.com>]

On Tue, 3 Jul 2001, Mark Kosters wrote:

> On Fri, Jun 29, 2001 at 06:39:23PM +0200, Jakob Schlyter wrote:
> > I think the opt-in flag should be moved to a separate RR, a modified
> > version of Ed Lewis SEC RR would probably we a good choice (although I
> > would perhaps like to call it ZSS for Zone Security Status instead).
>
> I agree with having some sort of way of indicating the type of dnssec
> that is offered by that particular zone. This would also help with the
> NXT/NO problem as well. We used an unused bit in the KEY RR for opt-in
> given there was no other alternative.

One could allocate a type-bit > 127 to be put in NXT (with RR-type bit
zero set to 1) to indicate different format.

There is no NXT/NO problem that has to be solved by SEC. Both RR types can
be in a zone, the server serves it, the resolver interprets it. I don't
see why a SEC record should indicate that there are NO records in a zone
or NXT records in zone. The response clearly has either NXT or NO in its
response.

(The only reason for a SEC record I can think of is to indicate that there
are neither NO nor NXT records. That would obsolete opt-in all together)

Note that this is not a "what to expect" thing. If the parent states that
a child is signed, the resolver expects either NXT or NO. (NO RR is still
draft ofcourse).

It is a chicken or egg thing. If there exists no SEC RR for the child,
it gets either NXT or NO.

> > the opt-in flag is a per zone flag. as there could be multiple zone keys
> > and if KEY would include this flag, all zone keys has to have the same
> > flag (for that bit). also, as the zone key are signed by the parent, the
> > child can not change from/to opt-in without having the parent sign the
> > child's key.
>
> That brings up a question. Is it better or worse for this to be stored in the
> parent so the resolver knows what type of zone it is dealing with before it
> queries the child?

When there is no indication in the NXT record if it is opt-in or rfc-2535
style, one has the KEY (bit 4 in flag field) to indicate it with. IE One
already knows, _before_ quering a child what to expect. Again, no uses for
SEC here.

I would opt :-) for an opt-in indication in NXT by using a type-bit > 127.

Regards,

Roy Arends
Nominum