1

I run dkimproxy to sign outbound email and verify inbound email.

Since a while, I am experiencing the following permanent problem. The dkimproxy service is unable to query the DNS. Each and every message I receive gets the following header set (in my example I am example.org and sender example.biz)

Authentication-Results: mail.example.org; dkim=invalid (public key: DNS query timeout for api._domainkey.example.biz at /usr/lib/perl5/vendor_perl/5.18.1/Mail/DKIM/DNS.pm line 156, line 643.) header.i=@example.biz; dkim=invalid (public key: DNS query timeout for api._domainkey.example.biz at /usr/lib/perl5/vendor_perl/5.18.1/Mail/DKIM/DNS.pm line 156, line 643.) header.i=@example.biz

The error is permanent. If I log in via SSH and try to use nslookup to get the TXT record from the remote DNS I can successfully read it.

How can I fix the above problem?

[Edit] my problem doesn't fall into this known question, because in that question the DKIM check seems to be done by SpamAssassin. I check DKIM with dkimproxy

usr-local-ΕΨΗΕΛΩΝ
  • 2,359
  • 7
  • 34
  • 52
  • To clarify, this did work at one point in time? – pete Apr 05 '16 at 11:07
  • Maybe. About one year ago I migrated my mail server to a newer OS. I did test much of the stuff, in particular DKIM signing. I am not sure if I ever tested DKIM verify. I could have left that test forgotten. And I don't have any firewall rule disallowing dkim user to query DNS – usr-local-ΕΨΗΕΛΩΝ Apr 05 '16 at 12:20
  • Two thoughts: If dkimproxy or perl is being run within a chroot or jail, that could affect it determining the correct resolver to use. If you can use `tcpdump`, take a look at the dns traffic - make sure it is attempting to use the correct resolver, _on the appropriate interface_ – pete Apr 05 '16 at 23:35
  • Confirmed `dkimproxy` does **not** run in chroot or jail. Obviously it runs unprivileged using a dedicated `dkim` user. Need to confirm DNS lookup yet – usr-local-ΕΨΗΕΛΩΝ Apr 06 '16 at 06:46

1 Answers1

0

I have voted to close my own question because it already has an answer in a different QA: Azure DNS does not lookup SPF policies for certain domains

Switching /etc/resolv.conf to any other public DNS (e.g. 8.8.8.8) allows TCP querying and SPF returns to work.

usr-local-ΕΨΗΕΛΩΝ
  • 2,359
  • 7
  • 34
  • 52