すべてのプロダクト
Search
ドキュメントセンター

HTTPDNS:ルールベースのカスタム DNS 解決の設定

最終更新日:Mar 20, 2026

このトピックでは、ルールベースのカスタム解析の設定方法について説明します。

前提条件

  • カスタム DNS 解決を設定するドメイン名を追加済みである必要があります。詳細については、「ドメイン名の追加」をご参照ください。

操作手順

  1. EMAS コンソール にログインします。

  2. 左側のナビゲーションウィンドウで、解決管理 > カスタム解決 の順に移動します。

  3. カスタム解決の追加 をクリックし、ポリシーの種類を ルールポリシー に設定します。

    image

  4. 以下のパラメーターを設定します:

    • 基本情報

      パラメーター

      説明

      ドメイン名

      カスタム DNS 解決を設定するドメイン名(例:www.aliyun.com)です。

      説明
      • ドロップダウンリストに表示されるドメイン名は、「接続済みドメイン名」で追加したドメイン名から取得されます。使用したいドメイン名がリストにない場合は、カスタム DNS レコードを追加する前に、まずドメイン名リストに追加してください。

      • ワイルドカードドメイン名(例:*.aliyun.com)のサブドメイン(例:a.aliyun.com)に対してカスタム DNS レコードを追加する場合、まず a.aliyun.com をドメイン名リストに追加する必要があります。

      • ドロップダウンリストにドメイン名が見つからない場合、以下のいずれかの状況が考えられます:

        • 該当ドメイン名がドメイン名リストに登録されていません。「接続済みドメイン名」から追加してください。

        • 該当ドメイン名がワイルドカードドメイン名のサブドメインです。サブドメインをドメイン名リストに追加してください。

        • 該当ドメイン名に対して既にカスタム DNS レコードが存在します。そのドメイン名は、カスタム DNS レコード一覧で管理する必要があります。

      キャリアおよびリージョンに基づいて回線を設定できます。

      • 中国本土内の回線:キャリア > 地理的エリア > 省に基づいて設定します。

        • キャリア:中国電信などのキャリアを指定できます。キャリアを「デフォルト」に設定すると、その回線はすべてのキャリアを対象とします。

        • 地理的エリア:東北地方、華北地方、華東地方などの地理的エリアです。各県・市は対応する地理的エリアに属しています。地理的エリアを「デフォルト」に設定すると、その回線はすべての地理的エリアを対象とします。

        • 省:北京や河北省など、特定の省を指定できます。省を「デフォルト」に設定すると、その回線はすべての省を対象とします。

      • 中国本土以外の回線:中国本土以外のリージョンを選択した場合に有効になります。大陸 > 国または地域に基づいて設定します。

        • アジア、ヨーロッパ、南米などの大陸、または日本やイギリスなどの特定の国・地域を選択できます。

        • 大陸および国・地域を「デフォルト」に設定すると、選択された範囲内のすべてのエリアが対象となります。

      説明

      同一ドメイン名において、同一地域のユーザー向けに複数の回線を設定した場合、回線の優先度は「キャリア > 地理的エリア > デフォルト」の順となります。たとえば、優先度の順序は「中国電信-華北地方-北京」>「中国電信-華北地方-デフォルト」>「デフォルト-華北地方-北京」>「デフォルト-デフォルト-デフォルト」です。

      たとえば、「中国電信-華北地方-北京」と「中国電信-華北地方-デフォルト」の両方のルールポリシーが同一ドメイン名に対して設定されている場合、北京にいる中国電信のユーザーは「中国電信-華北地方-北京」のルールポリシーを使用します。

    • カスタム解析ルール

      ルールポリシーでは、最大 10 個のカスタム解決ルールをサポートします。

      パラメーター

      説明

      ルール名

      ルールの名称です。SDK バージョンに基づくスケジューリングなど、ルールの目的を説明するために使用できます。

      ルールの並び順

      複数のルールの順序を調整できます。ルールは上から下へ順次照合され、順序によって最初にヒットするルールが決定されます。順序を変更した後は、新しい順序で照合が行われます。

      SDNS パラメータ設定

      クライアントの解決リクエストに付随する SDNS パラメーターと照合して、ルールがヒットするかどうかを判定するために使用されます。照合が成功した場合、ルールに設定された DNS レコード値が返されます。照合ロジックの詳細については、「ルールポリシーの照合ロジック」をご参照ください。

      • パラメーター名:SDNS パラメーターの名称です。長さは 2~64 文字です。

      • パラメーター値:SDNS パラメーターの値です。長さは 1~64 文字です。

      説明

      DNS レコード値

      カスタム解決の戻り値のコレクションです。各レコード値は、レコードセット内の DNS レコードを表します。このパラメーターは必須です

      • レコードタイプ:返される DNS レコード値のタイプです。A レコードおよび AAAA レコードがサポートされています。

      • レコード値:返されるレコード値です。

      複数のレコード値を追加できます。重み付きスケジューリングが無効の場合、追加されたレコード値はマージされてまとめて返されます。

      また、重みに基づくスケジューリングも可能です。この機能を有効化すると、各レコード値に重み(1~100)を設定できます。重みと負荷分散アルゴリズムに基づいて適切なレコード値が返されます。

      説明

      1 つのルールに最大 10 個のレコード値を追加できます。

      TTL

      必須項目です。カスタム DNS レコードの有効期間です。有効期間が短いほど、HTTPDNS SDK 内の DNS レコードキャッシュの有効期限が早まり、HTTPDNS SDK が新しい DNS レコードを要求する頻度が高くなります。

  5. ポリシー検証

    • ルールポリシーの追加ページには、以下に示すようにルール検証機能が提供されています:

      image

    • 表示される「ポリシー検証」ウィンドウで、必要なパラメーターを入力して、ポリシーが期待通りに動作することを確認します。

      image

ルールポリシーの照合ロジック

ルールポリシーによる解決プロセスは以下のとおりです。API リクエスト内のパラメーターを用いて、設定済みのルールと照合します。ルールは上から下へ順次評価され、最初にヒットしたルールの照合処理は終了し、そのルールのレコード値が返されます。どのルールにもヒットしなかった場合、権威サーバーをクエリして結果を返します。

image

単一のルールにおけるパラメーター照合ロジックは以下のとおりです:

  • API リクエスト内のパラメーターが、ルールで設定された条件を満たす場合、そのルールはヒットします。照合は、ルールで設定されたパラメーターがリクエスト内のパラメーターの部分集合または完全に一致する場合に成立します。

  • ルールにパラメーターが設定されていない場合、そのルールは常にヒットしたものとみなされます。

  • ルール内のパラメーター間は論理積(AND)の関係です。

以下の例で具体的な照合ロジックを説明します。

カスタム DNS 解決が必要なドメイン名を www.example.com と仮定します。

例 1

ルール A は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

Android

ルール B は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

iOS

ルール C は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

Android

bizType

car

リクエストパラメーター:

パラメーター名

パラメーター値

osType

iOS

照合結果:

この例では、リクエストパラメーターはルール B と完全に一致します。HTTPDNS サーバー側は、ルール B のレコード値を返します

例 2

ルール A は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

iOS

bizType

app

ルール B は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

iOS

ルール C は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

Android

bizType

car

リクエストに付随するパラメーター:

パラメーター名

パラメーター値

osType

iOS

照合結果:

例 2 では、ルール内のパラメーターは論理積(AND)の関係であるため、リクエストパラメーターは完全一致の原則に基づき、ルール B と完全に一致します。HTTPDNS サーバー側は、ルール B のレコード値を返します

例 3

ルール A は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

iOS

bizType

car

ルール B は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

iOS

bizType

car

region

hangzhou

ルール C は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

Android

bizType

car

region

shanghai

リクエストパラメーター:

パラメーター名

パラメーター値

osType

iOS

bizType

car

region

hangzhou

照合結果:

例 3 では、リクエストパラメーターはルール A と完全に一致します。完全一致および優先度返却の原則に基づき、HTTPDNS サーバー側はルール A のレコード値を返します。

例 4

ルール A は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

Android

bizType

car

ルール B は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

iOS

bizType

car

region

hangzhou

ルール C は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

Android

bizType

car

region

shanghai

リクエストパラメーター:

パラメーター名

パラメーター値

osType

iOS

照合結果:

この例では、リクエストパラメーターは設定済みのどのルールとも一致しません。したがって、HTTPDNS サーバー側は権威サーバーをクエリして結果を返します

例 5

ルール A は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

Android

bizType

car

ルール B にはパラメーターが設定されていません。

ルール C は以下のパラメーターで設定されています:

パラメーター名

パラメーター値

osType

Android

bizType

car

region

shanghai

リクエストパラメーター:

パラメーター名

パラメーター値

osType

iOS

照合結果:

例 5 では、リクエストパラメーターはルール B と完全に一致し、完全一致および優先度返却の原則に基づき、HTTPDNS サーバー側はルール B のレコード値を優先的に返します。

次のステップ

これでルールベースのカスタム DNS 解決の設定が完了しました。その後の手順については、「全体のワークフロー」をご参照ください。