ConoHa DNS と AWS Route 53 Resolver を比較する｜ConoHa VPS と AWS を併用するときの名前解決の分担

ConoHa DNS と AWS Route 53 Resolver は、どちらか一方を選ぶものではありません。ConoHa DNS はドメインの答えをインターネットに返す「権威 DNS」で、Route 53 Resolver は AWS の VPC 内のサーバーが名前を引くための「リゾルバー」です。比較が必要になるのは、ConoHa VPS で WordPress を動かしながら、データベースやバッチ処理などの一部を AWS に置く、といった併用の場面です。

この記事では、両者の役割の違いを確認したうえで、ConoHa と AWS を併用するときに「公開する名前」「AWS の中だけで使う名前」「ConoHa から AWS の内部の名前を引く方法」をどう分担するかを説明します。同じ「権威 DNS と Route 53 Resolver の比較」でも、大規模な振り分け機能を持つ NS1 との比較は別の記事で扱っており、この記事は ConoHa VPS を使う小〜中規模の構成に絞っています。各社の仕様や画面は変わることがあるため（2026年10月現在）、実際の設定は公式ドキュメントで確認してください。

役割の違いを先に整理する

ConoHa DNS は、ConoHa の利用者が自分のドメインのレコード（A・CNAME・MX・TXT など）を管理するためのものです。ConoHa VPS で使う DNS には API も用意されており、レコードをプログラムから変更できます。ただし VPS のバージョンによって API の仕様が異なるため、使っている環境向けのドキュメントを確認してください。

Route 53 Resolver は、AWS で VPC を作ると自動で使える DNS です。VPC 内の EC2 や Lambda は、通常この Resolver に問い合わせます。外部の DNS へ問い合わせを転送するアウトバウンドエンドポイント、外部から VPC 内の名前を引くためのインバウンドエンドポイント、問い合わせを遮断する DNS Firewall、問い合わせを記録するクエリログといった機能があります。

公開 DNS としての比較をしたいのであれば、ConoHa DNS の比較相手は Route 53 のパブリックホストゾーンです。Route 53 Resolver はネームサーバーとして登録できないため、公開 DNS の代わりにはなりません。

併用構成での分担

ConoHa VPS で WordPress を動かし、AWS に一部の機能を置く構成を例にします。

• 公開する名前（example.com、www.example.com）: ConoHa DNS で管理します。WordPress のサーバーである ConoHa VPS の IP を A レコードで返します。
• AWS の中だけで使う名前（db.internal.example.com など）: Route 53 のプライベートホストゾーンで管理し、VPC に関連付けます。VPC 内の Resolver がこの名前に答えます。
• ConoHa VPS から AWS の内部の名前を引く: VPN で ConoHa VPS と VPC をつなぎ、Route 53 Resolver のインバウンドエンドポイントへ問い合わせを転送します。

AWS のサーバーからは、公開する名前を Route 53 Resolver 経由で引けます。Resolver はインターネット経由で ConoHa DNS に問い合わせるので、追加の設定は要りません。

名前空間を分ける理由

AWS 側だけで使う名前を、公開ゾーンと同じ example.com の中に作ろうとすると問題が起きます。VPC に example.com のプライベートホストゾーンを関連付けると、VPC 内からは example.com 全体がプライベートホストゾーンで答えられるようになり、プライベート側に登録していない www.example.com などが VPC 内から引けなくなることがあります。

これを避けるため、プライベートホストゾーンは internal.example.com のようなサブドメインにして、公開ゾーンと重ならないようにします。ConoHa DNS の公開ゾーンには internal.example.com のレコードを置かず、内部の名前が外から見えないようにしておきます。

ConoHa VPS から AWS の内部の名前を引く手順

ConoHa VPS と AWS の VPC は、そのままでは別々のネットワークです。インバウンドエンドポイントは VPC 内のプライベート IP で待ち受けるため、ConoHa VPS から使うには VPN などでネットワークをつなぐ必要があります。インバウンドエンドポイントをインターネットに直接公開する使い方はしません。

1. VPN でネットワークをつなぐ

AWS 側では Site-to-Site VPN、ConoHa VPS 側では strongSwan などの IPsec ソフトウェアを使う構成が一般的です。VPN が確立したら、ConoHa VPS から VPC 内のプライベート IP に到達できることを先に確認します。DNS の設定は、ネットワークの疎通が取れてから行います。

2. インバウンドエンドポイントを作る

インバウンドエンドポイントには、2つ以上の IP アドレス（できれば別々のアベイラビリティーゾーンのサブネット）を割り当てます。セキュリティグループでは、VPN 経由の ConoHa VPS の送信元アドレスから、UDP と TCP の 53 番ポートへの通信を許可します。大きな応答は TCP で返るため、UDP だけを許可すると一部の問い合わせが失敗します。

# インバウンドエンドポイントの作成例（IDやサブネットは自分の環境に置き換え）
aws route53resolver create-resolver-endpoint \
  --name inbound-from-conoha \
  --creator-request-id inbound-from-conoha-001 \
  --direction INBOUND \
  --security-group-ids sg-0123456789abcdef0 \
  --ip-addresses SubnetId=subnet-aaaa1111 SubnetId=subnet-bbbb2222

# 割り当てられたIPアドレスの確認
aws route53resolver list-resolver-endpoint-ip-addresses \
  --resolver-endpoint-id rslvr-in-0123456789abcdef0

エンドポイントは時間単位で課金されるため、検証が終わったら不要なものは削除してください。

3. ConoHa VPS 側で転送を設定する

ConoHa VPS の OS で、internal.example.com の問い合わせだけをインバウンドエンドポイントへ送り、それ以外は通常どおり解決するように設定します。ここでは Unbound を使う例を示します。

# /etc/unbound/unbound.conf.d/forward-aws.conf の例
server:
    # 内部ゾーンのため、DNSSEC 検証の対象から外す
    domain-insecure: "internal.example.com."
    # 内部アドレスの応答を許可する
    private-domain: "internal.example.com."

forward-zone:
    name: "internal.example.com."
    forward-addr: 10.0.1.10   # インバウンドエンドポイントのIP（1つ目）
    forward-addr: 10.0.2.10   # インバウンドエンドポイントのIP（2つ目）

設定ファイルの文法を確認してから Unbound を再起動し、OS のリゾルバー設定が Unbound（127.0.0.1）を参照していることを確かめます。Ubuntu などで systemd-resolved が動いている場合は、Unbound と 53 番ポートが競合しないように構成を確認してください。設定を変える前に、現在の設定ファイルをバックアップしておきます。

sudo unbound-checkconf
sudo systemctl restart unbound

# ConoHa VPS から内部の名前と公開の名前を引いて確認する
dig +short @127.0.0.1 db.internal.example.com A
dig +short @127.0.0.1 www.example.com A

1つ目で VPC 内のプライベート IP が、2つ目で ConoHa VPS の公開 IP が返れば、分担どおりに動いています。

逆方向: AWS から ConoHa 側の内部の名前を引く場合

ConoHa VPS 側に社内向けの DNS サーバー（BIND など）を置いていて、その名前を AWS から引きたい場合は、Route 53 Resolver のアウトバウンドエンドポイントと転送ルールを使います。転送先には VPN 経由で到達できる ConoHa VPS のプライベート側の IP を指定し、転送ルールを VPC に関連付けます。公開している ConoHa DNS の名前を引くだけなら、この設定は要りません。

つまずきやすい点

• VPN が切れると内部の名前が引けなくなる: 転送先に到達できないと、問い合わせはタイムアウトします。WordPress から AWS 上のデータベースに名前で接続している場合、VPN の切断がそのまま接続エラーになります。VPN の監視をあわせて設定してください。
• ConoHa DNS の変更が AWS 側にすぐ反映されない: Route 53 Resolver はレコードの TTL の間、答えをキャッシュします。変更前に TTL を短くしておくと、切り替えが早く済みます。
• 費用の見落とし: Route 53 Resolver のエンドポイントや Site-to-Site VPN には利用料がかかります。併用が小規模なら、名前ではなく固定のプライベート IP で接続する、という単純な構成で足りる場合もあります。

まとめ

• ConoHa DNS は公開用の権威 DNS、Route 53 Resolver は VPC 用のリゾルバーで、役割が異なります。公開 DNS として比べるなら、相手は Route 53 のパブリックホストゾーンです。
• 併用するときは、公開する名前を ConoHa DNS、AWS 内だけの名前をプライベートホストゾーンに分け、名前空間を重ねないようにします。
• ConoHa VPS から AWS の内部の名前を引くには、VPN でつないだうえで、インバウンドエンドポイントへ転送します。UDP と TCP の 53 番を許可します。
• 逆方向はアウトバウンドエンドポイントと転送ルールで設定します。
• VPN の監視、TTL、エンドポイントの費用も含めて、構成が本当に必要かを判断してください。

• ConoHa DNS でレコードを追加する手順｜A・CNAME・MX・TXT の入れ方と、反映されないときの確認
• AWS Route 53 Resolver で名前を追加する方法｜プライベートホストゾーンのレコードと転送ルールの使い分け