Re: DNSSECbis Q-8: Non-zone KEY RR at the apex.

["Scott Rose" <scottr@antd.nist.gov>]

----- Original Message -----
From: "Simon Josefsson" <jas@extundo.com>
>
> It is not like it destroys interoperability, or add any negative
> consequences for anyone.  Resolvers doesn't have to implement anything
> extra to support it.  It just works, but wastes a few bytes of
> bandwidth.  Only the administrators using it will suffer.  Those
> administrator can chose to not use it if they suffer too much.
>
> > Since SIG(0) KEYs are usually for a host/entity it would seem that
> > having an update/zone transfer key with the same name as the zone
> > might not be a good idea.  Having another name "primary.zone" or
> > "updatekey.zone" seems more logical.
>
> Is there consensus about this?
>
> If so, explain the solution in the document, so people that were using
> valid RFC 2535 constructions can migrate to the new solution.  Don't
> forget to discuss the migration issues.
>
> > While most implementations would see the flags,
>
> Any implementation that didn't would be insecure.
>
> > a human admin may make mistakes if they manually edit a zone file.
>
> Humans should use tools if they don't know what they are doing.
>

There is no consensus about naming keys for non-zone signing purpose.  There
was a question in the protocol draft about this.  I do think it is not as
severe as problem to warrent a special rule (i.e. saying "MUST NOT include a
non-zone KEY RR at the apex"), but since it was a big enough issue to
warrent a seperate note in the draft, I felt it should go through
namedroppers.

It seems so far in the discussion that most seem to think it does no harm to
the protocol in allow non-zone KEYs to have the same name as the apex.

Scott


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