描述
如果 autopath 外掛程式看到一個查詢與已設定搜尋路徑的第一個元素匹配，它會追蹤搜尋路徑元素的鏈，並返回第一個不是 NXDOMAIN 的回覆。若有任何失敗，則會返回原始的回覆。由於 autopath 會針對一個非原始問題的名稱返回回覆，因此它會加入一個 CNAME，將原始名稱（包含搜尋路徑元素）指向此答案的名稱。
注意：有一些已知問題，請參閱下方的「錯誤」章節。
語法
autopath [ZONE...] RESOLV-CONF
- ZONES autopath 應該作為授權的區域。
- RESOLV-CONF 指向一個類似
resolv.conf的檔案，或是使用特殊的語法指向另一個外掛程式。例如，@kubernetes將會呼叫 kubernetes 外掛程式（針對每個查詢）來檢索它應該使用的搜尋列表。
如果外掛程式實作了 AutoPather 介面，那麼它就可以被 autopath 使用。
指標
如果啟用了監控（透過 prometheus 外掛程式），則會匯出以下指標
coredns_autopath_success_total{server}- 成功自動路徑化的查詢計數器。
server 標籤在 metrics 外掛程式文件中說明。
範例
autopath my-resolv.conf
使用 my-resolv.conf 作為檔案來取得搜尋路徑。此檔案只需要有一行：search domain1 domain2 ...
autopath @kubernetes
使用從 kubernetes 外掛程式動態檢索的搜尋路徑。
錯誤
在 Kubernetes 中，在以下情況下，autopath 可能會導出客戶端 Pod 的錯誤命名空間（以及因此錯誤的搜尋路徑）。為了正確建構客戶端的搜尋路徑，autopath 需要知道發出 DNS 請求的 Pod 的命名空間。為此，它依賴 kubernetes 外掛程式的 Pod 快取來將客戶端的 IP 位址解析為 Pod。Pod 快取由對 Pod 的 API 觀察維護。當 Pod IP 指派變更時，Kubernetes API 會透過 API 觀察通知 CoreDNS。但是，該通知不是即時的。如果刪除一個 Pod，並且它的 IP 立即配置給另一個命名空間中的 Pod，並且新的 Pod 在 API 觀察可以通知 CoreDNS 變更之前發出 DNS 查詢，那麼 autopath 將會把 IP 解析為先前 Pod 的命名空間。
在 Kubernetes 中，autopath 與從 Windows 節點執行的 Pod 不相容。
如果伺服器端搜尋最終導致否定答案（例如 NXDOMAIN），那麼客戶端將會徒勞地手動搜尋所有路徑，從而抵消 autopath 的最佳化。