8

I'm trying to setup opendkim, but I get this result:

# opendkim-testkey  -vvvv -d my.example.com -s 201702
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key '201702._domainkey.my.example.com'
opendkim-testkey: key not secure
opendkim-testkey: key OK

That should mean DNSSEC is not working.

But according to https://dnssec-debugger.verisignlabs.com/example.com dnssec is fine.

Should I worry?

Esa Jokinen
  • 43,252
  • 2
  • 75
  • 122
Lenne
  • 917
  • 1
  • 12
  • 30
  • 1
    The TLD `dom` doesn't yet exist, so `domain.dom` wouldn't have DNSSEC. Your link doesn't state that DNSSEC is fine on `domain.dom`, rather that DNSSEC on the root zone is fine. – Torin Mar 27 '18 at 15:51
  • 3
    It is obvious that `my.domain.dom` is an example, – Lenne Oct 29 '18 at 00:41
  • 1
    And we cannot help you diagnose DNSSEC issues on a domain which isn't supplied. – Torin Oct 29 '18 at 12:18

1 Answers1

3

You have to make sure that OpenDKIM is able to use DNSSEC. key not secure in this context means that OpenDKIM was not able to verify the key using DNSSEC.

For example, you can use dig to see if it reports the AD (authentic data) flag:

$ dig yourselector._domainkey.yourdomain.org TXT +dnssec

; <<>> DiG 9.16.1-Ubuntu <<>> yourselector._domainkey.yourdomain.org TXT +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26731
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

...

The important bit here is the flag ad: it means that whatever resolver was used on the host was able to authenticate the response data with DNSSEC.

For OpenDKIM, you also must make sure that it can use DNSSEC. For example, on Debian the setting TrustAnchorFile /usr/share/dns/root.key in the default /etc/opendkim.conf provides the support for DNSSEC capabilities.

glts
  • 681
  • 4
  • 14