転送

ソース

forward は、DNSメッセージをアップストリームリゾルバーにプロキシ転送する機能を提供します。

説明

forward プラグインは、アップストリームへの既存のオープンソケットを再利用します。UDP、TCP、およびDNS-over-TLSをサポートし、インバンドヘルスチェックを使用します。

エラーを検出すると、ヘルスチェックが実行されます。このチェックはループで実行され、アップストリームが異常な状態を報告している限り、0.5秒間隔で各チェックを実行します。正常になると、ヘルスチェックを停止します（次のエラーが発生するまで）。ヘルスチェックは、再帰的なDNSクエリ（. IN NS）を使用してアップストリームのヘルス状態を取得します。ネットワークエラー（REFUSED、NOTIMPL、SERVFAILなど）ではない応答は、正常なアップストリームと見なされます。ヘルスチェックは、TOで指定されたものと同じプロトコルを使用します。 max_fails が0に設定されている場合、チェックは実行されず、アップストリームは常に正常と見なされます。

すべてのアップストリームがダウンしている場合、ヘルスチェックのメカニズムが失敗したと想定し、ランダムなアップストリームへの接続を試みます（動作するかどうかは保証されません）。

構文

最も基本的な形式では、単純なフォワーダーはこの構文を使用します

forward FROM TO...
  • FROM は、転送されるリクエストに一致するベースドメインです。複数の逆引きゾーンに展開されるCIDR表記を使用するドメインは完全にサポートされていません。最初に展開されたゾーンのみが使用されます。
  • TO… は、転送先の宛先エンドポイントです。 TO 構文では、プロトコル、プレーンDNSの場合はtls://9.9.9.9またはdns://（またはプロトコルなし）を指定できます。アップストリームの数は15に制限されています。

複数のアップストリームは、最初の使用時にランダム化されます（policyを参照）。正常なプロキシが交換中にエラーを返した場合、リストの次のアップストリームが試行されます。

拡張構文では、追加のノブを使用できます

forward FROM TO... {
    except IGNORED_NAMES...
    force_tcp
    prefer_udp
    expire DURATION
    max_fails INTEGER
    tls CERT KEY CA
    tls_servername NAME
    policy random|round_robin|sequential
    health_check DURATION [no_rec] [domain FQDN]
    max_concurrent MAX
}

  • FROM および TO… は上記のとおりです。

  • except の IGNORED_NAMES は、転送から除外するドメインのスペース区切りのリストです。これらの名前のいずれにも一致しないリクエストは通過します。

  • force_tcp、リクエストがUDP経由で着信した場合でもTCPを使用します。

  • prefer_udp、リクエストがTCP経由で着信した場合でも、最初にUDPを使用してみます。応答が切り捨てられた場合（応答にTCフラグが設定されている場合）、TCP経由で再試行します。 force_tcp と prefer_udp の両方のオプションが指定されている場合、force_tcp が優先されます。

  • max_fails は、アップストリームがダウンしていると見なされるまでに必要な、連続したヘルスチェックの失敗回数です。0の場合、アップストリームはダウンとしてマークされません（ヘルスチェックも実行されません）。デフォルトは2です。

  • expire DURATION、この時間の経過後に（キャッシュされた）接続を期限切れにします。デフォルトは10秒です。

  • 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）を混在させることはできません。TLS転送を使用するが、tls_servernameを設定しないと、転送先のDNSサーバーへの接続に中間者攻撃を受ける可能性があります。このため、TLS転送を使用する場合は、この値を設定することを強くお勧めします。

  • policy は、アップストリームサーバーを選択するために使用するポリシーを指定します。デフォルトはrandomです。

    • random は、ランダムなアップストリーム選択を実装するポリシーです。
    • round_robin は、ラウンドロビン順序に基づいてホストを選択するポリシーです。
    • sequential は、順次順序に基づいてホストを選択するポリシーです。

  • health_check アップストリームサーバーのヘルスチェックの動作を設定します

    • <duration> - ヘルスチェックに異なる期間を使用します。デフォルトの期間は0.5秒です。
    • no_rec - ヘルスチェックで使用されるdnsクエリのRecursionDesiredフラグをfalseに設定するオプションの引数。フラグのデフォルトはtrueです。
    • domain FQDN - ヘルスチェックに使用するドメイン名をFQDNに設定します。設定されていない場合、ヘルスチェックに使用されるドメイン名は.です。

  • max_concurrent MAX は、同時クエリの数をMAXに制限します。同時クエリの数をMAXを超える新しいクエリは、REFUSED応答になります。この応答は、ヘルス障害としてカウントされません。 MAXの値を選択する場合は、少なくとも予想される*アップストリームクエリレート* *アップストリームサーバーのレイテンシ*よりも大きい数を選択してください。 MAXの上限として、各同時クエリは約2kbのメモリを使用することを考慮してください。

また、TLS設定は転送プロキシ全体で「グローバル」であることに注意してください。異なるアップストリームに異なるtls_servernameが必要な場合は、運が悪いです。

各エンドポイントでは、通信のタイムアウトは次のように設定されます

  • ダイヤルタイムアウトはデフォルトで30秒で、初期の結果に基づいて自動的に1秒まで短縮できます。
  • 読み取りタイムアウトは2秒で静的です。

メタデータ

forwardプラグインは、_metadata_プラグインも有効になっている場合、次のメタデータを公開します

  • forward/upstream：リクエストの転送に使用されるアップストリーム

メトリクス

モニタリングが有効になっている場合（_prometheus_プラグインを介して）、次のメトリックがエクスポートされます

  • coredns_forward_healthcheck_broken_total{} - すべてのアップストリームが異常で、ランダムに（これは常にrandomポリシーを使用します）アップストリームに送信している場合のカウント。
  • coredns_forward_max_concurrent_rejects_total{} - 同時クエリの数が最大であったために拒否されたクエリの数。
  • coredns_proxy_request_duration_seconds{proxy_name="forward", to, rcode} - アップストリームごとのヒストグラム、RCODE
  • coredns_proxy_healthcheck_failures_total{proxy_name="forward", to, rcode}- アップストリームごとの失敗したヘルスチェックの数。
  • coredns_proxy_conn_cache_hits_total{proxy_name="forward", to, proto}- アップストリームとプロトコルごとの接続キャッシュヒットの数。
  • coredns_proxy_conn_cache_misses_total{proxy_name="forward", to, proto} - アップストリームとプロトコルごとの接続キャッシュミスの数。

ここで、to はアップストリームサーバーの1つ（設定のTO）、rcode はアップストリームから返されたRCODE、proto は udp、tcp、tcp-tls などのトランスポートプロトコルです。

次のメトリックは最近廃止されました

  • coredns_forward_healthcheck_failures_total{to, rcode}
    • coredns_proxy_healthcheck_failures_total{proxy_name="forward", to, rcode}に置き換えることができます
  • coredns_forward_requests_total{to}
    • sum(coredns_proxy_request_duration_seconds_count{proxy_name="forward", to})に置き換えることができます
  • coredns_forward_responses_total{to, rcode}
    • coredns_proxy_request_duration_seconds_count{proxy_name="forward", to, rcode}に置き換えることができます
  • coredns_forward_request_duration_seconds{to, rcode}
    • coredns_proxy_request_duration_seconds{proxy_name="forward", to, rcode}に置き換えることができます

例

example.org.内のすべてのリクエストを、別のポートで実行されているネームサーバーにプロキシします

example.org {
    forward . 127.0.0.1:9005
}

lab.example.local.内のすべてのリクエストを10.20.0.1に、example.local.内のすべてのリクエスト（およびlab.example.local.内にない）を10.0.0.1に、他のすべてのリクエストを/etc/resolv.confで定義されているサーバーに送信し、結果をキャッシュします。サーバーブロックに複数の_forward_プラグインが設定されているCoreDNSサーバーは、リクエストを処理するときに、リストされている順序でそれらのforwardプラグインを評価することに注意してください。したがって、サブドメインリクエストが親ドメインのアップストリームに転送されないように、サブドメインを親ドメインの前に配置する必要があります。したがって、この例では、lab.example.localはexample.localの前に、example.localは.の前にあります。

. {
    cache
    forward lab.example.local 10.20.0.1
    forward example.local 10.0.0.1
    forward . /etc/resolv.conf
}

上記の例は、以下の例とほぼ同じですが、以下の例では3つの個別のプラグインチェーン（したがって_cache_の3つの個別のインスタンス）を定義している点が異なります。

lab.example.local {
    cache
    forward . 10.20.0.1
}
example.local {
    cache
    forward . 10.0.0.1
}
. {
    cache
    forward . /etc/resolv.conf
}

すべてのリクエストの負荷を3つのリゾルバー間で分散します。そのうちの1つはIPv6アドレスを持っています。

. {
    forward . 10.0.0.10:53 10.0.0.11:1053 [2003::1]:53
}

example.orgへのリクエストを除くすべてを転送します

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

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

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

DNS-over-TLS（DoT）プロトコルを使用してすべてのリクエストを9.9.9.9にプロキシし、すべての回答を最大30秒間キャッシュします。9.9.9.9はTLSネゴシエーションで使用できないため、tls_servernameは、機能する設定にするために必須であることに注意してください。また、ヘルスチェックの期間を5秒に設定して、サービスがヘルスチェックで完全に飽和しないようにします。

. {
    forward . tls://9.9.9.9 {
       tls_servername dns.quad9.net
       health_check 5s
    }
    cache 30
}

または、ヘルスチェックリクエスト用に他のドメイン名を設定します

. {
    forward . tls://9.9.9.9 {
       tls_servername dns.quad9.net
       health_check 5s domain example.org
    }
    cache 30
}

または、同じプロバイダーからの複数のアップストリームを使用する場合

. {
    forward . tls://1.1.1.1 tls://1.0.0.1 {
       tls_servername cloudflare-dns.com
       health_check 5s
    }
    cache 30
}

または、異なるtls_servernameを持つ複数のDoTアップストリームがある場合は、次のことができます

. {
    forward . 127.0.0.1:5301 127.0.0.1:5302
}

.:5301 {
    forward . tls://8.8.8.8 tls://8.8.4.4 {
        tls_servername dns.google
    }
}

.:5302 {
    forward . tls://1.1.1.1 tls://1.0.0.1 {
        tls_servername cloudflare-dns.com
    }
}

関連項目

TLS over DNSについては、RFC 7858を参照してください。

このファイルの正式なソース