do not stupidly delete ZSK files

[Lawrence K. Chen, P.Eng.]

On 2015-08-07 09:50, Heiko Richter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am 07.08.2015 um 07:16 schrieb Lawrence K. Chen, P.Eng.:
>> 
>> 
>> On 2015-08-06 19:26, Heiko Richter wrote:
>> 
>>>> 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.
>>> 
>>> So either you have very slow servers, or a really big zone, if
>>> it takes a whole minute to sign it.
>>> 
>>> Just use inline-signing and the changes will be instantanious. As
>>> soon as nsupdate delivers a change to the master server, it will
>>> sign it automatically and send out notifies. Doesn't even take a
>>> second, as only the changes need to be signed, not the whole
>>> zone.
>>> 
>> 
>> Its big and probably full of a lot of stuff that isn't needed
>> anymore, etc.  Though there something weird about the zones too.
>> 
>> our ksu.edu zone will have more entries than the k-state.edu one,
>> even though by policy they should be the same,
> 
> Just one addition aside the face that your network seems to drown in
> chaos:
> 
> If the two zones are mandated to be the same, just empty one of them,
> put a DNAME record in it that points to the other one and make all
> future changes there. That way you can be sure the two zones are
> always in sync....
> 

But, there are cases where what is pointed for a name differs.  It has only 
be recent that we've had access to multi-name certificates, and so far 
nothing has migrated to the new F5 where SNI is available.  There had only 
been one request an SNI virtual server...but that was before I knew whether 
there was ever going to be a new F5 in the future.  There had been a lot of 
talk that we'd stop.... the F5 is the first thing that is blamed ... when its 
doing the best it can.

There are also specific exceptions where something is only in one side and 
not the other (though not all the reasons are clear or known to me....plus 
the ones that just make no sense at all.  Like our central LDAP is 
ldap.k-state.edu, while there was a personal website on ldap.ksu.edu....)  
Though it was a conscious decision that our rfc1918 systems were only in 
'campus.ksu.edu', so there's no campus.k-state.edu entry.

Can't recall off the top of my head of case where something exists only in 
k-state.edu.  But, I'm sure if I looked there'll be some.

Otherwise, we make pretty heavy use of $INCLUDE of sections that are common 
on both sides....especially after an incident where there was a significant 
mismatch (due to over-editing...have to be more careful when using global 
search and destroy ;)

Hopefully the use of relative $ORIGIN's in include files remains valid.  
Though I had found some include files where they created two blocks of 
$ORIGIN.  Which seems to have become extra noisy now.

namely giant log file (close to its 10M rotate point.) grep out those lines 
to see what other warnings there are....left with less than a screenful of 
lines....  stopping those, it was time to turn my attention back to fixing 
the sharing slave zones...

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