Automated Certificate Management 中的 systemd-resolved 隱藏危險
SSL/TLS 憑證的自動化從根本上改變了我們保護網路安全的方式。像 Caddy 和 Let's Encrypt 這樣的工具讓取得與更新憑證的過程變得無縫，通常在背景中運行，無需任何人工干預。然而，這種無縫性創造了一種依賴：自動化流程依賴於健康且可預測的 DNS 解析過程。當該過程發生選擇性失效時，可能會導致災難性的失敗，這不僅難以察覺，而且通常很難進行除錯。
失效模式：選擇性 DNS 中斷
在一個 Caddy 伺服器憑證過期的情境中，根本原因可以追溯到 systemd-resolved，這是一個為本地應用程式提供網路名稱解析的系統服務。這次失效並非完全斷網——這會立即觸發監控警報——而是一種選擇性的中斷。
選擇性中斷特別危險，因為它會讓系統的其他部分看起來很健康。伺服器可能可以 ping 外部 IP，其他服務可能可以解析某些網域，而基本的連線檢查也可能通過。然而，用於 ACME (Automated Certificate Management Environment) 挑戰——憑證授權單位 (CA) 驗證網域所有權的過程——所需的特定 DNS 查詢卻失敗了。如果 ACME 用戶端無法解析 CA 的 API 端點，或者 CA 無法解析伺服器的網域，更新流程就會在背景中靜默失效。
技術深挖：systemd-resolved 的衝突
systemd-resolved 中一個常見的失效點涉及伺服器的 hostname。已知有一個問題，如果伺服器的 hostname 與被請求的網域完全相同，解析可能會失敗或出現非預期的行為。
為了緩解這個特定的 bug，一些管理員建議使用覆蓋配置來禁用伺服器嘗試合成 hostname 的行為：
Environment=SYSTEMD_RESOLVED_SYNTHESIZE_HOSTNAME=0
透過在 /etc/systemd/system/systemd-resolved.service.d/override.conf 中添加此內容到服務覆蓋配置中，管理員可以防止 systemd-resolved 嘗試將伺服器自身的名稱解析為本地地址，這可能會干擾 ACME 挑戰流程。
網路通訊辯論：systemd vs. Specialized Tools
這次事件凸顯了系統管理社群中關於 systemd 在網路堆疊中的角色所進行的更廣泛辯論。雖然 systemd 旨在提供一套完整的工具來管理系統，但有人認為其範圍已經擴展到了需要專業網路知識的領域。
一些經驗豐富的網路專業人士認為，在伺服器上應避免使用 systemd-resolved 和 systemd-networkd，而應改用更專業、更強大的工具。例如，對於伺服器，通常建議使用本地安裝的 unbound 來進行 DNS 解析。與 systemd-resolved 不同，unbound 是專門設計作為驗證式、遞迴式、快取式 DNS 解析器，在高度穩定的環境中提供更可預測的行為。
給現代管理員的教訓
為了防止「靜默」憑證過期，管理員應考慮以下策略：
- 實施端到端監控：不要僅依賴服務進程的健康狀態。監控向公眾提供的憑證實際到期日期。檢查 SSL 憑證剩餘有效期的外部監控工具可以在憑證過期前很久就向您發出警報。
- 審核 DNS 配置：確保您的 DNS 解析策略是一致的的。如果您使用
systemd-resolved而要留意 hostname 與網域之間的潛在衝突。 - 評估網路堆疊：對於穩定性至關重要的伺服器，請評估
systemd探索提供的工具是否足夠，或者像unbound這樣更專業的工具是否更適合該環境。