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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
