Key rotation in a live system is problematic: as soon as you update config/dkim.key, that key is used to sign outgoing email, despite the fact that you’ve not had time to run sympl-dns-generate to generate an updated TXT record, let alone time to apply the update and wait for the TTL on the existing TXT record to expire.
It would be nice if Sympl supported a pair of DKIM selectors and key files, so that the key associated with the non-active selector could be updated separately, allowing time for the DNS change to propagate before switching to make the updated selector active for signing.
It gets my vote. At the moment, it’s a bit of a manual faff, whether migrating servers or rotating keys for better security. (For the former, I set dual dkim records by dropping *.txt in config/dns and letting OctoDNS do its thing).
Going for gold, https://www.m3aawg.org/DKIMKeyRotation (.pdf) suggests using three ‘active’ sets; current, future – and past.
Example of Key 2 → 3 :
dkim1._domainkey.example.com ← public key 1 is retired [“p=”]
dkim2._domainkey.example.com ← public key 2 used to validate old email for 7-30 days
dkim3._domainkey.example.com ← public key 3 used to sign current and new email
dkim4._domainkey.example.com ← public key 4 ready for future use
- retired public keys are set empty in dns, seemingly, permanently. (Infinity seems overkill here; I’d prefer to kill the record at some point).
- selectors/key pairs are unique, i.e., no recycling of selectors
When sympl supports dns integration I can’t see why a fully-fledged rollover scheme wouldn’t be feasible and desirable. All the admin needs to do is create
It seems that the tinydns files support timestamps – that could be useful to set a self-destruct on creation (setting ‘p’ empty in, say, expiry+10 days).
This seems like a very useful feature - bringing the DNS integration back up to date is the next big step for Sympl, and adding support for rotating DKIM keys should be reasonably easy to add when I do.
Added to the feature list!
Hi. I can’t use the DNS integration. In some cases, the DNS is outside of my control. If example.com was such a domain, then I’d ask the owner of example.com to add CNAME records so that I can manage services on their behalf. With DKIM, this means a one-off request to add CNAME records for s1._domainkey.example.com and s2._domainkey.example.com. I then manage the actual keys through the domain the CNAME records point to. So I don’t want to have to add new selectors over time; I’d rather just bounce between s1 and s2 periodically. It would be great if this scenario could be taking into consideration when implementing support for DKIM key rotation.