2026年6月8日

AWS Route 53 Resolver で名前を追加する方法｜プライベートホストゾーンのレコードと転送ルールの使い分け

DNS・名前解決

Route 53 Resolver は VPC の中で名前解決を担うリゾルバーで、それ自体にレコードを登録する場所はありません。VPC の中から引ける名前を増やしたいときは、引きたい名前が AWS 側のものならプライベートホストゾーンにレコードを追加し、社内ネットワーク（オンプレミス）の DNS が持っている名前なら Resolver の転送ルールを追加します。この記事では、この2つのやり方を AWS CLI の例つきで説明し、追加したのに引けないときの確認手順を、よくある原因の順に整理します。

Route 53 Resolver の役割を整理する

VPC 内の EC2 が名前を問い合わせると、通常は VPC に用意された DNS（VPC の IP 範囲の先頭から2番目のアドレス、または 169.254.169.253）が受け取ります。これが Route 53 Resolver です。Resolver は問い合わせを受けると、次の順で答えを探します。

転送ルールに一致するドメインなら、指定した DNS サーバーへ問い合わせを転送する
VPC に関連付けられたプライベートホストゾーンに一致すれば、そのレコードを返す
どちらにも当てはまらなければ、インターネット上の公開 DNS を再帰的に引く

厳密な優先順位は、ルールとゾーンのドメイン名の一致の長さなどで決まります（詳しくは AWS の公式ドキュメントの Resolver の説明を参照してください）。ここで押さえておきたいのは、「Resolver にレコードを追加する」という操作は存在せず、ゾーンにレコードを足すか、ルールで問い合わせ先を足すかのどちらかになる、ということです。

引きたい名前	追加するもの
RDS や EC2 に付ける内部名（db.internal.example.com など）	プライベートホストゾーンのレコード
社内 DNS が管理する名前（fileserver.corp.example など）	送信エンドポイントと転送ルール
社内から AWS の内部名を引かせたい	受信エンドポイント（社内 DNS 側で転送設定）

なお、本サイトの別記事「Route 53 のゾーン作成方法」ではプライベートホストゾーンそのものの作り方を扱っています。この記事は、ゾーンがすでにある前提で「名前を増やす」側に焦点を当てています。

方法1：プライベートホストゾーンにレコードを追加する

WordPress を EC2 で動かし、データベースに RDS を使っている構成を例にします。RDS のエンドポイント名は長く覚えにくいので、db.internal.example.com という CNAME を作っておくと、wp-config.php の DB_HOST を分かりやすい名前にでき、RDS を作り直したときもレコードの書き換えだけで済みます。

cat > add-db.json <<'EOF'
{
  "Comment": "WordPress DB alias",
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "db.internal.example.com",
      "Type": "CNAME",
      "TTL": 60,
      "ResourceRecords": [
        {"Value": "mydb.abcdefghijkl.ap-northeast-1.rds.amazonaws.com"}
      ]
    }
  }]
}
EOF

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0PRIVATEZONEID \
  --change-batch file://add-db.json

UPSERT は「なければ作り、あれば置き換える」動作です。既存のレコードを誤って上書きしないよう、実行前に aws route53 list-resource-record-sets --hosted-zone-id Z0PRIVATEZONEID で今の内容を確認しておきます。DB の向け先を切り替える可能性がある名前は、TTL を短めにしておくと切り替え後の反映が早くなります。

追加したら、VPC 内の EC2 から確認します。

dig db.internal.example.com +short

--hosted-zone-id には、目的の VPC に関連付けられたプライベートゾーンの ID を指定します。同じ名前のパブリックゾーンがある場合、間違えてそちらに追加すると、VPC の中からは引けないうえに、内部の構成が外部に見えてしまいます。ゾーン ID の取り違えには特に注意してください。

方法2：転送ルールで社内 DNS の名前を引けるようにする

社内 DNS が管理する corp.example のような名前を VPC 内から引くには、送信（アウトバウンド）エンドポイントと転送ルールを作ります。エンドポイントは VPC 内に置かれるネットワークインターフェースで、ここから社内 DNS へ問い合わせが送られます。社内ネットワークとは VPN や Direct Connect でつながっている必要があります。

# 1. 送信エンドポイントを作る（異なるサブネットに IP を2つ以上割り当てる）
aws route53resolver create-resolver-endpoint \
  --name corp-outbound \
  --creator-request-id "corp-outbound-$(date +%s)" \
  --direction OUTBOUND \
  --security-group-ids sg-0123456789abcdef0 \
  --ip-addresses SubnetId=subnet-aaaa1111 SubnetId=subnet-bbbb2222

# 2. corp.example を社内 DNS（10.10.0.53）へ転送するルールを作る
aws route53resolver create-resolver-rule \
  --name corp-forward \
  --creator-request-id "corp-forward-$(date +%s)" \
  --rule-type FORWARD \
  --domain-name corp.example \
  --resolver-endpoint-id rslvr-out-0123456789abcdef0 \
  --target-ips Ip=10.10.0.53,Port=53

# 3. ルールを VPC に関連付ける
aws route53resolver associate-resolver-rule \
  --resolver-rule-id rslvr-rr-0123456789abcdef0 \
  --vpc-id vpc-0123456789abcdef0

つまずきやすい点を挙げます。

ルールは作っただけでは効かない: 手順3の VPC への関連付けを忘れると、何も変わりません。
セキュリティグループ: 送信エンドポイントのセキュリティグループで、社内 DNS への UDP と TCP の 53 番ポートの通信を許可します。応答が大きいと TCP が使われるため、UDP だけでは一部の問い合わせが失敗します。
社内側のファイアウォール: 社内 DNS がエンドポイントの IP アドレスからの問い合わせを受け付けるよう、社内側の許可設定も必要です。
エンドポイントの費用: エンドポイントは作成している間、継続的に費用が発生します。料金体系は AWS の料金ページで確認してください（2026年10月現在）。

複数の AWS アカウントで同じルールを使いたい場合は、AWS Resource Access Manager でルールを共有する方法があります。比較的新しい機能として Route 53 Profiles を使い、DNS の設定をまとめて複数の VPC に適用する方法も提供されています。どちらが合うかは組織の構成によるため、公式ドキュメントで対応状況を確認してから選んでください。

逆方向：社内から AWS の内部名を引かせる

社内の端末から db.internal.example.com などを引きたい場合は、受信（インバウンド）エンドポイントを作り、社内 DNS に「internal.example.com はこの IP アドレスへ転送する」という条件付き転送を設定します。作成は create-resolver-endpoint で --direction INBOUND を指定する以外、送信エンドポイントとほぼ同じです。セキュリティグループでは、社内ネットワークからの 53 番ポートへの受信を許可します。

追加したのに引けないときの確認手順

よくある原因の順に確認します。

1. 別のゾーンに追加している同じ名前のゾーンがパブリックとプライベートに一つずつ、あるいはプライベートが複数あることがあります。aws route53 list-hosted-zones-by-name --dns-name internal.example.com で一覧し、追加先が目的の VPC に関連付けられたゾーンかを、aws route53 get-hosted-zone --id の出力にある VPC の情報で確かめます。

2. VPC の DNS 設定が無効になっているVPC の DNS 解決と DNS ホスト名の属性が無効だと、プライベートゾーンは使われません。aws ec2 describe-vpc-attribute で両方を確認します。

3. インスタンスが Route 53 Resolver を使っていないDHCP オプションセットで独自の DNS サーバーを指定していると、EC2 は Resolver ではなくそのサーバーへ問い合わせます。EC2 上で /etc/resolv.conf（systemd-resolved を使う環境では resolvectl status）を見て、問い合わせ先を確認します。

4. 転送ルールが関連付けられていない、または通信が遮断されているaws route53resolver list-resolver-rule-associations で VPC への関連付けを確認します。関連付けがあるのに応答がない場合は、エンドポイントのセキュリティグループと社内側のファイアウォールを見直します。

5. 古い答えがキャッシュに残っているレコードを変えた直後は、Resolver やインスタンス側のキャッシュが TTL の間だけ古い答えを返します。TTL の時間を待つか、変更を予定している名前は前もって TTL を短くしておきます。

原因の切り分けには、Resolver のクエリログが役立ちます。クエリログを有効にすると、VPC 内からの問い合わせと応答を CloudWatch Logs や S3 に記録できるため、「問い合わせが Resolver に届いているか」「どんな応答を返したか」を確認できます。ログの保存にも費用がかかるので、調査の期間だけ有効にする運用も検討してください。

まとめ

Route 53 Resolver は VPC 内のリゾルバーで、レコードを直接登録する場所はありません。名前を増やすには、ゾーンにレコードを足すか、転送ルールで問い合わせ先を足します。
AWS 側の内部名はプライベートホストゾーンに追加し、ゾーン ID の取り違えに注意します。
社内 DNS の名前は送信エンドポイントと転送ルールで引けるようにし、ルールの VPC への関連付けと 53 番ポートの UDP・TCP の許可を忘れないようにします。
引けないときは、ゾーンの取り違え、VPC の DNS 設定、DHCP オプション、ルールの関連付けと通信、キャッシュの順に確認し、必要に応じてクエリログで裏付けを取ります。