fanout

fanout:github.com/networkservicemesh/fanout

fanout - 上流リゾルバーへの DNS メッセージの並列プロキシ。

説明

CoreDNS fanout プラグインに到達した各着信 DNS クエリは、リストされた各 IP (つまり DNS サーバー) に並列に複製されます。クエリされた DNS サーバーのいずれかからの最初の非負の応答が、アプリケーションの DNS 要求への応答として転送されます。

構文

tls CERT KEY CA TLS 接続の TLS プロパティを定義します。 0 ～ 3 個の引数を指定でき、その意味は下記のとおりです。
- tls - クライアント認証は使用されず、システム CA がサーバー証明書の検証に使用されます
- tls CA - クライアント認証は使用されず、ファイル CA がサーバー証明書の検証に使用されます
- tls CERT KEY - クライアント認証は、指定された証明書/キーペアで使用されます。サーバー証明書は、システム CA で検証されます
- tls CERT KEY CA - クライアント認証は、指定された証明書/キーペアで使用されます。サーバー証明書は、指定された CA ファイルを使用して検証されます
tls_servername NAME TLS 構成でサーバー名を設定できます。たとえば、9.9.9.9 では、これを dns.quad9.net に設定する必要があります。このシナリオでは、複数の上流が許可されていますが、同じ tls_servername を使用する必要があります。たとえば、9.9.9.9 (QuadDNS) と 1.1.1.1 (Cloudflare) を混在させても機能しません。
worker-count は、リクエストごとの並列クエリの数です。デフォルトでは、IP リストの数と同じです。これは、リクエストあたりの並列クエリを減らす場合にのみ使用してください。
policy - DNS サーバー選択メカニズムのポリシーを指定します。デフォルトは sequential です。
- sequential - DNS サーバーを順番に選択します
- weighted-random - weighted-random-server-count および weighted-random-load-factor パラメータに基づいて DNS サーバーをランダムに選択します。
weighted-random-server-count は、要求される DNS サーバーの数です。デフォルトでは、指定された IP の数と同じです。weighted-random ポリシーでのみ使用されます。
weighted-random-load-factor - サーバーを選択する確率です。これは、IP アドレスのリストの順序で指定され、1 から 100 の間の値を取ります。デフォルトでは、すべてのサーバーの確率は 100 で等しくなります。weighted-random ポリシーでのみ使用されます。
network は特定のネットワークプロトコルです。tcp、udp、tcp-tls が可能です。
except は、プロキシから除外するドメインのスペース区切りリストです。
except-file は、プロキシから除外するドメインの行区切りリストを含むファイルへのパスです。
attempt-count は、上流がダウンしていると見なすまでに必要な、上流サーバーへの接続試行回数です。 0 の場合、上流はダウンとしてマークされず、リクエストは timeout で完了します。デフォルトは 3 です。
timeout は、リクエストのタイムアウトです。この期間が経過すると、上流サーバーからの応答を受信しようとする試行が停止します。デフォルトは 30s です。
race は、標準 DNS 結果である限り、負であろうとなかろうと、最初の結果に優先順位を付けます。

メトリクス

モニタリングが有効になっている場合 (prometheus プラグイン経由)、次のメトリクスがエクスポートされます

coredns_fanout_request_duration_seconds{to} - 上流インタラクションごとの期間。
coredns_fanout_request_count_total{to} - 上流ごとのクエリ数。
coredns_fanout_response_rcode_count_total{to, rcode} - 上流ごとの RCODE の数。

ここで、to は上流サーバーのいずれか (構成の TO)、rcode は上流から返された RCODE です。

例

example.org. 内のすべてのリクエストを、異なるポートで実行されているネームサーバーにプロキシします。プロキシからの最初の肯定的な応答が結果として提供されます。

example.org {
    fanout . 127.0.0.1:9005 127.0.0.1:9006 127.0.0.1:9007 127.0.0.1:9008
}

3 つのリゾルバー間で並列リクエストを送信します。そのうちの 1 つは TCP 経由の IPv6 アドレスを持っています。プロキシからの最初の応答が結果として提供されます。

. {
    fanout . 10.0.0.10:53 10.0.0.11:1053 [2003::1]:53 {
        network TCP
    }
}

example.org へのリクエストを除くすべてのものをプロキシします

. {
    fanout . 10.0.0.10:1234 {
        except example.org
    }
}

ホストの resolv.conf のネームサーバーを使用して、example.org を除くすべてをプロキシします

. {
    fanout . /etc/resolv.conf {
        except example.org
    }
}

DNS-over-TLS プロトコルを使用して、すべてのリクエストを 9.9.9.9 にプロキシします。9.9.9.9 は TLS ネゴシエーションで使用できないため、動作するセットアップが必要な場合は tls-server が必須であることに注意してください。

. {
    fanout . tls://9.9.9.9 {
       tls-server dns.quad9.net
    }
}

UDP 経由で 5 つのリゾルバー間で並列リクエストを送信し、2 つのワーカーを使用し、再接続を試行しません。プロキシからの最初の肯定的な応答が結果として提供されます。

. {
    fanout . 10.0.0.10:53 10.0.0.11:53 10.0.0.12:53 10.0.0.13:1053 10.0.0.14:1053 {
        worker-count 2
    }
}

複数の上流サーバーが構成されていますが、そのうちの 1 つがダウンしている場合、non-existent ドメインをクエリします。race が有効になっている場合は、NXDOMAIN 結果をすぐに取得できます。それ以外の場合は、数秒で "connection timed out" 結果を取得します。

. {
    fanout . 10.0.0.10:53 10.0.0.11:53 10.0.0.12:53 10.0.0.13:1053 10.0.0.14:1053 {
        race
    }
}

ランダムに選択された 2 つのリゾルバー間で並列リクエストを送信します。127.0.0.1:9007 は、最も高い weighted-random-load-factor を持つため、より頻繁に選択されることに注意してください。

example.org {
    fanout . 127.0.0.1:9005 127.0.0.1:9006 127.0.0.1:9007 {
      policy weighted-random
      weighted-random-server-count 2
      weighted-random-load-factor 50 70 100
    }
}

3 つのリゾルバー間で並列リクエストを順番に送信します (デフォルトモード)。

example.org {
    fanout . 127.0.0.1:9005 127.0.0.1:9006 127.0.0.1:9007 {
        policy sequential
    }
}

fanout

説明

構文

メトリクス

例

関連情報