これは、期待通りにデバッグするのに時間がかかったものです

設定

systemdベースのLinuxマシン上でCaddyをリバースプロキシとして実行しています。ACMEを通じて証明書の更新を行っています。ログには何も問題がないように見えます。しかし、ある日証明書が有効期限切れになり、2日間誰も気づかなかったのです

原因

systemd-resolvedは、上流のリゾルバーの状況によって特定のDNSクエリに対してSERVFAILを返す動作があります。一貫性がありません。いくつかのゾーンは正常に解決しますが、いくつかは静かに失敗します。CaddyのACMEクライアントが挑戦リクエストを送信し、systemd-resolvedは失敗を報告し、そして更新がただ起こりません...

これが面倒なのは、systemd-resolve --statusに何も問題がないように見えるからです。dig は 8.8.8.8 に対してうまくいくかもしれません。スタブリゾルバーがあなたのアプリケーションに対して嘘をついており、それをどこか役立つ場所に記録していない

。 修正策

それを処理する三つの方法：

1. スタブリゾルバーをバイパスする

Caddy（またはGoのnetスタック全体）を直接公共のリゾルバーにポイント。あなたのCaddyfile:

{
  servers :443 {
    dns resolver 1.1.1.1
  }
}

またはGODEBUG=netdns=goを設定して、システムリゾルバーの設定ではなくGoリゾルバーを強制します

2. systemd-resolvedを再起動します

systemctl restart systemd-resolvedは、蓄積した破損状態をクリアします。これは一時的な解決策です — また同じ問題に直面する可能性があります

より永続的な解決策として、/etc/resolv.confを確認し、すべてのことをスタブリゾルバーに依存していないことを確認してください

3. DNS-over-HTTPSを使用します

解決済みのままでも、より頑健にするには、平文UDPの代わりにDoH上流を使用するように設定します。SERVFAILのケースを解決しませんが、MITM問題のクラスを回避します.

知っておくべき症状

具体的な症状：Caddyのログには更新が失敗したと記録されますが、明確な理由は示しません。caddy list は証明書がすぐに有効期限切れになると表示します。他のすべては正常に動作しています。ブラウザは証明書の有効期限切れの警告をキャッシュするので、ユーザーは苦情を止める——そして月曜日の朝にあなたの問題になります.

まとめ

Caddyをsystemd-resolvedで実行していて、証明書が予期せず有効期限切れになっている場合、他の何かを確認する前にスタブリゾルバーを確認してください。DNSが動作しているという理由で、この種の失敗は明らかに見え隠れしているタイプです。

スポンサーではありません。ただ、午後を無駄に費やしただけのものです。