Re: null DK records at the parent

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

On Tue, 5 Jun 2001, Olafur Gudmundsson wrote:

> At 09:21 PM 6/5/2001, Roy Arends wrote:
> >[cross-posted reply to dnssec@cafax.se]
> >
> >On Tue, 5 Jun 2001, Scott Rose wrote:
> >
> > > I haven't seen much discussion about the DK record draft on this or =
> > > cafax.se lists, so I'd thought I'd get the ball rolling:
> > >
> > > The reason for needing null DK (or KEYs) in the parent, as I see it, is =
> > > that a security aware resolver knows to expect a DK or KEY in the glue =
> > > data when getting a delegation.  If it doesn't, it knows to query for =
> > > them to determine the security status of the child.  If it gets a null =
> > > DK/KEY record, then receives a self-signed KEY from the child, the =
> > > resolver knows the child is experimentally secure.  In these two =
> > > schemes, the parent is responsible for stating the security status of =
> > > the delegated child. =20
> 
> The main argument for NULL DK is to avoid having to look for the
> parents NXT and look inside it.


Looking at DK RR type in the nxt@parent for the child or looking for a
NULL-DK@parent for the child is to me the same. The secure resolver has to
do 1 lookup in both cases. This is ofcourse when NXT/NO are not tossed
out.


> Background: in order to get the upper/parent NXT a query to an authoritative
> server is required. If server is authoritative for both parent and child it may
> not give out both NXTs. (The ENDS0 ZONE option addresses this).


This I had overlooked. Is it valid though to require huge amounts of
information (ie. null-DK RRs) for the rare case that parent and child are
both secure and are served by the same server ? Looks to me like a
paradox. Especially those servers that serve both secured parents and
secure childs do not have the burden of serving null-DK RRs. 

If this is assumed to be valid I see no alternative then requiring
null-DK. 



> > > One thing that might be helpful to add to the DK draft (or the key =
> > > rollover draft) is how DK records should be used when performing a key =
> > > rollover.  It might be helpful when learning how to perform a secure key =
> > > rollover.
> 
> I debated putting that in, but decided against that in order to keep the
> draft focused on the core idea (not using KEY record in parent).
> There are two main key rollover strategies for DK
>          3 step (old key, old +new key, new key)
>          Master key that does not rollover and only signs the child KEY set.
> The master key idea comes from the discussion on how to maintain the same root
> key for a long time.
> 
> >When using the sig@parent/DK schemes, there is no fundamental difference
> >between obsoleting the NULL-key qualification and requiring a NULL-key at
> >the parent (it is unnecessary redundant). IIRC RFC 2535 stated that
> >sig@parent is optional, and therefore the parent needed to specify some
> >info when it wants to specify that the parent regards the child as
> >not secured.
> 
> See above discussion, but if NXT/NO is tossed out then this is not redundant.



True, but this discussion was on obsoleting NULL-DK RR, not on obsoleting
NXT/NO records. 



> >With the new drafts, the parent is required to give information on the
> >childs security status, in the case that the child is secured by the
> >parent. If the parent does not consider the child to be secure, obsoleting
> >sig/key/DK@parent is sufficient. ie, no information is in this case also
> >information.
> 
> Correct, if your resolver can talk directly to the authoritative server 
> (preferably using TSIG or SIG(0)). Explicit records can be cached for a while
> but negative answers can not.


Thats true, especially when NXT/NO records are tossed out. My reply was
written with a requirement for NXT/NO records in mind.

Regards 

Roy Arends
Nominum