do not stupidly delete ZSK files

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

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
                                    with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally