do not stupidly delete ZSK files

[Heiko Richter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 07.08.2015 um 00:23 schrieb Lawrence K. Chen, P.Eng.:
> 
> 
> On 2015-07-31 06:33, Tony Finch wrote:
>>> Most zones have four authoritative nameservers, only one of
>>> which I manage. Of the three I don't manage, I'm pretty sure at
>>> least two have no DNSSEC-specific configuration -- a hint that
>>> any DNSSEC records they serve come from this hidden primary.
>> 
>> The DNSSEC records come from the zone data like any other
>> records. You don't need any special DNSSEC configuration to act
>> as a secondary for a signed zone - it just works.
>> 
> 
> Is that the case now?  I recall when I was initial deploying
> DNSSEC, DLV required that all my nameservers respond the same.
> 
> We use NSEC3 on our zones, but at the time our network operator's 
> nameservers didn't support NSEC3, so were absent from their
> responses. Had to delay until they upgraded their servers
> (something about needing to upgrade from 5 to 6 first), before we
> could go DNSSEC.
> 
> At first I was just going to turn off NSEC3, but our CISO decided
> we had to have it.  Though until earlier this year we used a
> constant 4 digit salt. (ascii for KS ;)  Now I have it generating a
> new random 16 digit salt, adapted from example from some paper I
> had read.... (and each signing generates its own salt...
> 
> Even though it is apparently still possible to walk a NSEC3 domain,
> I think it was to more to hide any embarrassment cruft in our zone
> file. No idea when somebody will decide to finally clean things
> up. Other than that recollection, I haven't looked into what
> possible issues we could run into if the capabilities of our
> outside managed secondaries didn't match the appliance.
> 
> Like what if those secondaries only supported up to RSASHA256, but 
> appliance with crypo accelerator prefers RSASHA512 (or perhaps some
> GOST ... or ECDA/SHA384, which aren't in my named builds...still
> using 0.9.8zlatest - avoids figuring what else depended on
> it....aside from clamav on our virus filters.)  Actually, I wonder
> if a transition to RSASHA512 on my nameservers wouldn't be bad....
> my bind builds are 64-bit.
> 

The secondaries don't have to support any encryption algorithms as
they will not use them. These encryption algorithms are used to create
the RRSIG records (a process running only on the master) and to verify
them (a process running only on dnssec-enabled recursive servers).

Whenever you update your zone with nsupdate or you run 'rndc sign' on
your zone the master creates the signatures and saves them in RRSIG
records. Then it sends out notifys to all secondaries, which will
re-transfer the zone from the master. From that point on the only
thing your servers have to do, is hand out records from the existing zone.

The only thing your servers have to support are the record types. So
if your server is still living in the stone age and doesn't know about
the existence of DNSKEY, RRSIG and NSEC3 resource records, it will
probably have problems to handle your zone.

But if such a server still exists nowadays, not having dnssec will be
the least of it's worries as has missed decades of security updates...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJVw+WJAAoJECKEz6pWghImuowP/j7lLD/8+VbHxvNY7P3O+9jQ
+r8tA80mkf9JJ5MdLejOm50eZuTShulSVuIYqdlfttXxkVb51dI16ej6fLzJj3Ed
qKeO8EBU/LJKaOosUuDxZyrPbrw8iPRXeERFF44z16NfGtMsvP4BROyDRZD4EJnD
O1dxDmBBT2+hz9NJ69PtRmbxTjXYds/w4gXr1Jb9qp41a0l9PwgPnGbaYtHdi2be
0py05poIJKYk2z+qxBHYc/uKAzlIvLFhk63GWRZjYaPJNoWAW50vDXy6+vMGEIiq
Fb3jpXYyxYxRV/TOF7L8Cehgy0Bvz1jk/JUoWfXEt5ZfVLq+XITaIZxYe2i2Rdd0
6j51X3c8CVBfpEWNoMqo/YiDhQ++D51glN+oRMlBMdpZHmVVsWpZyTOttXfUTeuB
ZmIM6ntNb6t6ofJBwF4ihrnm0Z4l21d4wbe/nETbCzoPkct9T0QsN9D9wYD8rkFf
ksU6H+N0SZvX8Y+DS9D0cJ5WfZnP9PM5syt47YKVr9yLMQGRZbb31S6c3u/Myhq5
qiIjUZETSVxoCEz3iZnmdbY4bE+u73jHe7yt+akW1mpnwfiiyyxjZNYKws/otT62
8ge/XIZoaVd5AzM2o2Ew7bYu75dM2fTjltVdKOGz4tLbtMcr/ydXQYz7FcoM2jxU
8tgxPfOQtUknMtA7IoZ9
=1Xlf
-----END PGP SIGNATURE-----