對於依賴 Let’s Encrypt 進行自動化憑證管理的系統管理員與 DevOps 工程師來說，Let’s Encrypt 這次宣布推出新的 ACME 驗證挑戰類型 DNS-PERSIST-01 很重要。這項新標準有望解決長期以來 DNS-01 挑戰中較麻煩的問題，也就是必須頻繁地對 DNS 記錄進行寫入操作。
這項提案基於 IETF 的新草案，並已於 2025 年 10 月通過 CA/Browser Forum 的 SC-088v3 投票。目前 Let’s Encrypt 計畫於 2026 年第一季末在 Staging 環境部署，並預計於第二季正式上線生產環境。目前為 IETF ACME WG Internet-Draft，尚未成為正式 RFC。通過投票代表政策層面已允許，但實際安全控管仍由 CA 依內部驗證流程實作。
DNS-PERSIST-01 解決了什麼問題呢？
在 DNS-PERSIST-01 出現之前，若使用者需要申請萬用字元憑證（Wildcard Certificates）或是在不公開對外連線的內網環境中取得憑證，唯一的選擇是使用 DNS-01 驗證。
然而，DNS-01 的運作機制要求每次申請或續約憑證時，都必須在 DNS 中寫入一個一次性的隨機 Token。這帶來了兩個主要的維運挑戰，第一個是DNS 傳播延遲，每次自動化續約都需要等待 DNS 全球傳播，這在某些大型 DNS 供應商上可能耗時甚久。
再來則是資安風險，為了自動化寫入 DNS，系統管理員往往必須將 DNS 的 API 寫入權限（Credentials）部署到每一台需要憑證的 Web Server 或負載平衡器上，這大幅增加了高權限金鑰外洩的攻擊面。
DNS-PERSIST-01 如何運作？
新的 DNS-PERSIST-01 採用了一種「靜態授權」的模式。你不再需要每次都寫入新的 Token，而是只需在 DNS 中發布一次「長期有效」的 TXT 記錄，將網域的憑證簽發權限綁定到特定的 ACME 帳號（Account URI）。
官方列出的設定範例如下，若要為 example.com 啟用此功能，只需新增以下 TXT 記錄 :
Plaintext
_validation-persist.example.com，IN TXT (
“letsencrypt.org，”
” accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890″
)
一旦設定完成，該 ACME 帳號就可以在不修改 DNS 的情況下，隨時為該網域申請憑證。這對於 IoT 設備、多租戶平台（Multi-tenant platforms）以及大規模自動化部署來說，簡化了極大的維運負擔。
此外，該標準也支援，萬用字元策略，加上 policy=wildcard 即可授權 *.example.com。以及過期時間控制，可選用 persistUntil 參數設定授權的截止時間（Unix Timestamp），以降低長期授權的風險。
社群反應與潛在隱憂
在相關社群的討論中，技術社群對此功能普遍給予正面評價。許多資深工程師表示，這終於解決了內部伺服器取得公開信賴憑證的難題，也讓那些缺乏 API 支援的舊式 DNS 託管服務有了生存空間，你現在只需要手動設定一次 TXT 記錄即可。
然而，從資安方面來看，也是有一些值得注意的隱憂。
首先是可能的隱私洩漏，由於 TXT 記錄是公開的，且其中包含了 ACME 的 accounturi，這意味著任何人（包括攻擊者或 Shodan 等掃描服務）都可以透過反向查詢，找出哪些網域屬於同一個 ACME 帳號，這可能會暴露企業的基礎設施關聯圖。
DNS-PERSIST-01 的安全關鍵在於撤銷是否簡單且即時。若要撤銷授權，只需刪除 TXT 記錄或設定 persistUntil 到期即可。但實際上 DNS TTL 仍會造成撤銷延遲，這是殘餘風險。
CyberQ 建議，若介意隱私，建議為不同的專案或客戶使用不同的 ACME 帳號，甚至考慮每個網域使用獨立帳號（透過 Docker 或自動化腳本生成）。
其次則是安全重心的轉移，過去 DNS-01 的風險在於 DNS API Key 的分散，現在 DNS-PERSIST-01 則將風險集中到了 ACME Account Key 上。一旦這個帳號金鑰被竊取，攻擊者就能為所有綁定該帳號的網域簽發憑證，而無需攻破 DNS 系統。因此，保護 ACME 帳號金鑰（Account Key）將成為新的資安防護重點。
若使用 policy=wildcard，等於把整個 zone 的簽發權交給同一個 ACME 帳號。對大型企業而言，這會影響內部子網域分權模型。CyberQ 不建議目前在多 BU 或多團隊共用的 zone 上使用全域 wildcard policy，可能要等待實際上線後，有更適當的機制來處理這部分的實作。
憑證自動化更簡單，但 ACME 帳號金鑰成為新單點風險
CyberQ 認為，DNS-PERSIST-01 的推出可說是 ACME 協議的一次重要演進，它用帳號授權的概念取代了單次挑戰，在安全性與便利性之間找到了新的平衡。不過呢，也會有想到萬一未來企業域名轉移 ownership 後，如果舊 TXT 未移除會發生什麼？我們需要在域名轉移時，將 DNS-PERSIST-01 記錄列入 M&A 或域名交接流程的清查清單。
對於正在維護複雜憑證自動化流程的團隊來說，現在正是重新評估架構的好時機。隨著 2026 年 Q2 正式上線的接近，建議開始測試 Pebble 中的實作，並思考如何妥善管理 ACME 帳號金鑰，為不同產品線建立獨立 ACME account key，將 account key 存放於 HSM 或至少使用 encrypted key storage，以及實作 key rotation policy，我們今年可以有機會進行更流暢的自動化 DNS 部署。
首圖由 Nano Banana AI 生成
