Score:1

OpenDKIM on Fedora Server, opendkim-testkey loads the key, says it's checking it, then just says "query failed" How do I find (and fix) what's wrong?

ru flag

On Fedora Server 37 (updated as of about February 1, 2023), a new OpenDKIM installation was performed (it's version v2.11.0). The configuration included creating a signing table and a key table, and creation of a key, as well as publishing it in DNS. So far, so good...

I got to the point where you test it via opendkim-testkey and this failed.

The first time I ran it it complained "unsafe permissions", though that didn't stop it, however, I focused on that for a bit; NOTHING I did - changing ownerships and permissions in a half dozen or more permutations - made that error go away, so to heck with it for now!

I recognized that there must have been an error in the signing table, so I made a subtle change. ...It apparently demands to use "_domainkey", even though the official documentation doesn't say that's required and it seems purely unnecessary for it to do so, but apparently that's required. And I think so because when I comported with the seemingly silly addition of this "_domainkey" text to the entry in the signing table, it got further along, at least now saying it's loading the correct keyfile. Yet, I still get the "query failed" error.

To be clear, the session goes like this:

opendkim-testkey -d some-fqdn.com -s default -vvvvvvv
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: /etc/opendkim/keys/some-fqdn.com/<prefix>.private: WARNING: unsafe permissions
opendkim-testkey: key loaded from /etc/opendkim/keys/some-fqdn.com/<prefix>.private
opendkim-testkey: checking key 'default._domainkey.some-fqdn.com'
opendkim-testkey: 'default._domainkey.some-fqdn.com' query failed

Well, thanks for the clue, opendkim-testkey!

I got nothing helpful from systemctl status opendkim.service - it says it's status is "active (running)" with no errors. So, I checked the log (in this case /var/log/messages), and there were some entries. So, to be sure they're current, I cycled opendkim with systemctl reload while grepping on a tail -f command and got:

Mar  5 11:17:21 fs1 systemd[1]: Started opendkim.service - DomainKeys Identified Mail (DKIM) Milter.
Mar  5 11:17:21 fs1 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=opendkim comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar  5 11:17:22 fs1 abrt-notification[3173323]: Process 348313 (opendkim) crashed in _nl_load_domain.cold()

WHOAH! Crashed? Why does it say it's up and running then?! Strange!

Some investigation shows that _nl_load_domain.cold() is in fact a C++ function.

The function definition begins:

internal_function
_nl_find_domain (const char *dirname, char *locale,
         const char *domainname, struct binding *domainbinding)
{
  struct loaded_l10nfile *retval;
  const char *language;
  const char *modifier;
  const char *territory;
  const char *codeset;
  const char *normalized_codeset;
  const char *alias_value;
  int mask;

That's enough to make this guy go: "Hmmm... what now?!"

(Note that the domain in question is working just fine - except for opendkim! - with a fairly robust DNS zone that's live, AND, the system in question has full access to DNS queries.)

NOTE OpenDKIM is validating inbound email DKIM keys just fine! I just need to get the signing part working, too!

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.