次のCorefileでのクイズの時間
. {
proxy . 8.8.8.8:53
file db.example.com
}
www.google.comクエリはproxyまたはfileプラグインによって処理されますか? 以下に解答を入力します。
このCorefileは実際に何を言っていますか? ルート(.)およびその下すべてのクエリ(つまり、すべてのドメイン名)について、このスタンザを入力する必要があることを指定します。
次にすべてのクエリは8.8.8.8:53に転送する必要があります。
それからfileプラグインはdb.example.comファイルからどのゾーンに回答されるべきかを指定しないので、ルート(.)である最上位レベルが適用されます。
したがって、同じ名前に対して両方のプラグインが呼び出される状況になります(これは他の連鎖したプラグインを呼び出すプラグインに対して完全に有効である可能性があります)。
しかし、クエリがプラグインが存在した後に回答されて完了するため、proxyはfileを呼び出しません。逆の方向でも同じです。
ここで何が起こっているのかを確認するには、プラグインの順序を確認する必要があります
...
dnssec:dnssec
file:file
etcd:etcd
proxy:proxy
...
そして、fileが最初でproxyが少し後に来ることがわかります。これは、上記の例ではすべてのクエリがfileプラグインにルーティングされることを意味します。fileはそれらのクエリをSERVFAILで喜んで回答します。これは、www.google.comが主に*.example.comの名前を持つファイルで検出できない可能性があるためです。
これを修正するには、スタンザを分離するか、fileプラグインの起点(複数)を指定する必要があります。
. {
proxy . 8.8.8.8:53
file db.example.com example.com
}
機能強化要求に先回りして: はい、CoreDNSがこのことを検出して警告するとよいでしょう(今はそうではありません)。