bind autosign - DS distribution

[Kevin Oberman]

> From: Chris Buxton <chris.p.buxton at gmail.com>
> Date: Thu, 9 Dec 2010 21:16:41 -0800
> Sender: bind-users-bounces+oberman=es.net at lists.isc.org
> 
> 
> On Dec 9, 2010, at 2:26 PM, Matus UHLAR - fantomas wrote:
> 
> > Is it possible(planned) for bind to sign slave zone?
> > And, are incremental updates possible with dnssec?
> > 
> > I'm thinking about hidden master bind loading (un)signed zones and providing
> > axfr/ixfr to our public servers
> 
> Secure64 makes a product that does this.
> 
> - The hidden master creates/updates an unsigned zone.
> - Secure64 appliance acts as a slave, transferring the zone in
> response to notify messages. It then signs the zone, including
> auto-generating and auto-rotating keys as needed (I believe).
> - Secure64 appliance then acts as a second hidden master, replicating
> the zone out to the regular slaves.
> 
> I believe it's implemented using two instances of nsd (from NLnet
> Labs), one acting as a slave and another acting as a primary master,
> with some proprietary code in between.
> 
> http://www.secure64.com/automated-DNSSEC-signer-software-appliance
> 
> Note: You hinted that the unsigned zone content is generated by some
> process that would be difficult to modify. Products from my employer
> and our other competitors would not have as easy a time handling that
> type of need as this off-the-shelf product from Secure64. If that is
> not the case, however, I would be happy to talk to you about DNSSEC
> solutions from BlueCat Networks.

Your description is pretty close. The main exception is that it only
runs a single instance of nsd. It acts as both client and server. When
it updates a zone, it then signs the data and sends out notifies to the
slaves which publicly serve the data. No need for two instances.

I believe the real claim to fame of Secure64 is the security of the
private keys. The system is FIPS140-2 level 2 certified and that is hard
to come by, especially without an HSM. This is very nice of dynamic
updates are required since most solutions require an HSM or store the
private key in an on-line system.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751