Dynamic update, signed zones, and DS/Opt-in

["Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>]

[This question might be slightly off-topic for this
list, but I wanted to start here because the questions
are quite relevant IMHO for DNSSEC signed zones...]

All--
Is anyone on this list actively looking at how to
operationally deal with dynamic update of DNS
information in signed zones?  (I'm assuming
secure dynamic update, protected either with
TSIG or GSS-TSIG).  Yes, I've just re-read
  http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html
and the relevant RFCs.

The breakdown right now still seems to be that
if I want to be able to update my zone, and I
want the zone to remain signed more-or-less
in its entirety, then I must have a zone signing
key online.  For a lot of reasons, I've been trying
to avoid having such keys online in the policy
documents I've been writing for a particular
set of users.

It seems that the potential additions of DS
and opt-in might make things easier as follows:
 - With DS, I could use two keys--one to appear
   in the parent DS record (and to be kept off-line
   for higher assurance and rarely changed) and
   a second for the actual zone signing (which I
   would allow to be online but which would have
   a validity period of no more than 3-5 days).
   It seems that this might allow me a little more
   flexibility in dealing with dynamic update clients.

 - With opt-in on each record (which I was previously
   against, but which is at least a possibility), I
   could allow dynamic hosts to opt-out...so that
   I could secure the "main" records in a zone but
   allow mobile/dynamic update folks to change their
   data without requiring a whole new set of NXT/
   SIG records.  (yes, I know that opt-in might be
   near death right now...I'm just wondering if
   the "opt-in on each record" case that Verisign
   strongly advocated might not have another benefit.)

Neither of the above items is a wonderful perfect
solution, but the intersection of "dynamic update"
and "DNSSEC signed zones" is an ugly one that
Win2K is making a little uglier for me right now.
It's especially annoying because some folks seem
to think that a flat namespace is a requirement,
and that $large_number of Win2K boxes should
each have entries in a single zone "place.company.com"
so that they can logon to a single Win2K AD
domain.  Try as I might, I haven't been able to
convince them that a flat namespace is not a
requirement--which means I'm going to have plenty
of Win2K desktops "living" in the same domain
as critical servers--and I need signed DNS records for
the critical servers at a minimum.

If anyone thinks this is worth discussing on
namedroppers or dnsop, then please tell
me which one =8-) or I may just pick one if
no one answers up here.  If anyone has any
suggestions as to other ways to deal with this
intersection point, or I've missed something, then
I'm listening.  Thanks--

  --Rip