> * Esteban L.:
>> Trying to figure this out with as little disruption as possible.
> I sugest you do the following, in order:
> * Generate new key.
> * Add new key's data, using a new DKIM selector, to your DNS.
> * Wait for your domain zone's DNS TTL to expire (typically 1-2 days).
Yes that is the way. One detail here.
In case DNS does not use notify then yes you should wait for the zone
refresh time in SOA (not TTL) for all slaves to sync. Just about any DNS
now days uses notify and the new DKIM selector should be available
within seconds after the zone reload in all authoritative domain
servers, if all set correctly and you could use your new key almost
immediately, if you control the reload time. In any case, you can easily
and should verify that with a dig or an nslookup.
> * Switch to signing with the new key.
> * Wait another 1-2 days, in case messages signed with the previous key
> are still in limbo somewhere (low risk of that, but still).
> * Remove old key's data from DNS.
> As long as you make sure to use a different DKIM selector for each key,
> that should suffice for a key rollover.
> In case DNS does not use notify then yes you should wait for the zone
> refresh time in SOA (not TTL) for all slaves to sync.
I recommended the zone's TTL because it is the upper limit for all
cached data to disappear, but yes, data newly added to the zone should
usually be available sooner. My own DNS pair will deliver additions
within seconds after I make the change, but I don't quite trust every
caching resolver out there and rather wait an extra day.
On 23/6/2019 23:25, Ralph Seichter wrote:
> * Lefteris Tsintjelis:
>> In case DNS does not use notify then yes you should wait for the zone
>> refresh time in SOA (not TTL) for all slaves to sync.
> I recommended the zone's TTL because it is the upper limit for all
> cached data to disappear
There is nothing to disappear from cache for the new key. This is a new
selector so all is needed is for all DNS servers to be in sync (notify
takes care of that) and that is all. You may start using it.
> There is nothing to disappear from cache for the new key.
Lefteris, I am fully aware. As I wrote, I don't trust every caching
resolver out there to do the right thing (meaning to query for new
information while older data is still in the cache). It should happen,
but I rather wait an extra day. You may of course make your own choice,
it makes no difference to me.