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
_______________________________________________
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
