Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

リゾルバーポリシー

最終更新 Markdown で表示Agent セットアップ

デフォルトでは、Gateway は名前解決のために DNS リクエストを Cloudflare の公開 DNS リゾルバー 1.1.1.1 へ送ります。Enterprise ユーザーは、代わりに Gateway ポリシーを作成し、DNS クエリをカスタムリゾルバーへルーティングできます。

flowchart TD
    %% Accessibility
    accTitle: Gateway が DNS クエリをルーティングする流れ
    accDescr: エンドポイントからの DNS クエリが、DNS ポリシーとリゾルバーポリシーを経てユーザーに戻る順序を示すフローチャートです。

    %% Flowchart
    user(["ユーザー"])-->endpoint[/"Gateway DNS エンドポイント"/]

    endpoint-->query["DNS ポリシー（クエリ）"]

    query-->resolver["リゾルバーポリシー"]

    resolver--"カスタムリゾルバーへ</br>ルーティング"-->response["DNS ポリシー（応答）"]

    response--"応答を返す"-->user

Gateway は、一致したポリシーに基づいてユーザートラフィックを設定済みの DNS リゾルバーへルーティングします。リゾルバー同士の IP アドレスが重複していても同様です。

用途

非公開でルーティングされるドメイン（プライベートネットワーク上のサービスや社内リソースなど）へアクセスする必要がある場合に、リゾルバーポリシーを使えます。保護された DNS サービスへアクセスする場合や、複数拠点の DNS 管理を簡素化したい場合にも使えます。

Internal DNS

Cloudflare Internal DNS を使うと、プライベートネットワーク上の社内リソース向け DNS レコードを管理できます。Internal DNS で設定した DNS ゾーンは、Gateway リゾルバーだけが照会できます。リゾルバーポリシーでは、地理的な拠点の既知の送信元 IP など、クエリの文脈に応じて、組織の DNS クエリを社内リソースへ解決する方法を決められます。

リゾルバーポリシーで社内 DNS クエリを解決し始めるには、はじめに を参照してください。

Local Domain Fallback

DNS サーバーに Cloudflare のネットワークから到達できる場合（たとえば Cloudflare Tunnel、IPsec/GRE トンネル、または公開インターネット経由）は、リゾルバーポリシーを使います。DNS サーバーにユーザーのデバイスからしか到達できない場合は、Local Domain Fallback を使います。

同じデバイスに Local Domain Fallback とリゾルバーポリシーの両方がある場合、Cloudflare はまずクライアント側の Local Domain Fallback ルールを適用します。Cloudflare One Client で DNS クエリを Gateway にオンボードし、リゾルバーポリシーでルーティングすると、クエリの送信元 IP は Cloudflare One Client が割り当てた IP アドレスになります。

リゾルバー接続

リゾルバーポリシーは TCP と UDP 接続に対応しています。カスタムリゾルバーは、IPv4 または IPv6 でインターネットを指すことも、Magic トンネル などのプライベートネットワークサービスを指すこともできます。ポリシーのデフォルトポートは 53 です。ポリシー内でカスタマイズして、リゾルバーが使うポートを変更できます。

DNS Firewall を有効にすると、権威ネームサーバーを DDoS 攻撃から保護できます。

Cloudflare Tunnel

Cloudflare Tunnel で Cloudflare に接続したプライベートリゾルバーへの接続を設定できます。cloudflared がリゾルバーへ UDP トラフィックをルーティングできるようにするには、トンネルを QUIC で接続します。

Cloudflare Tunnel でプライベート DNS リゾルバーを Cloudflare に接続する方法の詳細は、Private DNS を参照してください。

Cloudflare WAN

Cloudflare WAN 経由で Cloudflare に接続したプライベートリゾルバーへの接続を有効にするには、アカウントチームに問い合わせてください。

利用できる DNS エンドポイント

リゾルバーポリシーは、次の DNS エンドポイントからのクエリを解決先へルーティングできます。

Gateway は、エンドポイントに関係なくクエリをフィルタリング、解決、記録します。

リゾルバーポリシーを作成する

リゾルバーポリシーを作成するには:

  1. Cloudflare ダッシュボード ↗ で Zero Trust > Traffic policies > Resolver policies を開きます。

  2. Add a policy を選択します。

  3. 対象トラフィックの式を作成します。たとえば、内部サービスのホスト名を解決できます。

    セレクター 演算子 値
    Host in internal.example.com

    宛先が Local Domain Fallback の対象になっていないことを確認してください。

  4. Select DNS resolver で Configure custom DNS resolvers を選びます。

  5. カスタム DNS リゾルバーの IP アドレスを入力します。IP アドレスを入力すると、Gateway は Zero Trust で設定した 仮想ネットワーク を検索します。

  6. Network で、クエリを公開（インターネット）へ送るか、非公開（プライベートネットワークサービス）へ送るかを選びます。

  7. （任意）各 IP アドレスにカスタムポートを入力します。

  8. Create policy を選択します。

カスタムリゾルバーはアカウントに保存され、あとから再利用できます。ポリシーには IPv4 アドレスを最大 10 個、IPv6 アドレスを最大 10 個追加できます。

  1. 次の権限を cloudflare_api_token ↗ に追加します。

    • Zero Trust Write

  2. cloudflare_zero_trust_gateway_policy ↗ リソースでリゾルバーポリシーを作成します。

    resource "cloudflare_zero_trust_gateway_policy" "resolver_policy" {
	name        = "Example resolver policy"
	enabled     = true
	account_id  = var.cloudflare_account_id
	description = "TERRAFORM MANAGED resolver policy"
	action      = "resolve"
	traffic     = "dns.fqdn in {\"internal.example.com\"}"
	identity    = "identity.email in {\"jdoe@example.com\"}"
	precedence  = 1
	rule_settings = {
			dns_resolvers = {
			# You can add up to 10 IPv4 and 10 IPv6 addresses to a policy.
				ipv4 = [{
					ip = "192.0.2.24"
					port = 53
					route_through_private_network = true
					vnet_id = cloudflare_zero_trust_tunnel_cloudflared_virtual_network.staging_vnet.id
				}]
				ipv6 = [{
					ip = "2001:DB8::"
					port = 53
					route_through_private_network = true
					vnet_id = cloudflare_zero_trust_tunnel_cloudflared_virtual_network.staging_vnet.id
				}]
			}
	}
}

ユーザーのクエリがリゾルバーポリシーに一致すると、Gateway は次の順でリスト上のリゾルバーへクエリを送ります。

  1. 公開リゾルバー
  2. アカウントのデフォルト仮想ネットワーク配下のプライベートリゾルバー
  3. カスタム仮想ネットワーク配下のプライベートリゾルバー

Gateway は、以降のクエリで使うため、最も速いリゾルバーをキャッシュします。リゾルバーの優先順位は、データセンターごとにユーザー単位でキャッシュされます。

DNS ポリシーの作成について詳しくは、DNS ポリシー を参照してください。

専用 egress IP を送信元にして DNS クエリを送る Closed beta

デフォルトでは、Gateway がカスタムリゾルバーへ送る DNS リクエストは、共有の Cloudflare 送信元 IP アドレスを使います。上流リゾルバーが送信元 IP でアクセスを制限している場合は、リゾルバーポリシーを設定し、代わりに 専用 egress IP からそれらのリクエストを送れます。

前提条件

  • アカウントに専用 egress IP がプロビジョニングされている必要があります。
  • リゾルバーポリシーには、公開リゾルバーが少なくとも 1 つ必要です。すべてのリゾルバーがプライベートネットワーク経由の場合、専用 egress IP は使えません。

リゾルバーポリシーで専用 egress を有効にする

  1. Cloudflare One ダッシュボード ↗ で Traffic policies > Resolver policies を開きます。
  2. カスタム DNS リゾルバーを使うリゾルバーポリシーを作成または編集します。
  3. カスタムリゾルバーの設定で、Use dedicated egress IPs for DNS requests to custom resolvers をオンにします。
  4. 利用可能な専用 egress IP から Primary IPv4、IPv6、任意で Secondary IPv4 アドレスを選びます。
  5. ポリシーを保存します。

API 設定

API でリゾルバーポリシーに専用 egress を設定するには、rule_settings に egress オブジェクトを追加します。

{
	"rule_settings": {
		"dns_resolvers": {
			"ipv4": [{ "ip": "198.51.100.1" }]
		},
		"egress": {
			"ipv4": "104.30.133.232",
			"ipv6": "2a09:bac0:1000:3ec::/64",
			"ipv4_fallback": "104.30.134.156"
		}
	}
}

egress オブジェクトは egress ポリシー と同じスキーマを使います。

セレクター

Content Categories

このセレクターは、特定の コンテンツカテゴリ に属するドメインをフィルタするために使います。

UI 名 API の例 評価フェーズ
Content Categories any(dns.content_category[*] in {1}) DNS 解決前

DNS Resolver IP

登録済みの DNS ロケーションに対応する Gateway Resolver IP アドレスへ届いた DNS クエリに、ポリシーを適用するときにこのセレクターを使います。ほとんどの Gateway 利用者では IPv4 エニーキャストアドレスであり、この IPv4 アドレスで作成したポリシーはすべての DNS ロケーションに適用されます。ただし、各 DNS ロケーションには専用の IPv6 アドレスがあり、一部の Gateway 利用者には専用の IPv4 アドレスが提供されています。どちらも、特定の登録済み DNS ロケーションにポリシーを適用するために使えます。

UI 名 API の例 評価フェーズ
DNS Resolver IP any(dns.resolved_ip[*] == 198.51.100.0) DNS 解決前

DoH Subdomain

このセレクターは、各 DNS ロケーションに設定した DoH エンドポイント宛の、DNS-over-HTTPS（DoH）経由の DNS クエリに一致させるために使います。たとえば、DoH エンドポイントが abcdefg.cloudflare-gateway.com の DNS ロケーションを使う場合は、DoH Subdomain セレクターを選び、値に abcdefg を入力します。

UI 名 API の例 評価フェーズ
DOH Subdomain dns.doh_subdomain == "abcdefg" DNS 解決前

Domain

このセレクターは、ドメインとそのすべてのサブドメインに一致します。たとえば、example.com と www.example.com などのサブドメインに一致できます。

UI 名 API の例 評価フェーズ
Domain any(dns.domains[*] == "example.com") DNS 解決前

Gateway ポリシーは、非ラテン文字を含む domain を直接はサポートしません。非ラテン文字を含む domain を使うには、リスト に追加します。

Host

このセレクターは、指定したホスト名だけに一致します。たとえば、test.example.com には一致しますが、example.com や www.test.example.com には一致しません。

UI 名 API の例 評価フェーズ
Host dns.fqdn == "example.com" DNS 解決前

Gateway ポリシーは、非ラテン文字を含む hostname を直接はサポートしません。非ラテン文字を含む hostname を使うには、リスト に追加します。

Location

このセレクターは、特定の Gateway DNS ロケーション、または複数のロケーションにポリシーを適用するために使います。

UI 名 API の例 評価フェーズ
Location dns.location in {"location_uuid_1" "location_uuid_2"} DNS 解決前

Query Record Type

このセレクターは、ポリシーを適用する DNS リソースレコードタイプを選ぶときに使います。たとえば、ドメインの A レコードには一致させ、MX レコードには一致させない、といった指定ができます。

UI 名 API の例 評価フェーズ
Query Record Type dns.query_rtype == "TXT" DNS 解決前

Security Categories

このセレクターは、特定の セキュリティカテゴリ に属するドメイン（任意で IP アドレス）と照合します。

UI 名 API の例 評価フェーズ
Security Categories any(dns.security_category[*] in {1}) DNS 解決前

Source Continent

このセレクターは、クエリが Gateway に到達した大陸で絞り込みます。

位置情報は、デバイスのパブリック IP アドレス（通常はユーザーの ISP が割り当てます）から判定します。大陸を指定するには、Value フィールドに 2 文字のコードを入力します。

大陸 コード
アフリカ AF
南極 AN
アジア AS
ヨーロッパ EU
北アメリカ NA
オセアニア OC
南アメリカ SA
UI 名 API の例 評価フェーズ
Source Continent IP Geolocation dns.src.geo.continent == "North America" DNS 解決前

Source Country

このセレクターは、クエリが Gateway に到達した国で絞り込みます。

位置情報は、デバイスのパブリック IP アドレス（通常はユーザーの ISP が割り当てます）から判定します。国を指定するには、Value フィールドに ISO 3166-1 Alpha-2 コード ↗ を入力します。

UI 名 API の例 評価フェーズ
Source Country IP Geolocation dns.src.geo.country == "RU" DNS 解決前

Source IP

このセレクターは、DNS クエリの送信元 IP アドレスにポリシーを適用します。たとえば、組織が Gateway へクエリを送るために使うスタブリゾルバーの WAN IP アドレスです。

UI 名 API の例 評価フェーズ
Source IP dns.src_ip == 198.51.100.0 DNS 解決前

Users

これらのセレクターを使い、アイデンティティ属性と照合します。

UI 名 API の例 評価フェーズ
User Email identity.email == "user@example.com" DNS 解決前
User Name identity.name == "Test User" DNS 解決前
User Group IDs any(identity.groups[*].id in {"group_id"}) DNS 解決前
User Group Names any(identity.groups[*].name in {"group_name"}) DNS 解決前
User Group Emails any(identity.groups[*].email in {"group@example.com"}) DNS 解決前
SAML Attributes any(identity.saml_attributes["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"] in {"Test User"}) DNS 解決前

比較演算子

比較演算子は、Gateway がトラフィックをセレクターと照合する方法です。ダッシュボードのポリシービルダーで Selector を選ぶと、Operator のドロップダウンに、そのセレクターで使える選択肢が表示されます。

演算子 意味
is 定義した値と等しい
is not 定義した値と等しくない
in 定義した値のいずれかと一致する
not in 定義した値のいずれとも一致しない
in list 定義済みの リスト に含まれる
not in list 定義済みの リスト に含まれない
matches regex 正規表現が true と評価される
does not match regex 正規表現が false と評価される
greater than 定義した数値を超える
greater than or equal to 定義した数値以上
less than 定義した数値未満
less than or equal to 定義した数値以下

値

Value には、等価比較演算子（is など）を使う場合は単一の値を、包含比較演算子（in など）を使う場合は複数の値を入力できます。対応するセレクターでは、正規表現（regex）で値の範囲を指定することもできます。

正規表現

正規表現は Rust で評価されます。Rust の実装は、ほかで使われる正規表現ライブラリと少し異なります。詳細は ワイルドカード のガイドを参照してください。正規表現が一致するか確認するには、Rustexp ↗ を使えます。

複数の値に一致させたい場合は、パイプ記号（|）を OR 演算子として使えます。パイプ記号の前にエスケープ文字（\）は不要です。たとえば、次の式は hostname が .*whispersystems.org または .*signal.org のいずれかに一致すると true になります。

セレクター 演算子 値
Host matches regex .*whispersystems.org|.*signal.org

正規表現に加えて、論理演算子 で複数の値に一致させることもできます。

論理演算子

式内の複数の条件を評価するには、And 論理演算子を選びます。これらの式は、Or 論理演算子でさらに比較できます。

演算子 意味
And 式内のすべての条件に一致する
Or 式内のいずれかの条件に一致する

Or 演算子は、同じ式グループ内の条件に対してのみ使えます。たとえば、Traffic の条件と Identity の条件は比較できません。

役に立ちましたか？