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


To: dnssec@cafax.se
From: Olaf Kolkman <olaf@ripe.net> (by way of Ólafur Guðmundsson <ogud@ogud.com>)
Date: Mon, 15 Oct 2001 09:41:16 -0400
Sender: owner-dnssec@cafax.se
Subject: Re: Signalling DS support to resolvers

(Because of the mailproblems at cefax.se I take the liberty of resending
this message followed by the one I wrote as an answer Olafur).


My 0.02 Euro (only about 80 days to go before we can actually 'pay')


I would like to see the SEC RR to be used for this, it seems a clean
design and the idea to have to set the flag on ANY of the ZONE keys
seems error prone.

Those arguments are not good enough to make a engineering decision so
here comes another argument:

In addition the SEC RR could be stored to store some additional
administrative details about the ZONE's security. Let me try to
explain shortly, I want to write this out in more detail in a draft
but since that will take a week or two (or more) here follows a small
braindump.

We are trying to design a system for automatic "trusted-keys"
rollover. The first iteration of this idea was published as
draft-ietf-dnsop-resolver-rollover. With DS the concept of keyset
signing keys was introduced. You could call that key the secure entry
point to a zone, it is the key that the parents point to with DS and
that resolvers can have preconfigured. The method described in the
draft would not be able to distinguish between these
'secure-entry-point' keys and keys that are used for signing and may
rollover with relatively high frequency. I am thinking about how to
indicate to resolvers which key is the secure entry point. During
automatic rollovers parents and distant resolvers would need to be
able to fetch just these keys.

Indicating the status of 'secure entry point' cannot be done with a
key flag; toggling the flag would change the key id and that would be
similar to a keyrollover.

The SEC RR could be used to indicate which keys in the keyset are used
as secure entry points for a zone. This would be a purely
administrative hint to resolver administrators or to parent zone
administrators and would not influence the resolving process itself.

I find introducing a new RR for administrative purposes a little bit
of an overkill but maybe the information could piggy-back on the SEC
RR.

--Olaf


Home | Date list | Subject list