· 

OCIのDNSサービス

こんにちは。テリロジーのumeです。

 

今回、私からはOCIで使えるクラウド型DNSサービスについて紹介したいと思います。

DNSと一言にいっても色々な機能がありますが、OCIのDNSサービスでは権威サーバとしての動作がメインのような印象を受けます。

 

2021/11/29時点で管理コンソールで表示されているメニューは以下の通りです。

(OCIログイン後、ネットワーキング > DNS管理の画面)

  • ゾーン
  • トラフィック管理ステアリング・ポリシー
  • プライベート・ビュー
  • HTTPリダイレクト
  • TSIGキー

それぞれ概要を説明したいと思います。

ゾーン

その名の通り、DNSゾーンの管理を行うサービスです。

基本的にVCNにアタッチして使用しますが「パブリック・ゾーン」と「プライベート・ゾーン」の2種類があります。

パブリック・ゾーン

パブリック・ゾーンはいわゆる外部公開ゾーンです。

外向け権威DNSサーバとして稼働する感じです。

 

プライマリサーバとしても、セカンダリサーバとしても動作させることができます。

セカンダリサーバとして使用する場合、プライマリサーバ側で以下のIPアドレスからのゾーン転送要求を許可してあげる必要があります。IPv6もありますね。

 

208.78.68.65
204.13.249.65
2600:2001:0:1::65
2600:2003:0:1::65

プライベート・ゾーン

プライベート・ゾーンはいわゆる内部ローカル向けゾーンです。

こちらはプライマリサーバのみのようで、ゾーン・タイプがグレーアウトして変更できないです。

セカンダリサーバとして使えないのはちょっと残念ですね。

 

デフォルトだとクライアント側から見えるIPアドレスは「169.254.169.254」のものが用意されてます。

権威DNSサーバ兼キャッシュサーバになっているように見えますね。

自身の管理ゾーンでなければrootに問い合わせする感じです。

 

また、VCNの方の設定項目であるプライベートDNSリゾルバのところに「エンドポイント」という機能あり、こちらでListenするIPを追加することもできます。

サブネット単位で指定する形になるので、イメージとしてはリクエスト受付専用のインスタンスが立ち上げるような感じでしょうか。

セキュリティリストも適用されますし、NSGの適用も可能です。

 

フォワードゾーン(条件付きFowarder)を作りたい場合も「エンドポイント」の機能を使用します。

すべてのリクエストを特定のDNSサーバにフォワードしたい場合も同様です。

 

設定箇所がゾーンのところではないので、若干分かりづらい印象を受けました。

トラフィック管理ステアリング・ポリシー

何やら仰々しい名前ですが。

以下の説明書きがあります。

「トラフィック管理ステアリング・ポリシーによって、DNS問合せに対してインテリジェント・レスポンスを提供するようにポリシーを構成できるため、ポリシー・ロジックに応じて問合せに異なる回答(エンドポイント)を提供できます。」

 

…ようは指定したポリシーに沿ってDNS応答をいい感じに変えられるということのようです。(ざっくりしすぎ)

設定方法を見る限り、パブリック・ゾーンにのみ適用できる機能のようです。

以下のポリシータイプが選択できます。

それぞれのポリシーを少し細かく見ていきます。

 

ロード・バランサ

わざわざ書くことでもないかもしれませんが、DNSの名前解決によって複数のサーバーにトラフィックを分散します。

 

DNSラウンドロビンや、重み付けを設定して応答をコントロールすることができます。

使用できるレコードタイプはA、AAAA、CNAMEの3種類です。

 

登録したレコードへのヘルスチェック機能もあり、ヘルスチェックの結果でDNSの応答に含めるか除外するかを自動でコントロールしてくれます。

ただ気をつけないといけないのが、ここの設定項目でヘルスチェックを新規作成すると、

リクエストタイプがHTTP固定で、選択できるプロトコルがHTTPとHTTPSの2種類になっています。

 

ヘルスチェック作成用の別画面だと、リクエストタイプにPingチェックが選択できるのですが

トラフィック管理ステアリング・ポリシーの適用はできない(リクエストタイプがHTTPのみ)のようです。

 

実際にユーザにアクセスさせるFQDNについては少し設定方法が分かりづらい感じですが、「アタッチ済みドメイン」という項目でFQDNを指定します。

先にゾーンを作成する必要があり、パブリック・ゾーンを指定して、そこにレコードをアタッチする感じです。

 

例えばsub.test.terilogy.tokyoというレコードを作ってバランシングさせたい場合、

先に作るゾーンは「test.terilogy.tokyo」、

アタッチ済みドメインの追加の項目にあるサブドメインでsubを入力して設定します。

 

他のポリシーでも同じような設定方法です。

 

フェイルオーバー

ヘルスチェックによってメインのサーバーが使用不可と判断されると、DNSの応答を次に優先度の高いサーバーに自動的に切り替えます。

 

フェイルオーバーの設定項目では「回答プール」というものを設定します。

回答プールを2つ以上作ります。

プールの中に応答するRDATA(AレコードであればIP)を登録します。

使用できるレコードタイプはA、AAAA、CNAMEの3種類です。

 

この回答プール毎に優先度がある形で、優先度が高い順に応答を返します。

例えばプール1から返せれば常にそれを応答し、ヘルスチェック失敗でNGと判定されればプール2から応答を返す、という感じです。

 

1つのプールの中にRDATAを複数登録することも可能ですが、重み付けは設定できないのでそのプール内からの回答はラウンドロビンになります。

 

ジオロケーション・ステアリング

リクエスト送信元のジオロケーションに基づいて、DNSの応答を動的に切り替えます。

 

選択できるレベルは大きく分けると「大陸」、「国とリージョン」です。

大陸はアジアやオセアニアなど、国とリージョンは日本や中国、ドイツなどの粒度です。

 

フェイルオーバー同様、2つ以上の回答プールを作成します。

その後、ルールでジオロケーションを指定し、そのルール中で優先プールを決定します。

例えば日本はプール1、プール2の順番で回答するが

中国はプール2、プール1の順番で回答する、という形です。

 

また、「グローバル・キャッチオール」というルールがあります。

これはどのルールにもマッチしなかった場合の回答ルールを定義するものです。

このルールがなかった場合は、回答がランダムになるようです。

 

ASNステアリング

リクエスト送信元のAS番号(6185など)に基づいて、DNSの応答を動的に切り替えます。

 

設定の仕方はジオロケーションとほぼ同様の設定方法です。

ルールでジオロケーションを指定していたところが、ASN指定に変更されているイメージです。

 

IP接頭辞ステアリング

リクエスト送信元のIPプレフィックス(172.16.1.0/24など)に基づいて、DNSの応答を動的に切り替えます。

 

これもジオロケーションやASNと同じ設定方法です。

ルールで送信元のサブネットアドレスを指定する形です。

 

プライベート・ビュー

これはプライベート・ゾーンを使用するときに使える機能です。

1つのゾーンは1つのプライベート・ビューにのみ紐づきます。

いわゆる「DNS View」と同じようなイメージで、同じレコードの問い合わせに対して特定のリゾルバへの応答は違う値を返したいときに使用します。

HTTPリダイレクト

HTTPトラフィックを別のURLにリダイレクトするための機能です。DNSは確かに使ってますが、メインはWebの機能な気がしますが…。

使い方の例としては以下のようなものが挙げられます。

  1. ゾーン全体のすべてのHTTPトラフィックを別のゾーンにリダイレクトする
  2. 特定のサブドメインをHTTP URLにリダイレクトする
  3. サブドメインをポート番号付きのURLにリダイレクトする

 

1)は会社がexample.netやexample.comを所有している場合、HTTPリダイレクトを使用すると(例えば)example.net宛のすべてのHTTPトラフィックをexample.comにリダイレクトさせることができます。

ただ、これは1対1の紐づけのみでワイルドカードは使用できないようです。

 

2)はたとえば、http://test.example.com宛のトラフィックをhttp://example.net/test/test.phpにリダイレクトさせるような使い方です。

 

3)はhttp://camera.example.com宛のトラフィックをhttp://office.example.com:8080にリダイレクトさせる形です。

接続先のポート番号が一般的でないような場合でもユーザーがあまり意識することなくページを表示させたい場合などに使用できます。

TSIGキー

TSIG (Transaction SIGnature)はDNSメッセージへの署名や送受信者の認証に使われるもので、RFC2845で定義されています。

 

共通鍵を使う仕組みであり、不特定の相手とのやりとりはできませんが、プライマリとセカンダリサーバ間のゾーン転送やNOTIFYのアクセス制限など、特定の相手とだけやりとりできればいい局面で利用されます。

 

OCIでは、パブリック・ゾーンのセカンダリサーバとして動かす際に使用することが可能です。

 

終わりに

今回はOCIでのDNSサービスをざっくりと紹介させていただきました。

 

個人的には「トラフィック管理ステアリング・ポリシー」はなかなか使い勝手が良い機能ではないかと思います。

Infobloxでも同じような機能がありますが、別ライセンスが必要でそこそこ良いお値段なのでOCIで要件が合えば導入のハードルも下がるのではと感じました。

 

次回以降で実際に設定して動作を見ていきたいと思います。