bind9 dns 的 dkim 密钥错误

Question

我在 ubuntu 20.04 上使用 postfix 配置 dkim 时遇到问题，出现以下错误：

opendkim-testkey -d example.com -s khloud -vvv
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: key loaded from /etc/opendkim/keys/example.com/khloud.private
opendkim-testkey: checking key 'khloud._domainkey.example.com'
opendkim-testkey: 'khloud._domainkey.example.com' record not found

当我使用 dig 时，我可以获得 TXT 记录：

;; ANSWER SECTION:
khloud._domainkey.example.com. 3600 IN TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCovh+yxWZIxya57mm0hITvfGXH9RjW/MfeeKjrXkChqNrjlYAfqERBjUwL4VCmceUf/bbbkKskdNQUJq9mm54qAGi4MZS6v9TectyF7mvO1uw4GcjZjiCL8r8A1jX7znRjYl6Ew3+jecMLIoUci7m/LV7xPQcxMEMPO8sNK4dluQIDAQAB"

我的 dns 区域文件上有以下 dkim 记录（我正在使用bind9在 Ubuntu 20.04 上):

khloud._domainkey.example.com.    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCovh+yxWZIxya57mm0hITvfGXH9RjW/MfeeKjrXkChqNrjlYAfqERBjUwL4VCmceUf/bbbkKskdNQUJq9mm54qAGi4MZS6v9TectyF7mvO1uw4GcjZjiCL8r8A1jX7znRjYl6Ew3+jecMLIoUci7m/LV7xPQcxMEMPO8sNK4dluQIDAQAB"

这是我的配置： /etc/opendkim.conf

# Log to syslog
Syslog          yes
# Required to use local socket with MTAs that access the socket as a non-
# privileged user (e.g. Postfix)
UMask           007

# Sign for example.com with key in /etc/dkimkeys/dkim.key using
# selector '2007' (e.g. 2007._domainkey.example.com)
Domain          example.com
KeyFile     /etc/opendkim/keys/example.com/khloud.private
Selector        khloud

# Commonly-used options; the commented-out versions show the defaults.
Canonicalization    relaxed/simple
Mode            sv
#SubDomains     no

AutoRestart         yes
AutoRestartRate     10/1M
Background          yes
DNSTimeout          5
SignatureAlgorithm  rsa-sha256

# Socket smtp://localhost
#
# ##  Socket socketspec
# ##
# ##  Names the socket where this filter should listen for milter connections
# ##  from the MTA.  Required.  Should be in one of these forms:
# ##
# ##  inet:port@address           to listen on a specific interface
# ##  inet:port                   to listen on all interfaces
# ##  local:/path/to/socket       to listen on a UNIX domain socket
#
#Socket                  inet:8892@localhost
Socket          local:/var/spool/postfix/opendkim/opendkim.sock

##  PidFile filename
###      default (none)
###
###  Name of the file where the filter should write its pid before beginning
###  normal operations.
#
PidFile               /run/opendkim/opendkim.pid


# Always oversign From (sign using actual From and a null From to prevent
# malicious signatures header fields (From and/or others) between the signer
# and the verifier.  From is oversigned by default in the Debian pacakge
# because it is often the identity key used by reputation systems and thus
# somewhat security sensitive.
OversignHeaders     From

##  ResolverConfiguration filename
##      default (none)
##
##  Specifies a configuration file to be passed to the Unbound library that
##  performs DNS queries applying the DNSSEC protocol.  See the Unbound
##  documentation at http://unbound.net for the expected content of this file.
##  The results of using this and the TrustAnchorFile setting at the same
##  time are undefined.
##  In Debian, /etc/unbound/unbound.conf is shipped as part of the Suggested
##  unbound package

# ResolverConfiguration     /etc/unbound/unbound.conf

##  TrustAnchorFile filename
##      default (none)
##
## Specifies a file from which trust anchor data should be read when doing
## DNS queries and applying the DNSSEC protocol.  See the Unbound documentation
## at http://unbound.net for the expected format of this file.

TrustAnchorFile       /usr/share/dns/root.key

##  Userid userid
###      default (none)
###
###  Change to user "userid" before starting normal operation?  May include
###  a group ID as well, separated from the userid by a colon.
#
UserID                opendkim

# Map domains in From addresses to keys used to sign messages
#KeyTable           refile:/etc/opendkim/key.table
#SigningTable       refile:/etc/opendkim/signing.table

# Hosts to ignore when verifying signatures
ExternalIgnoreList  /etc/opendkim/trusted.hosts

# A set of internal hosts whose mail should be signed
InternalHosts       /etc/opendkim/trusted.hosts

/etc/默认/opendkim

# Command-line options specified here will override the contents of
# /etc/opendkim.conf. See opendkim(8) for a complete list of options.
#DAEMON_OPTS=""
# Change to /var/spool/postfix/run/opendkim to use a Unix socket with
# postfix in a chroot:
#RUNDIR=/var/spool/postfix/run/opendkim
RUNDIR=/run/opendkim
#
# Uncomment to specify an alternate socket
# Note that setting this will override any Socket value in opendkim.conf
# default:
SOCKET="local:/var/spool/postfix/opendkim/opendkim.sock"
# listen on all interfaces on port 54321:
#SOCKET=inet:54321
# listen on loopback on port 12345:
#SOCKET=inet:12345@localhost
# listen on 192.0.2.1 on port 12345:
#SOCKET=inet:[email protected]
USER=opendkim
GROUP=opendkim
PIDFILE=$RUNDIR/$NAME.pid
EXTRAAFTER=

我添加了以下部分/etc/postfix/main.cf

# Milter configuration
milter_default_action = accept
milter_protocol = 6
smtpd_milters = local:opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters

我的密钥表文件：

khloud._domainkey.example.com     example.com:khloud:/etc/opendkim/keys/example.com/khloud.private

我的签名表文件：

*@example.com    khloud._domainkey.example.com

笔记：

1. 私钥文件归 opendkim 用户所有。
2. 密钥的大小为 1024 位。
3. 我正在使用本地 DNS（BIND9），因此传播没有问题。

Answer 1

从opendkim.conf(5)参数：

Domain（数据集）

一组域，其邮件应由此过滤器签名。来自其他域的邮件将被验证，而不是签名。

如果正在使用，则不需要此参数SigningTable；在这种情况下，签名域的列表由该文件中的行暗示。

Selector（细绳）

定义签名消息时使用的选择器的名称。有关详细信息，请参阅 DKIM 规范。仅在使用单个密钥签名时使用；有关SigningTable详细信息，请参阅下面的参数。

KeyTable如果定义了a，则忽略此参数。

在您的 opendkim.conf 中您有：

KeyTable           refile:/etc/opendkim/key.table
SigningTable       refile:/etc/opendkim/signing.table

这些与上面的单域设置相冲突。您可以注释掉这两行，也可以使用它们完成配置：

• /etc/opendkim/key.table：

  khloud._domainkey.example.com example.com:khloud:/etc/opendkim/keys/mydomain.com/khloud.private
  

• /etc/opendkim/signing.table：

  *@example.com khloud._domainkey.example.com
  

如果您计划稍后添加其他域并且希望使用单独的选择器或键，则后者更为合适。