RE: General OpenDKIM setup questions

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Thu, 3 May 2012 19:53:49 +0000

> -----Original Message-----
> From: opendkim-users-bounce_at_lists.opendkim.org [mailto:opendkim-users-bounce_at_lists.opendkim.org] On Behalf Of Quanah Gibson-Mount
> Sent: Thursday, May 03, 2012 12:47 PM
> To: opendkim-users_at_lists.opendkim.org
> Subject: General OpenDKIM setup questions
>
> Update leads me to the following questions:
>
> Is there ever a time someone would want to re-generate the keys for a
> domain? If they do, should they use the same Selector as they had
> previously, or should they use a new one?

You would regenerate keys subject to a key rotation policy of some kind. But the theory is "never re-use selectors", so you might name your keys "quanah2012" and such, for example.

> Remove removes the DKIM data for the domain from LDAP. However, is
> that valid? What kind of trouble may ensue if that occurs? ;)

Depends on the impact from the OpenDKIM perspective. If you do something that basically means the SigningTable query comes back with "not found", then that domain's mail won't be signed anymore. That's probably what you want. If you only cause KeyTable for that domain to come back empty, you might get SigningTable errors.

> Also, this following will come in a separate email once our new mtas
> have their firewall rules updated, but that may take a few days, so:
>
> Is there any reason not to use a guaranteed UUID for the SELECTOR with
> dkim, something like:
>
> 9d624885-08e6-4ebf-bc0f-532b0d9f4060
>
> I ask because we have clients that literally have hundreds or thousands
> of domains. Having them try and pick a selector for each domain,
> rather than generating it programmatically with a UUID seems like it
> would be a major headache to manage.

I imagine you should give them the choice, but something transparent like that is likely fine. As long as that fits inside a DNS label, and the total DNS query name length doesn't exceed the maximum, nothing should squawk.

-MSK
Received on Thu May 03 2012 - 19:54:04 PST