自动化证书管理中 systemd-resolved 的隐藏危险
SSL/TLS 证书的自动化已经从根本上改变了我们保护 Web 安全的方式。像 Caddy 和 Let's Encrypt 这样的工具使得获取和更新证书的过程变得无缝衔接，通常在后台运行而无需任何人工干预。然而，这种无缝性创造了一种依赖：自动化流水线依赖于健康、可预测的 DNS 解析过程。当该过程发生选择性故障时，可能会导致灾难性的失败，这些失败不仅难以察觉，而且通常难以调试。
故障模式：选择性 DNS 中断
在 Caddy 服务器证书过期的场景中，根本原因被追溯到 systemd-resolved，这是一个为本地应用程序提供网络名称解析的系统服务。故障并非完全中断——如果是完全中断，监控告警会立即触发——而是一种选择性中断。
选择性中断特别危险，因为它会让系统的其余部分看起来很健康。服务器可能能够 ping 通外部 IP，其他服务可能能够解析某些域名，而基础连通性检查可能会通过。然而，ACME (Automated Certificate Management Environment) 挑战所需的特定 DNS 查询却失败了——这是证书颁发机构 (CA) 验证域名所有权的过程。如果 ACME 客户端无法解析 CA 的 API 端点，或者 CA 无法解析服务器的域名，续订过程就会在后台静默失败。
技术深挖：systemd-resolved 冲突
systemd-resolved 中一个常见的故障点涉及服务器的主机名。有一个已知问题：如果服务器的主机名与请求的域名完全相同，解析可能会失败或表现异常。
为了缓解这个特定的 bug，一些管理员建议使用覆盖配置来禁用服务器尝试合成主机名的行为：
Environment=SYSTEMD_RESOLVED_SYNTHESIZE_HOSTNAME=0
通过在 /etc/systemd/system/systemd-resolved.service.d/override.conf 中添加此项到服务覆盖配置中，管理员可以防止 systemd-resolved 尝试将服务器自身的名字解析为本地地址，这可能会干扰 ACME 挑战过程。
网络辩论：systemd vs. 专业工具
这次事件凸显了系统管理社区内关于 systemd 在网络栈中扮演角色的更广泛辩论。虽然 systemd 旨在提供一套全面的系统管理工具，但有人认为其范围已经扩展到了需要专业网络知识的领域。
一些经验丰富的网络专业人员认为，在服务器上应避免使用 systemd-resolved 和 systemd-networkd，转而使用更专业、更健壮的工具。例如，通常建议在服务器上本地安装 unbound 用于 DNS 解析。与 systemd-resolved 不同，unbound 是专门设计作为验证型、递归式、缓存型 DNS 解析器，在高度稳定的环境中提供更可预测的行为。
给现代管理员的教训
为了防止“静默”证书过期，管理员应考虑以下策略：
- 实施端到端监控：不要仅仅依赖于服务进程的健康状况。监控面向公众提供的证书的实际过期日期。检查 SSL 证书剩余有效期的外部监控工具可以在证书过期前很久就向你发出告警。
- 审计 DNS 配置：确保你的 DNS 解析策略是一致的。如果正在使用
systemd-resolved，请注意主机名与域名之间潜在的冲突。 - 评估网络栈：对于稳定性至关重要的服务器，评估
systemd提供的工具是否足够，或者像unbound这样更专业的工具是否更适合该环境。