dkim updating keys

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

dkim updating keys

Drexl Spivey
Friendly Greetings,

I am going to update my email server's Dkim keys for the first time.

I can go to the original install instructions, and figure out how to
update them. What I can't find in that original tutorial is the
following:

1. Do I delete/remove old key and references thereto? Namely, in the
key.table?

2. Do I just create the new key, and update the key.table, and upload
the txt to my DNS?

3. Do I leave my old key information (including on the DNS) for a
"grace period" of a week or so?

Trying to figure this out with as little disruption as possible.

Thanks in advance.

Esteban



--
https://little-beak.com
"Doing what we can."
Reply | Threaded
Open this post in threaded view
|

Re: dkim updating keys

Ralph Seichter-2
* 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).

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

-Ralph
Reply | Threaded
Open this post in threaded view
|

Re: dkim updating keys

Drexl Spivey
Thanks Ralph.

That was the step-by-step guide I was looking for. The simplest things
are always the hardest to find information for.

Esteban
--
https://little-beak.com
"Doing what we can."

-----Original Message-----
From: Ralph Seichter <[hidden email]>
To: [hidden email]
Subject: Re: dkim updating keys
Date: Sun, 23 Jun 2019 15:20:42 +0200

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

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

-Ralph

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dkim updating keys

Lefteris Tsintjelis
In reply to this post by Ralph Seichter-2
On 23/6/2019 16:20, Ralph Seichter wrote:

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

Lefteris

> * 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.
>
> -Ralph
Reply | Threaded
Open this post in threaded view
|

Re: dkim updating keys

Ralph Seichter-2
* 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, 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.

-Ralph
Reply | Threaded
Open this post in threaded view
|

Re: dkim updating keys

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

Lefteris
Reply | Threaded
Open this post in threaded view
|

Re: dkim updating keys

Ralph Seichter-2
* Lefteris Tsintjelis:

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

-Ralph