説明
オートパスプラグインは、設定済みの検索パスの最初の要素と一致するクエリを見ると、検索パス要素の連鎖をたどり、NXDOMAIN以外の最初の応答を返します。エラーが発生すると、元の応答が返されます。オートパスは、元の質問とは異なる名前の応答を返すため、元の名前（検索パス要素を含む）からこの応答の名前をポイントするCNAMEが追加されます。
注意: 既知の問題がいくつかあります。以下の「バグ」セクションを参照してください。
構文
autopath [ZONE...] RESOLV-CONF
- ZONES オートパスが権威を持つ必要があるゾーン。
- RESOLV-CONF は
resolv.confのようなファイルをポイントするか、別のプラグインをポイントするための特別な構文を使用します。たとえば、@kubernetesは、使用する検索一覧を取得するために、（各クエリに対して）kubernetesプラグインを呼び出します。
プラグインがAutoPatherインターフェイスを実装している場合、オートパスで使用できます。
メトリクス
監視が有効になっている場合（prometheusプラグイン経由）、次のメトリクスがエクスポートされます。
coredns_autopath_success_total{server}- 成功したオートパス済みクエリのカウンターです。
serverラベルについては、metricsプラグインのドキュメントで説明されています。
例
autopath my-resolv.conf
検索パスを取得するファイルとしてmy-resolv.confを使用します。このファイルには、1行だけ必要です: search domain1 domain2 ...
autopath @kubernetes
kubernetesプラグインから動的に取得した検索パスを使用します。
バグ
Kubernetesでは、オートパスは次の場合にクライアントPodの誤った名前空間（したがって、誤った検索パス）を導き出す可能性があります。クライアントのオートパスの検索パスを適切に構築するには、DNSリクエストを行っているPodの名前空間を知る必要があります。これを行うために、クライアントのIPアドレスをPodに解決するためにkubernetesプラグインのPodキャッシュを使用します。Podキャッシュは、Podsに関するAPIウォッチによって維持されます。PodのIP割り当てが変わると、Kubernetes APIはAPIウォッチを介してCoreDNSに通知します。ただし、その通知は即時ではありません。Podが削除され、そのIPが別の名前空間のPodにすぐにプロビジョニングされ、その新しいPodがAPIウォッチがCoreDNSに変更を通知する前に DNSルックアップを実行した場合、オートパスはIPを以前のPodの名前空間で解決します。
Kubernetesでは、オートパスはWindowsノードで実行されているPodと互換性がありません。
サーバー側の検索が最終的に否定的な応答（例: NXDOMAIN）をもたらした場合、クライアントはすべてのパスを手動で無駄に検索するため、オートパスの最適化は無効になります。