Well, there is design, and then there is implementation. What I can
speak of with fair authority is the design. But I have not been
involved in the implementation, so I do not have first hand knowledge
of that. And also, they were still in a test mode...
> > Registration database: The system is designed so that delayed requests
> > are queued at the registrar (at least it was when I was involved). So
> > the bottom line is that if you can rebuild the system in 24 hours at a
> > different location you probably have adequate security. To do that
> > you need 1) distributed warm backups of the current databases, 2)
> > distributed copies of the software and configuration data, and 3)
> > machines that can be converted to the purpose in a short time (and for
> > a relatively short time, probably, since the primary site would
> > certainly be insured and rebuilt).
> >
> OK. That looks correct. Did it work? Were there _distributed_
> backups? The machines seemed to be able to get back up and working in a
> relatively short time.
All the registrations made so far have been with pure dummy
information. DNS went live just a few days before the theft, as I
recall. I do not believe, therefore, that the DB of registration
data was backed up. However, the system and configuration was backed
up enough to get things up in a relatively short time.
The RFP, as I recall, does not specify backups to multiple sites --
it specifies that there be backups to *a* remote site.
As Dave said, the threat model has somewhat changed. In working on
the RFP I consciously considered terrorist activity and natural
disaster as a possible, but very low probability issue -- say, once in
10 years. I consider the theft to fall within the same category as
terrorism or natural disaster. But it was supposed to be a very low
probability event, and now that it has happened it is necessary (IMO)
to re-evaluate the probabilities. I hope that CORE is doing so.
-- Kent Crispin, PAB Chair "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html