running w/ win2k as master and bind8 as slave (was win2k's dns)

[steve rader]

 > }Jim Reid  <jim at mpn.cp.philips.com> wrote:
 > }just changes this problem: you use strong crypto to authenticate the
 > }thing making the update. But there's still no real control over what
 > }that update changes 
 
 > From: John Hascall
 >     How is that problem really different that there's no real change
 >     control over what editting random.conf.file changes.  Change
 >     control is a more general management problem.  If you're doing
 >     a sloppy job pre-DDNS, you'll probably still do a sloppy-job
 >     post-DDNS.

But if you do a good job of change management pre-DDNS, how
can you do a good job of change management post-DDNS??

Lots of folks overlay robust change management systems on top of
good ol' BIND to provide authorization control and auditability.
I doubt anyone will every reasonably overlay a change management
system to provide authorization control and auditability of
DDNS changes.

We have revision histories, change logs, trouble tickets and the
like to associate with (ahh, well, almost =:) every DNS change.
With DDNS, we can't continue to gather all this change management
information.

If I run DDNS and I notice a change that's happened via DDNS,
I doubt I will ever be able to answer three very important
security related questions: 1) should that change have been
allowed? 2) who made that change? 3) why was that change made?

I think DDNS is vaguely scary: it appears to have significant
security issues because it lacks fine-grain authorization
control and auditability.

later
steve
- - -
systems guy
wiscnet.net