【Oracle Cloud】転送エンドポイント + NLB でDNSフェイルオーバーを実現する方法

ブログ

2026.06.10

こんにちは、k.katoです。

今回は、OCIからオンプレミスのDNSサーバーへ名前解決を行う際に、転送エンドポイントとNLB（ネットワーク・ロード・バランサー）を組み合わせることで、DNSフェイルオーバーを実現する方法をご紹介します。

転送エンドポイントは、OCIからのDNSクエリを特定のIPアドレスに転送するサービスです。
転送エンドポイントを使って、どの条件でDNSクエリを転送するかルールを設定できますが、もし転送先のDNSサーバーが2台ある場合はどうでしょうか？

おそらく、このように設定したくなるはずです。

同じドメインに対して、転送先を2つ設定しようとするものですが、
ノートにも書いてある通り、このルールで構成したとしても最初のルールしか適用されず、2台目のDNSサーバーへフェイルオーバーされません。

それを解決する方法として、例えば以下のような方法が挙げられます。

オンプレ側のVIPを転送先の宛先IPアドレスとして登録する

NLBのバックエンドとしてオンプレのDNSサーバーを構成し、NLBのIPアドレスを転送先の宛先IPアドレスとして登録する。

タイトルにもある通り、今回は②の方法をご紹介します。

参照:
OCIプライベートDNS – ベストプラクティス

1 構成図
2 DNSサーバーの構成
3 NLBの作成
4 転送エンドポイントの作成
5 検証
6 終わりに

構成図

今回検証として構築する構成図は以下の通りです。

Server1から、転送エンドポイント、NLB、DRGを経由して、DNSサーバーに名前解決を依頼する構成です。

今回の検証では、オンプレミス環境の代わりにVCN2を使用していますが、
オンプレミス環境のDNSサーバーの代わりにVCN2のDNSサーバーを使用するだけですので、構成自体は同じです。

VCN・サブネット、DRG、NSGなどの作成・設定手順は本題ではないため省略します。
今回は、DNSサーバーの構成、転送エンドポイント、NLBの設定方法に焦点を当ててご紹介します。

DNSサーバーの構成

DNSサーバー用のインスタンスを2台、Oracle Linux 9で作成し、VCN2上に構築しました。

DNSサーバーにはexample.comとtest.comの2つのゾーンを作成します。

ログを取る際にヘルスチェックのログが混在してしまうため、example.comをヘルスチェック用、test.comを動作確認用として使い分けます。

また、検証のためTTLは3秒と短めに設定しています。

それぞれ、

oci.example.com というサブドメインに対して Aレコード：111.111.111.111
oci.test.com というサブドメインに対して Aレコード：222.222.222.222

を名前解決できるようにしました。

DNSサーバーの設定手順は本題ではないため、設定手順は「詳細を見る」からご確認ください。

▶
詳細を見る

DNSサーバーとして動かしたいので、SSH接続し、以下のコマンドを実行します。
まずはDNS1のサーバーから行います。DNS2のサーバーでも同じことを繰り返します。

# BINDインストール
sudo dnf install bind bind-utils -y
# 起動・自動起動設定
sudo systemctl enable named --now

インストールが完了したら、設定ファイルを編集していきます。

なお、今回は2つのゾーン（example.com , test.com）を作成します。

# ゾーンファイルの作成
sudo vi /var/named/example.com.zone

options {
    listen-on port 53 { any; };
    listen-on-v6 port 53 { any; };
    directory       "/var/named";
    allow-query     { any; };
    recursion yes;
};
zone "example.com" IN {
    type master;
    file "/var/named/example.com.zone";
};
zone "test.com" IN {
    type master;
    file "/var/named/test.com.zone";
};

ゾーンファイルを作っていきます。

まずはexample.comからです。

ns1の部分はDNSサーバーのIPを記入します。

サブドメインはociとし、Aレコードは検証用のため、わかりやすい 111.111.111.111 としています。

# ゾーンファイルの作成
sudo vi /var/named/example.com.zone

$TTL 300
@   IN  SOA ns1.example.com. admin.example.com. (
        2024010101  ; Serial
        3600        ; Refresh
        900         ; Retry
        604800      ; Expire
        300 )       ; Minimum TTL
@       IN  NS   ns1.example.com.
ns1     IN  A    192.168.0.168
oci     IN  A    111.111.111.111

次にtest.comですね。

ns1の部分はDNSサーバーのIPを記入します。

サブドメインはociとし、Aレコードも同様に、わかりやすい 222.222.222.222 としましょう。

このドメインを検証で問い合わせるため、TTLは3秒と非常に短くしています。

# ゾーンファイルの作成
sudo vi /etc/named/test.com.zone

$TTL 3
@   IN  SOA ns1.test.com. admin.test.com. (
        2024010101  ; Serial
        3600        ; Refresh
        900         ; Retry
        604800      ; Expire
        300 )       ; Minimum TTL
@       IN  NS   ns1.test.com.
ns1     IN  A    192.168.0.88
oci     IN  A    222.222.222.222

完了です！これで構文チェックと再起動を行い、設定を反映させましょう。

# 設定ファイルの構文チェック
sudo named-checkconf
sudo named-checkzone example.com /var/named/example.com.zone
sudo named-checkzone test.com /var/named/test.com.zone
# 反映
sudo systemctl restart named

最後に、OSのファイアウォールは切っておきましょう。

# firewalld無効化
sudo systemctl disable firewalld --now

DNS2にも同じ手順で設定します。ns1のIPアドレスをDNS2のIPアドレスに変更するだけで大丈夫です。

NLBの作成

続いて、NLBを作成します。

NLBのバックエンドにIPアドレスでサーバーを指定するには、送信元IPアドレスの変換が必要です。
そのため、ソースIPの保持をOFFにする必要があります。OFFにしないとIPアドレスでバックエンドを指定できないため、注意してください。

1.
外部に公開しないため可視性のタイプは「プライベート」を選択します。

2.
リスナーのプロトコルとポートは「TCP・UDP」で、ポートは「53」にします。

3.
「ソースIPの保持」はOFFにしてから、「バックエンドの追加」をクリックします。

4.
バックエンドの「追加先」は「IPアドレス」を選択し、DNSサーバーのプライベートIPアドレスを入力します。

5.
バックエンドのヘルスチェックは「DNS」、問い合わせドメインはoci.example.comにしておきます。レスポンスコードは "NO ERROR" で判定するようにしましょう。問い合わせに成功したことだけをもって正常と判定します。

6.
ロード・バランシング・ポリシーは負荷分散させたければ、5タプル・ハッシュを選択しましょう。バックエンドを固定させたい場合は、2タプルを選びます。

7.
これで作成をクリックします。NLBからのヘルスチェックが通るように、セキュリティ・リストまたはNSGを設定しておきましょう。

NLBの名前・可視性タイプ（プライベート）・VCN・サブネットを設定する

NSGをアタッチし、プライベートIPアドレスの割り当て方法を選択する

リスナーのプロトコルは「UDP/TCP」、ポートは「53」を指定する

ソースIPの保持をOFFにしてから「バックエンドの追加」をクリック

バックエンド・タイプは「IPアドレス」を選択し、DNSサーバーのIPを入力する

ヘルスチェックのプロトコルは「DNS」、問合せ名・レスポンスコードを設定する

ロード・バランシング・ポリシーを選択して作成する

NLBが「アクティブ」になる

バックエンド・セットのヘルスがOKになっていることを確認する

転送エンドポイントの作成

続いて、転送エンドポイントを作成します。

1.
DNSリゾルバの「エンドポイント」タブから転送タイプのエンドポイントを作成します。事前に作成しておいたNSGをアタッチします。

2.
続いて、「ルール」タブからルールを作成します。

3.
入力するのは、ドメイン名でも、FQDN(oci.test.comなど)でも構いません。

4.
宛先には、NLBのプライベートIPアドレスを指定します。

VCNに紐づくプライベート・リゾルバを開く

「エンドポイント」タブから「エンドポイントの作成」をクリック

ポリシー・タイプは「転送」を選択し、NSGをアタッチする

「ルール」タブを開き、「ルールの管理」をクリック

「ルールの追加」からドメインと宛先IPアドレス（NLBのIP）を入力する

入力が完了したら「ルールの追加」をクリックして保存

ルールが作成され、転送設定が完成した状態

検証

Server1からDNSクエリを投げてみる

では、Server1から名前解決をしてみましょう。
tcpdumpで53番ポートのトラフィックをキャプチャし、FQDNの問い合わせに対してIPアドレス「222.222.222.222」が返ってくることを確認します。DNSサーバー側では以下のコマンドでキャプチャします。

sudo tcpdump -l -i any port 53 | grep 222.222.222.222

今からDNSクエリを投げてみます。nslookupでも構いません。

DNS2のサーバーに行きましたね。

今度はDNS1のサーバーに振り分けられたことがわかります。

想定通り、DNS1とDNS2のサーバーに交互に振り分けられています。

DNS2を止めてみる

では、DNS2のサーバーを止めてみましょう。これでDNS1のサーバーのみに問い合わせがいくはずです。

DNS2を停止しました。

NLBのヘルスチェックもDNS2がクリティカルになっています。

Server1からはDNS1しか見えなくなりました。

Server1からはDNS1にしか問い合わせがいきません。

2回目もDNS1にしか問い合わせがいきません。

3回目もDNS1にしか問い合わせがいきません。

想定通りの挙動になっていますね！
画像にはありませんが、再びDNSサーバーを起動させると、DNS2の方に問い合わせがいくようになったことを確認済みです。

終わりに

ここまで読んでいただき、ありがとうございました。

AWSにもOCIの転送エンドポイントと同様のサービスである「Route53リゾルバエンドポイント」というサービスがありますが、
こちらでは複数のDNSサーバーの宛先IPを登録できるようです。

参照:
Route 53リゾルバーエンドポイントを使用してDNSの高可用性を実現する方法

Azureでも、転送エンドポイントと同様のサービスである「送信エンドポイント」というサービスがあり、
こちらも複数のDNSサーバーの宛先IPアドレスを指定することが可能です。

参照:
Azure DNS プライベートリゾルバーのエンドポイントとルールセット

OCIで同様のことをするには今回のような構成にしなければなりませんが、転送エンドポイントとNLBはいずれも無料のリソースです（2026/06時点）。無料の範囲内で高可用性を実現できる点はOCIの魅力の一つではないでしょうか。

以上です！お役に立てましたら幸いです。

この記事を書いた人

k.kato

この執筆者の記事一覧