[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: miekg@nlnetlabs.nl
Cc: masseyd@isi.edu, dnssec@cafax.se
From: Havard Eidnes <he@runit.no>
Date: Thu, 19 Apr 2001 11:36:01 +0200
Delivery-Date: Thu Apr 19 20:31:10 2001
In-Reply-To: Your message of "Wed, 18 Apr 2001 16:01:58 +0200"<20010418160158.A44736@open.nlnetlabs.nl>
Sender: owner-dnssec@cafax.se
Subject: Re: Keys at apex problem

> > Looking back on the namedroppers discussion, it seemed like
> > the consensus was that non-zone keys shouldn't be present at
> > the apex (I agree) and that this problem could be resolved by
> > adding a SHOULD to the spec (I don't agree).
>
> How do you see it then? As a must? I'm playing with the
> idea to mention this some more in the draft, like:
>
> If KEYS other than zone KEYS or not placed in the apex of
> a zone then they SHOULD/MUST (?) be placed in the seperate
> child zone, called keys.zone.

Hm, I'm confused by this -- I'm reading this as "if you want to have
other KEY records for keys other than the zone key at the zone apex,
you should have the KEY records elsewhere", which sort of translates
into "you can't do what you want", i.e. a requirement that you "MUST
not have other keys than the zone key at the zone apex".

If on the other hand other KEY records are allowed at the zone apex,
it strikes me as a generally bad idea to break the KEY RRset apart
and only sign the zone key at the parent -- that just goes so
totally against the more general rules of the DNS (RRsets should in
all other contexts that I can think of be handled as a single unit).

But then again I probably know too little about the finer details of
DNSSEC anyway...  (I'll at this moment refrain from making more
general comments about the general complexity and deployability of
this creature, but suffice it to say that I have my personal serious
doubts.)

Regards,

- Håvard

Home | Date list | Subject list