do not stupidly delete ZSK files

[Lawrence K. Chen, P.Eng.]

On 2015-08-06 17:54, Heiko Richter wrote:
> -----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...

Ok, so way back then....they were running servers that didn't support NSEC3 
RRs and it had nothing to do with what algorithm we were using....5 for 
RSASHA1 or 7 for RSASHA1-NSEC3-SHA1.

It did stump when the move to RSASHA256 was made that there was a selection 
with NSEC3 in the name.  Though not as freaked out management....some how my 
manager was able to calm them down...

I don't recall if there was a conscious decision to go SHA256 or SHA512, 
except that from messages I had seen most people were doing SHA256.  Though 
back then I was still building bind 32-bit, and the hardware as much slower.  
A full signing was more than 10x longer than our current hardware....which 
can get it done in just under a minute. (usually)  The need for speed is some 
people expect DNS changes to be near instantaneous.

For those I do have a script that can run after and ssh into all my caching 
servers have flush....

Now if only I could figure out how to do that to the rest of the world to 
satisfy those other requests.

Recently saw in incident....a department that has full control of their 
subdomain made a typo on an entry with TTL 86400.  They had fixed the typo, 
but the world still wasn't seeing the correction.  Asked us if we could lower 
the TTL for it, to maybe 300.

Hmmm... no.

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