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

[John Hascall]

steve rader  <rader at teak.wiscnet.net> wrote:
} > }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??

   By integrating DDNS into your existing change management system?

}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 do, see below)

}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.

   (We can, see below)

}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 can, see below)

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

   Here's how we do it.  And admittedly, this would be serious
   overkill if all we were managing was ddns, but we aren't.

   We manage dozens of different servers (DNS, Hesiod-DNS,
   Kerberos, POP, AFS, etc) serving thousands of clients.

   We use a System Management System based (ever more loosely)
   on "Moira" from MIT Project Athena / DECathena.

   The basic idea is that a database (ingres in our case) holds
   *all* of your system configuration information.  A server
   sits over this DB a provides a set of queries which view
   and manipulate this data.  This server provides the
   all the security (authentication, authentication, auditing),
   and change control (logging, journaling, etc).  On the
   back end of this are modules to update various servers
   -- either in response to a change, or as a brain-dump batch
   (e.g., as a nightly sanity check or to deploy a new instance
   of a server or for those services with no 'incremental'
   update ability like pre-DDNS DNS).

   This one machine is the only machine with the authority
   to update DDNS on the relevant DNS servers.  So, for example
   I can look in the log and see (excerpted and sanitized here):
   [I trimmed the timestamp and pid from the start of all these
   lines to minimize line-wrap too]

moirad register[#22106]: query: "get_user_extended4_by_name", "Joe", "User"
moirad register[#22106]: query: "register_user", "282796", "juser", "1", \
	"register1.cc.iastate.edu"
moirad register[#22106]: new login name OK
moirad register[#22106]: setting ID uid to 11742
moirad register[#22106]: AFS homedir user.juser mount \
	/afs/iastate.edu/users/14/30/juser created with quota of 50000
moirad register[#22106]: query: "update_user_status", "juser", "1"
moirad register[#22106]: INCREMENTAL(users, \
	[juser,11742,/bin/tcsh,User,Joe,M,2,000990000,0,POP,POP-5.IASTATE.EDU],\
	[juser,11742,/bin/tcsh,User,Joe,M,1,000990000,0,POP,POP-5.IASTATE.EDU])
moirad register[#22106]: Query complete.
moirad: incr popdns, forking /u1/sms/bin/popdns.incr
popdns.incr: users \
	(juser,11742,/bin/tcsh,User,Joe,M,2,000990000,0,POP,POP-5.IASTATE.EDU)->
	(juser,11742,/bin/tcsh,User,Joe,M,1,000990000,0,POP,POP-5.IASTATE.EDU)
update add juser.mail.iastate.edu. 3600 IN A 129.186.6.65
popdns.incr: NS Update Completed
popdns.incr: done
moirad: incr hesiod, forking /u1/sms/bin/hesiod.incr
hesiod.incr: users \
	(juser,11742,/bin/tcsh,User,Joe,M,2,000990000,0,POP,POP-5.IASTATE.EDU)->
	(juser,11742,/bin/tcsh,User,Joe,M,1,000990000,0,POP,POP-5.IASTATE.EDU)
update add juser.grplist.ns.IASTATE.EDU. 3600 HS TXT users:*:101:nogroup:65533
update add juser.filsys.ns.IASTATE.EDU. 3600 HS TXT \
	AFS /afs/iastate.edu/users/14/30/juser w /home/juser
update add juser.pobox.ns.IASTATE.EDU. 3600 HS TXT POP POP-5.IASTATE.EDU juser
update add juser.passwd.ns.IASTATE.EDU. 3600 HS TXT \
	juser:*:11742:101:,,,,:/home/juser:/bin/tcsh
update add 11742.passwd.ns.IASTATE.EDU. 3600 HS CNAME \
	juser.passwd.ns.IASTATE.EDU.
update add 11742.uid.ns.IASTATE.EDU. 3600 HS CNAME juser.passwd.ns.IASTATE.EDU.
hesiod.incr: NS Update Completed
hesiod.incr: done

   I can see that these changes were because a user registered for
   an account from a certain machine at a certain time.  If I was
   to pop into the management client and change this account's username,
   for example, a different set of changes would be performed and logged.

   So, from our point of view DDNS was a great thing.  It was the last
   bit to allow the "create your own account" part of our system to
   complete almost instantaneously (before that, they had to wait for DNS
   to batch-update in toto overnight before their account was usable).

John
-- 
John Hascall, Software Engr, Acropolis Project Manager, ISU Computation Center
http://www.cc.iastate.edu/staff/systems/john/index.html  <=- the usual crud

Shut up, be happy. The conveniences you demanded are now mandatory. Jello Biafra