Re: Signalling DS support to resolvers

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

On Mon, 1 Oct 2001, Jakob Schlyter wrote:

> On Tue, 25 Sep 2001, Ólafur Guðmundsson wrote:
>
> > First Dan Massey for using KEY flags to signal DS support:
> >
> > [..]
> >
> >     The proposed answer is that the parent's key includes a flag to indicate
> >     DS or SIG@child.  By looking at the parent's key, you can determine
> >     if the parent uses SIG@child or DS to sign its children.
>
> how do we know if root uses DS or SIG@child ?

In any case, always, no exceptions, the root has a key in either the DS
or SIG@child scheme. Since resolvers has to be preconfigured with the
roots-pubkey, you don't need a DS for the parent key.

Next, if a TLD has a key with "DS bit", the root has a DS for it, and vice
versa, if the root has a DS for some TLD, expect the TLD's key to have a
"DS bit".

> > Second Edward Lewis for the use of SEC RR to signal DS usage
> >
> > [...]
> >
> > One of the means to indicate a zone's security semantics is to use the
> > oft-suggested but never fully defined SEC RR set.  The SEC RR set has been
> > a latent suggestion to relate security information about a zone.  There is
> > natural resistance to defining a new RR set, which is why the SEC RR set
> > has not been put forward.
>
> I think it's time to define the SEC RR - storing information about the
> security status of a zone, such as DS vs SIG@child, in several possible
> locations (e.g. multiple KEYs) seems like bad design to me.

I dunno about SEC. I'm hesitating. Security status can be signalled by KEY
(for DS/SIG@somehere) and NXT (for optin-nosig/rfc2535), and those are
exactly the places where you need to know the status.

I'm more with the first then the second proposal. Though both probably
would work.

Regards,

Roy Arends
Nominum
-------------
0-14-023750-X dcrpt ths 43.0D.01 01.05.0C 84.18.03 8A.13.04 2D.0B.0A