Actually it is useless to change the salt regularly. Changing the salt provides no real benefit against discovering the names in a zone which is the reason people were saying to change the salt.
The attacker uses cached NSEC3 records. When it gets a cache miss it asks the servers for the zone, puts the answer in the cache and continues. When the salt changes it just maintains multiple nsec3 chains eventually discarding the old nsec3 chain eventually. I would wait until the new NSEC3 chain has as many cached records as the old NSEC3 chain. Changing the salt slows things up miniminally for a very short period of time after the change. Additionally once you have some names you ask for those names for a non-exisisting type to quickly pull in part of the new NSEC3 chain you know exists. The only reason to change the salt is if you have a collision of the hashed names. This will be a very very very rare event. Mark In message <8661imr6cq....@strotmann.de>, Carsten Strotmann writes: > Hello Johannes, > > Johannes Kastl <m...@ojkastl.de> writes: > > > Hi everyone, > > > > I read quite a bit on DNSSEC in the last couple of weeks, and found > > that BIND can automatically rollover the ZSK without manual intervention. > > > > I also found the recommendation, to change the NSEC3 salt each time > > the key is rolled over. > > > > What I did not find is, if BIND can also automatically change the salt > > each time it does a ZSK rollover. Cos that would be quite handy... > > > > I'm not aware that BIND 9 can do a ZSK rollover all on its own, it is > however possible to set the timing values on the ZSK key files in a away > that BIND 9 will execute the rollover at the set times. It is also possible > to create a direct successor ZSK from an existing ZSK. > > But the creation of the new ZSK, as well as setting the timing values, > need to be done outside BIND 9. It is relaive strightforward to script > this in a cron job, and there are ready-made tools that can help. > > In the same cron job, it is then possible to create a new NSEC3 salt and > inject that into the zone. Doing so at the exact moment of the ZSK key > rollover (to prevent unecessary re-generation of all RRSIGs) is > tricky. > > If the zone is no too big (e.g. re-generating all RRSIGs is not a > problem), I would recommend to roll the salt in the same intervals, but > independent from the ZSK rollover. > > -- > Carsten Strotmann > Email: c...@strotmann.de > Blog: dnsworkshop.org > _______________________________________________ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ 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
