说明
如果 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 缓存由 Pods 上的 API 监视来维护。当 Pod IP 分配更改时，Kubernetes API 会通过 API 监视向 CoreDNS 发送通知。然而，该通知并非立即发生。如果一个 Pod 被删除，并且其 IP 立即被提供给另一个名称空间中的 Pod，并且该新 Pod 在 API 监视可以将更改通知 CoreDNS 之前 进行 DNS 查找，则 autopath 将将 IP 解析为前一个 Pod 的名称空间。
在 Kubernetes 中， autopath 不兼容于从 Windows 节点中运行的 Pod。
如果服务器端搜索最终导致否定答案（例如 NXDOMAIN），那么客户端将徒劳地手动搜索所有路径，从而否定自动路径优化。