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

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

Michael--
Thanks for your thoughts.   Comments inline below (please pardon
the screwy webmail interface that doesn't let me quote properly)

>  The major operational issues that I have are issues with being unable
> to edit the zone file properly. bind9, when it writes out the zone file,
> writes out the .signed file, which then gets whiped out again. That is
> currently keeping me from doing dynamic update more often.
So you have the key online, and automatic re-signing after each
dynamic update, but the zone file gets wiped out before the re-signing
is complete?  Or did I miss something...

> Having a master server which is not net accessible, but to which
> the secondaries can talk (perhaps over IPsec) seems like the best
> idea, but I haven't seen that work with dynupd yet, although it is
> supposed to.
Neat idea...I did know that BIND9 can proxy dynamic updates from slaves
back to the master, but I hadn't contemplated this way of doing things.
I'll definitely try to test this soon, since the "online but not
directly accessible signing/stealth master" is already the direction
that some folks have indicated they want to go.  Trying to move the
signed zone files by sneakernet didn't get many folks to say "sounds
great" when I proposed it to the particular audience I'm writing
policies for...

    Loomis> It seems that the potential additions of DS and opt-in might
make
    Loomis> things easier as follows: - With DS, I could use two
keys--one to
    Loomis> appear in the parent DS record (and to be kept off-line for
    Loomis> higher assurance and rarely changed) and a second for the
actual
    Loomis> zone signing (which I would allow to be online but which
would

> I didn't know that DS made this possible.
>  I'm not really clear what it will mean to a client to see one
> signature and not the other.
This is actually one of the neater features of DS from my perspective--
it's entirely possible to have only a single keypair (which is 1. pointed
to by the parent DS and 2. used to sign the child zone), but it's also
possible to split the functions out...and from testing with the BIND 9.3.0
snapshot at NAI back in July, It Just Works...well, mostly.  There were
some strange cases that gave non-intuitive results, and at least a few
probable code bugs, but we were able to create a signed hierarchy and
rollover "child zone signing keys" without changing the "child key
pointed to by DS at parent".  DS really provides a great way to partially
de-couple the child and parent for zone signing, so they no longer need
to be in lockstep for every change.  I thought that someone had posted a
write-up of those tests.


    Loomis> - With opt-in on each record (which I was previously
against, but
    Loomis> which is at least a possibility), I could allow dynamic
hosts to
    Loomis> opt-out...so that I could secure the "main" records in a
zone but
    Loomis> allow mobile/dynamic update folks to change their data
without

>  I think that dyndns is only interesting if the results are then
> signed.
Well yes...to *me* it's only interesting if the results are then
signed.  However, I have a large contingent of Win2K folks who are
currently implying that DNS is only interesting to them if it allows
Win2K boxes to dynamically register everything all the time (even things
which really should be statically configured and never change).  Right
now, they'd rather have GSS-TSIGish support than DNSSEC signed zones.

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

>  secure-ddns-howto suggests that you put CNAMEs in place.company.com
> pointing at place.dyndns.company.com, and only permit updates to
> dyndns.company.com. You can just have an unsigned, or a weakly signed
> (key online) zone for dyndns.company.com.
>  I have been meaning to do this. 
I've been meaning to play with it as well...but the flat namespace
folks have strongly resisted anything like this.  It's not clear, in
the wonderful Win2K Active Directory world, how this would work
(even the Active Directory servers themselves want to dynamically
register themselves, and they need to be members of the AD domain,
and the flat namespace folks want the login domain name to be the
same as the real DNS domain for the larger organization...)

  --Rip