DNS Traffic Management Steering Policies

解決する課題

• 障害時に別リージョン／別エンドポイントへ自動で切り替えたい（フェイルオーバー）
• ユーザーを最も近い／速いエンドポイントへ誘導したい（ジオロケーション系）
• 複数のエンドポイントへ重み付けでトラフィックを分散したい（カナリア・段階移行）
• ダウン中のエンドポイントをDNS応答から自動で外し、生きている先だけを返したい

主要概念と用語

• ステアリングポリシー（Steering Policy）: 同じFQDNへの問い合わせに対し、条件に応じて返す応答（アンサー）を動的に選ぶルールの集合。Route 53のルーティングポリシーに相当
• ポリシーアタッチメント（Attachment）: ステアリングポリシーを特定のゾーン内のドメイン（FQDN）に結びつける関連付け。1ドメインに1アタッチメント
• アンサー（Answer）: 返却候補となる個々のレコード値（A/AAAA/CNAMEなど）。各アンサーにプール（pool）名や**重み（weight）**といったメタデータを付与できる
• ルール（Rule）: アンサーを評価して並べ替え・除外する処理の連なり。ヘルスチェック除外、地理・ASN・IPプレフィックスでの絞り込み、重み付け、上限件数の制限などを段階的に適用
• ヘルスチェック（Health Checks）連動: HTTP/HTTPS/TCP/ICMPの監視結果をルールに渡し、ダウン中のアンサーを自動で除外
• ポリシータイプ: 用途別のテンプレート。FAILOVER／LOAD_BALANCER／ROUTE_BY_GEO／ROUTE_BY_ASN／ROUTE_BY_IP／CUSTOM
• TTL: ステアリングが返すレコードのキャッシュ時間。切替の速さに直結するため、フェイルオーバー前提では短めに設定

仕様・制限・クォータ

• ステアリングポリシーはOCI DNSの機能であり、対象ドメインはOCIで権威を持つパブリックゾーンに属している必要がある
• 1つのドメイン（FQDN）には1つのポリシーアタッチメントのみ。複数ポリシーを同じ名前に同時適用はできない
• ポリシーはコンパートメント配下のリソースとしてIAMポリシーで権限制御
• アンサー数・ルール数・ポリシー数などにはサービス制限があり、上限値は変動するため公式ドキュメントとコンソールのリミット表示を参照
• ヘルスチェック連動には別途Health Checksのモニタ設定が必要で、ステアリング側がその結果を参照する
• 応答は権威DNSの仕組みに乗るため、最終的な切替速度はリゾルバ側のTTLキャッシュに依存する

内部の仕組み

ステアリングポリシーの本質は、同じFQDNへの問い合わせに対して固定のレコードを返すのではなく、評価のたびにアンサー候補を並べ替え・絞り込みして返す点にあります。

問い合わせが届くと、OCI DNSは対象ドメインにアタッチされたポリシーを評価します。まずアンサー集合（各アンサーにプール名・重み・地理などのメタデータが付く）を起点に、ルールを順番に適用していきます。代表的なルールは次のように働きます。

• ヘルスチェック ルール: Health Checksの結果を参照し、ダウン中のアンサーを候補から除外する
• 地理／ASN／IPプレフィックス ルール: 問い合わせの送信元（再帰リゾルバの位置やネットワーク）に応じて、該当プールのアンサーを優先・限定する
• 重み付け ルール: 各アンサーのweightに比例した確率で候補を並べ替え、ロードバランサ的に分散する
• 件数制限 ルール: 最終的に返すアンサー数を絞る（例: 1件だけ返してフェイルオーバー的に振る舞う）

これらを通過した結果が、その問い合わせへのDNS応答になります。送信元やヘルス状態が変われば同じ名前でも返る値が変わるため、静的なAレコードでは表現できない動的なルーティングを、アプリ側を一切変えずに実現できます。

設計パターン / ベストプラクティス

• DR フェイルオーバー: FAILOVERポリシー＋ヘルスチェックで、プライマリ異常時にセカンダリ リージョンへ自動切替。切替前提でTTLは短めにしておく
• 多リージョン分散・カナリア: LOAD_BALANCER（重み付け）でトラフィックを按分し、新リージョンへ少しずつ寄せる
• データレジデンシー対応: ROUTE_BY_GEOで規制要件に応じて地域ごとに返す先を分ける
• ネットワーク最適化: ROUTE_BY_ASNやROUTE_BY_IPで、特定の通信事業者・社内ネットワークからのアクセスを専用エンドポイントへ誘導
• apex との併用: ゾーン頂点（apex）はALIASレコードでロードバランサへ向け、その手前の振り分けをステアリングで担う設計が相性良い

運用・監視

• ヘルスチェックのステータスを監視し、OCI MonitoringのメトリクスとAlarmsで異常を検知
• ポリシー／アタッチメントの変更はAuditログで追跡し、いつ誰が振り分けを変えたかを可視化
• 実際にどのアンサーが返るかはdig／nslookupで、送信元の異なる地点（または別ASN）から検証
• フェイルオーバーが効かないときは、まずTTL、次にヘルスチェックのモニタ設定（対象URL・しきい値）とアタッチメントの有効化を確認

コスト

課金は主に「ステアリングポリシー」と、連動させる「ヘルスチェック」の規模に応じます。

セキュリティ

• IAMポリシー＋コンパートメントでステアリングポリシー／アタッチメントの変更権限を最小化する
• 振り分け先エンドポイントは、ステアリングだけに頼らず各レイヤ（NSG／セキュリティリスト／WAF）でも防御する。DNSは経路を案内するだけで通信そのものを止めはしない
• 内部向けの振り分けに使う場合でも、パブリックゾーンに内部ホスト名やプライベートIPを露出させない

関連サービス・比較

ステアリングはOCI DNSの一機能であり、Health Checksと密接に連動します。AWSではRoute 53のルーティングポリシーが相当します。

ハンズオン / CLI例

最小の流れは「ヘルスチェック モニタを用意 → ステアリングポリシー作成 → ドメインへアタッチ」です。

# 1) ヘルスチェックのHTTPモニタを作成（ステアリングが参照する死活監視）
oci health-checks http-monitor create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name primary-health \
  --protocol HTTPS \
  --targets '["203.0.113.10"]' \
  --path "/healthz" \
  --interval-in-seconds 30

# 2) フェイルオーバー型のステアリングポリシーを作成
#    （プライマリ異常時にセカンダリのアンサーへ切り替える想定）
oci dns steering-policy create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name failover-policy \
  --template FAILOVER \
  --ttl 60

# 3) ポリシーを対象ドメイン（FQDN）へアタッチ
oci dns steering-policy-attachment create \
  --steering-policy-id ocid1.dnssteeringpolicy.oc1..xxxx \
  --zone-id ocid1.dns-zone.oc1..xxxx \
  --domain-name app.example.com

# 4) 作成済みのステアリングポリシーとアタッチメントを確認
oci dns steering-policy list \
  --compartment-id ocid1.compartment.oc1..xxxx

oci dns steering-policy-attachment list \
  --compartment-id ocid1.compartment.oc1..xxxx