do not stupidly delete ZSK files

[Heiko Richter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 07.08.2015 um 01:55 schrieb 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...

Modern keys are all NSEC3-aware. Everything that came after RSASHA1
has NSEC3-support. It is automatically enabled as soon as you publish
NSEC3-parameters in your zone.

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

You always have to look at the complete trust-chain from root to you.
The trust of your records can only be as high as the weekest algorithm
used in the entire chain allows.

Root is signed with RSASHA256 at the moment. There is no sence in
having a more secure algorithm because anybody who can't crack that
algorithm may just attack the weakest link in the chain above you.

Also you have to keep in mind that resolvers have to be able to verify
your signatures. I used ECDSA in the beginning, but then notices that
by far not every dnssec-enabled resolver is able to verify those
signatures, so I changed back to RSASHA256 as this is the minimum any
resolver needs to know in order to verify root.

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

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

You don't need to manually sync your servers. Just aktivate NOTIFY and
your master will inform all slaves of any zone changes. If you also
activate IXFR-Transfers, the slaves will only transfer the records
that have changes; there's no need to transfer the whole zone.
Combined with inline-signing your updates will propagate to all
servers within a second.

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

It's just a matter of lowering your ttl. Resolvers all over the world
will cache your records according to your ttl. If you really have
86400 set as ttl, any given record will be queried only once per day.

Just lower the default ttl to a resonable number and your updates will
propagate faster to the resolvers. It's just a question of how much
bandwidth and resources are you willing/able to give to DNS? Lower it
step-by-step until either hit the limit in your bandwidth or the
system-resources of your servers.

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

If they have full control of their subdomain, why don't they just
change the ttl themselves?

Setting a ttl of 1 day seems a bit high, but of course it always
depends on your zone. If the data is static, 1 day is find, but for
dynamic zones this is a but high.

When you use inline-signing, your updates will be signed on-the-fly,
as they come in, so you can lower the ttl to a few minutes without any
problems. This helps much in keeping outdated data out of any
resolver's cache.

> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJVw/scAAoJECKEz6pWghImV2IP/jHrDhf82UsafnCdVbH8ppRB
ShQTIQ4gCi40WLTGoahv8qRYyaRbcOiLTw4JStc92UcbKOEaHJwGFg1dy369flVh
KJ2eGa5t8UFMUJNMYTL9G32+HWv07xVKXHzbTBp9FvEhSzhOE31dI+7/5m2l6doG
z4mEGbhuKqJxvagcEND137uSmzJX11QUXMBD9lPJRSNYUzI7e1aA/zjlJAs/BlpX
iD8iJ3V3oKF4eKBuceM5x9Gco6z1VAAKM58yJERyrSkoUYzD2lrmOZCRddUKduJ2
zI5roCsxaa3W8/z6Qr9VWHUe/l+czUZcYBWkzQfwWKgMBFzxrjxRc2s205ansGMp
Py2MXYTNmBlxI0Ga5RFNaVCLbhri3b+oQMkZK6ADj4zJJEj54P+lRm5yRb9NECdP
oV8E4sLiBi0tqvd2KG2d1Xzfw2aQsq6LIyBDDoGWhXGiaKP0ZZQQ2sRu/cmQLwva
SrrAw8tgkS8GkpvDPphC8NhwRdbiuheN4pQG5bVx3Yk2y1nOJAzKcqgrCo88RA5q
4spOLnBbLrESNjXzLXiWh97Y0wcN2Di/XwTUu4SxtrnyDeZiyFeJgVgHjUKgoGzy
QZUhgfElaSf87NPgPhbMh15FKLv3qCnJSz7GLrdFhe8xeVscGXnoHgVJl2QwftOa
zzDqAt7Y87byg83fimoM
=6Hal
-----END PGP SIGNATURE-----