PowerDNS Recursor 5.5.0 的第一支 alpha 版本在 2026 年 8 月 13 日發布。這一輪的更新量不像 5.0 把設定檔切換到 YAML 那麼大，但幾項改動實務上很關鍵：outbound DNS-over-TLS 連線可以帶 client certificate 做認證、RPZ 更新改成預設清掉 packet cache、named interface 能用來指名來源位址，再加上 5.4 系列推動的 DNS cookies 持續收 operator 回饋，整體方向明顯往「遞迴解析器要像上游服務一樣可被稽核」靠。
跑遞迴解析器這件事長期以來分兩派：一派直接接 ISP 給的位址或 Cloudflare、Quad9 這類公開服務，另一派在機房或 VPS 上自己跑一臺 Unbound、BIND 或 PowerDNS Recursor。自家跑的理由不外乎 cache 命中率可控、DNSSEC 驗證邏輯透明、RPZ 可以塞自家黑名單，近兩年多了一條：outbound 加密不想交給別人。PowerDNS Recursor 5.4 到 5.5 這一路，把這條路線上的工具補得差不多齊了。
outbound DoT 現在能帶 client cert 走雙向認證
5.4 版加了 outbound DoT 的 server 憑證驗證選項，操作面是在轉發設定裡指定 subjectName 跟 caStore，讓 recursor 在跟上游授權伺服器或 forwarder 建立 TLS 連線時真的檢查對方憑證，而不是像早期版本那樣只開 TLS 不驗證。到了 5.5 alpha，這條路徑再往上補一層：outbound DoT 連線可以攜帶 client certificate 跟 private key，用來證明自己身分給上游。
這個設計主要給兩種場景用。一種是企業內部多層遞迴架構，上游 forwarder 設定成只接受憑證認證過的 recursor 查詢，整條鏈路都走 mutual TLS。另一種是跟授權伺服器直連的場景，部分安全性要求高的 TLD 或私有 zone 開始要求 client cert 做身分綁定。沒有這個能力之前，遞迴解析器只能用 IP ACL 做身分識別，一旦前面有 NAT 或 proxy 就擋不住。
設定方式延續 5.4 的 forward-zones-recurse YAML 寫法，subjectName、caStore、certFile、keyFile 這幾個欄位組合起來。要注意的是 TLS 握手成本仍然在，每個 forwarder 建議開 outgoing-tcp-threads 跟 connection pool，不然單一熱 zone 的尾延遲會明顯被 TLS 建連時間拉高。
DNS cookies 不是新東西，但這一輪才被正式推進預設
RFC 7873 定義 DNS cookies 已經是 2016 年的事，RFC 9018 補完 server cookie 的 anycast 兼容細節也是 2021 年。Unbound 1.18 在 2023 年補上 downstream 的 answer-cookie 支援，BIND 更早就有。PowerDNS Recursor 走得比較慢，直到 5.4 才把 outbound 到授權伺服器方向的 DNS cookies 支援補齊，而且預設關閉。
5.5 alpha 的發佈公告直接點名「希望收到 DNS cookies 的 operator 回饋」，意思很清楚：這個開關正在評估改成預設開。對第一線 operator 來說值得測試的點有兩個：一是上游授權伺服器實作完成度不一，部分舊版 BIND 或非主流 authoritative server 遇到帶 cookie 的查詢行為會比較怪，需要 recursor 這邊能自動退化不帶 cookie 重試；二是 cookie secret 的輪替策略會影響上游 cache 命中，PowerDNS 的實作在這塊有單獨旋鈕。
從防禦角度看，DNS cookies 真正有效的是對抗 off-path 的 spoofing 跟 reflection attack，對應付 cache poisoning 跟 DDoS 反射都有實質效果。不開這個等於放著現成的降級選項不用，直接升到 5.4 或等 5.5 GA 時建議把 outgoing-cookies 打開。
RPZ 更新預設清 packet cache 是遲到的修正
RPZ（Response Policy Zone）在 enterprise 跟 ISP 側用得很多，常見場景是餵一條 threat intel feed 進來，recursor 自動擋 malware 用的 C2 domain。老問題是 PowerDNS Recursor 的 packet cache 跟 record cache 是分開跑的，RPZ 更新進來時只會失效 record cache，packet cache 裡面已經組好的回應封包要等 TTL 到期才會被換掉。
這代表 RPZ 剛推一條新規則進來後，一段時間內繼續有使用者拿到被加黑名單之前的 cached 回應。多數人碰到這個行為會手動呼叫 rec_control wipe-packet-cache，但這個步驟很容易漏做。5.5 alpha 把預設行為反過來，RPZ update 進來時相關 entry 在 packet cache 裡自動被清。
這條改動乍看很小，實務上是對 RPZ 這類安全動態規則有依賴的環境，封鎖生效的平均延遲從幾分鐘降到幾秒。要降回舊行為可以用設定關掉，但沒有理由要關。
named interface 跟 PKCS12 這些是運維面的掃尾
named interface 支援出現在 outgoing 設定裡，意思是來源位址可以寫 interface 名稱而不是 IP。這對 VPS 上做 IPv6 PA 位址輪替、或者機器上同時掛多條 WAN 的場景很有用，過去綁 IP 一旦網路介面重拉就要改設定，寫 interface 名稱就穩定了。多 WAN 做 outbound load balancing 的寫法也乾淨不少。
web interface 的 TLS 設定能讀加密的 PKCS12（pfx）檔案，意思是運維可以把憑證加密存放在設定目錄裡，開機時由 systemd credential 或 ansible-vault 之類的機制提供密碼。這在合規要求比較高的環境裡省掉一層 secret 管理層的實作。
Protobuf logging 加了 4 byte framing format 跟多目標發送策略，這條對接 pdns-ee、dnstap 之類 downstream 分析工具的環境影響最大，老的 2 byte framing 在高 QPS 下會對不準長度欄位，4 byte 直接把這個邊界拉開。
哪些場景該立刻跳上 5.5
從 5.3 以下直接升 5.4 的理由已經很明確：outbound DoT 的 server 驗證、OpenTelemetry trace 更細緻、EDE 選項更完整。5.5 alpha 現在還不建議上 production，但有兩種環境值得開一臺 VPS 把 alpha 跑起來先測：對 outbound DoT mutual TLS 有需求的多層遞迴架構，以及重度用 RPZ 的環境。這兩類在 alpha 版本就能先把設定寫到位，等 5.5 GA 直接換二進位檔即可。
跟 Unbound 的對照還是維持原本的分野。Unbound 在 downstream 加密（DoT、DoH over client-side）的工具鏈成熟度仍然略高，PowerDNS Recursor 的強項在 scripting hook 跟 RPZ 處理深度，加上 YAML 設定後複雜環境可讀性好。單純要「小而輕」仍然選 Unbound，環境裡有 RPZ、Lua 腳本、重度 observability 需求的，PowerDNS Recursor 5.5 這一輪升級給的空間比較大。
自己開一臺 VPS 把 5.5 alpha 跑起來
PowerDNS 官方的 apt repository 在 Debian 13 Trixie 跟 Ubuntu 24.04 上已經提供 alpha 套件，meson 建置路徑也走得差不多了。測 alpha 版本最乾淨的做法是開一臺乾淨 VPS，從官方 apt 裝 pdns-recursor，YAML 設定檔直接寫 forward-zones-recurse 掛兩條 outbound DoT forwarder，壓測工具用 dnsperf 餵真實 query log，再對照 pdnsutil 跟 Prometheus exporter 的指標調 max-cache-entries、max-packetcache-entries。
NCSE Network 提供的 VPS 跑在臺灣是方電訊機房、Intel Gold CPU 加 NVMe SSD，Debian 13、Ubuntu 26.04 等映像檔開機即用，kernel 6.x 全系列在 io_uring 跟 systemd credential 面支援完整，拿來跑 PowerDNS Recursor 這類對網路延遲跟 CPU cache 效率敏感的服務很合適。想了解相關方案細節，可以到 ncse.tw 查看。
