サブドメイン委任(Subdomain Delegation)
「本社と支社」で理解する、DNSの権限委譲のしくみ
独立した管理
サブドメインを別のホストゾーンで独立管理でき、親に影響を与えない
NSレコードで接続
親ドメインにNSレコードを設定するだけで委任が完了する
DNS解決は自動
クライアントはNSレコードをたどって自動的に正しいサーバーへ問い合わせる
本社と支社で理解するサブドメイン委任
サブドメイン委任は、大企業の本社が支社に業務を委任することと同じです。
本社の受付は「支社のことは支社に聞いてください」と案内し、
支社は独自に来訪者を対応します。
本社の受付
親ドメインのネームサーバー
(example.com の Hosted Zone)
(example.com の Hosted Zone)
支社の受付
サブドメインのネームサーバー
(staging.example.com の Hosted Zone)
(staging.example.com の Hosted Zone)
来訪者
DNSクライアント
(Webブラウザやアプリケーション)
(Webブラウザやアプリケーション)
支社の連絡先リスト
NSレコード
(支社のネームサーバー一覧)
(支社のネームサーバー一覧)
たとえ話の対応表
| 本社・支社のたとえ | AWSの実際の概念 |
|---|---|
| 本社(example.com) | 親ドメインの Hosted Zone |
| 支社(staging部門) | サブドメイン用の Hosted Zone(staging.example.com) |
| 本社の受付デスク | 親ドメインのネームサーバー(NS) |
| 支社の受付デスク | サブドメインのネームサーバー(NS) |
| 本社に貼ってある「支社の連絡先」 | 親ドメインに設定するNSレコード |
| 来訪者が支社の部屋番号を知る | クライアントがIPアドレスを取得する |
サブドメイン委任の全体像
親ドメインのホストゾーンにNSレコードを追加し、サブドメインの問い合わせを別のホストゾーンへ委任する構成です。
サブドメイン委任の設定プロセス
必要な作業はたった2ステップです。「支社を設立し、本社に連絡先を掲示する」だけで完了します。
1
サブドメイン用ホストゾーンを作成
Route 53 で staging.example.com の Hosted Zone を新規作成します。作成すると、AWSが自動的にNSレコードとSOAレコードを割り当てます。
新しい支社を開設し、支社専用の受付デスクと電話番号を用意する段階です。
2
親ドメインにNSレコードを追加
親の Hosted Zone(example.com)に staging.example.com のNSレコードを作成し、値にはステップ1で割り当てられたネームサーバーのリストを設定します。
本社の受付に「staging部門の問い合わせは支社(電話番号: xxx)へ」と案内板を設置する段階です。
設定コマンド例
# ステップ1: サブドメイン用ホストゾーンを作成
aws route53 create-hosted-zone \
--name staging.example.com \
--caller-reference "staging-$(date +%s)"
# → レスポンスからNSレコードの値を確認
# "NameServers": [
# "ns-111.awsdns-11.com",
# "ns-222.awsdns-22.net",
# "ns-333.awsdns-33.co.uk",
# "ns-444.awsdns-44.org"
# ]
# ステップ2: 親ドメインにNSレコードを追加
aws route53 change-resource-record-sets \
--hosted-zone-id Z_PARENT_ZONE_ID \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "staging.example.com",
"Type": "NS",
"TTL": 300,
"ResourceRecords": [
{"Value": "ns-111.awsdns-11.com"},
{"Value": "ns-222.awsdns-22.net"},
{"Value": "ns-333.awsdns-33.co.uk"},
{"Value": "ns-444.awsdns-44.org"}
]
}
}]
}'
# CloudFormation テンプレート
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Subdomain Delegation Setup'
Resources:
# ステップ1: サブドメイン用ホストゾーン
StagingHostedZone:
Type: AWS::Route53::HostedZone
Properties:
Name: staging.example.com
# ステップ2: 親ドメインにNSレコードを追加
DelegationNSRecord:
Type: AWS::Route53::RecordSet
Properties:
HostedZoneId: Z_PARENT_ZONE_ID
Name: staging.example.com
Type: NS
TTL: '300'
ResourceRecords:
- !GetAtt StagingHostedZone.NameServers.0
- !GetAtt StagingHostedZone.NameServers.1
- !GetAtt StagingHostedZone.NameServers.2
- !GetAtt StagingHostedZone.NameServers.3
DNS解決のステップバイステップ
クライアントが staging.example.com にアクセスするとき、DNSはどのように解決されるのかを追いかけてみましょう。
クライアントが親ドメインのNSに問い合わせ
クライアントが「staging.example.com のIPアドレスを教えてください」と、まず example.com のネームサーバーに問い合わせます。
親NSが「サブドメインの管轄は別です」と応答
example.com のNSは、staging.example.com のNSレコードを返します。これは「そのサブドメインは別のネームサーバーが管理しています」という参照応答(referral)です。
クライアントがサブドメインのNSに再問い合わせ
クライアントは教えられたサブドメイン用のネームサーバーに対して、改めて「staging.example.com のIPアドレスを教えてください」と問い合わせます。
サブドメインNSがIPアドレスを返却
staging.example.com のネームサーバーが、目的のリソースのIPアドレス(Aレコード)やCNAMEなどを返し、クライアントはリソースにアクセスできるようになります。
サブドメイン委任 あり vs なし
委任あり(別 Hosted Zone)
サブドメインのDNSレコードを独立して管理でき、親への影響ゼロ
チームごとに異なるAWSアカウントで管理できる
サブドメイン管理者が自由にレコードを作成・変更・削除できる
環境ごと(dev / staging / prod)の分離が容易
委任なし(同一 Hosted Zone)
すべてのレコードを1つのホストゾーンで管理するため混雑しやすい
サブドメインの変更にも親ゾーンの管理権限が必要
チーム間でIAMポリシーの細かい分離が困難
小規模な構成ではシンプルで管理コストが低い
こんなときにサブドメイン委任を使う
マルチ環境の分離
dev.example.com、staging.example.com、prod.example.com をそれぞれ独立したHosted Zoneで管理
チーム別のDNS管理
各チームが担当サブドメインを独自のAWSアカウントで管理し、親への依存を排除
マルチリージョン構成
リージョン別のサブドメイン(us.example.com, ap.example.com)を各リージョンのアカウントに委任
組織統合・M&A
買収した企業のドメインをサブドメインとして統合しつつ、DNS管理は委任して独立性を維持
運用のベストプラクティス
NSレコードの値を正確にコピーする
サブドメインのHosted Zone作成時に割り当てられたNSの値を、親のNSレコードに正確にコピーしましょう。1文字でも違うと解決に失敗します。
TTL を適切に設定する
NSレコードのTTLは 172800(48時間)や 86400(24時間)が一般的です。短くしすぎるとDNS問い合わせが増え、長すぎると変更の反映が遅れます。
SOAレコードは編集しない
親ゾーンに作成するのはNSレコードだけです。SOAレコードはサブドメインのHosted Zone内に自動作成されるので、親側には不要です。
dig コマンドで委任を確認する
dig staging.example.com NS を実行し、サブドメインのNSが正しく返されるか必ず検証しましょう。
AWS認定試験で狙われるポイント
Q: サブドメインを別アカウントで管理するには?
→ サブドメイン用のHosted Zoneを別アカウントで作成し、親のHosted ZoneにNSレコードを追加して委任する。
→ サブドメイン用のHosted Zoneを別アカウントで作成し、親のHosted ZoneにNSレコードを追加して委任する。
Q: NSレコードとCNAMEの違いは?
→ NSレコードは「このドメインの権威サーバーはどこか」を示す。CNAMEは「このドメインの別名」を示す。委任にはNSレコードを使う。
→ NSレコードは「このドメインの権威サーバーはどこか」を示す。CNAMEは「このドメインの別名」を示す。委任にはNSレコードを使う。
Q: 親ゾーンにサブドメインのSOAレコードは必要?
→ 不要。SOAはサブドメインのHosted Zone内に自動生成される。親にはNSレコードのみ設定する。
→ 不要。SOAはサブドメインのHosted Zone内に自動生成される。親にはNSレコードのみ設定する。
Q: サブドメイン委任が正しく機能しない場合の原因は?
→ 親のNSレコードの値が、サブドメインHosted Zoneの実際のNSと一致していないことが最も多い原因。
→ 親のNSレコードの値が、サブドメインHosted Zoneの実際のNSと一致していないことが最も多い原因。
よくある質問
Route 53のHosted Zone料金(月額 $0.50/ゾーン)とクエリ料金が追加で発生します。サブドメイン用にHosted Zoneを作成するため、親とは別に1つ分の料金がかかります。小規模な構成ではコスト面も考慮して、同一Hosted Zoneでの管理を検討してもよいでしょう。
CNAMEは1つのドメイン名を別のドメイン名にマッピングするレコードですが、ゾーンの頂点(Zone Apex)には使えません。サブドメイン委任はNSレコードでDNS管理権限そのものを別のサーバーに移すため、サブドメイン配下のすべてのレコードが独立して管理できます。「名前の転送」ではなく「管理権の委譲」という根本的な違いがあります。
はい、まさにそれがサブドメイン委任の大きなメリットです。子アカウントでHosted Zoneを作成し、そのNS値を親アカウントのHosted Zoneに設定するだけです。AWS Organizationsとの組み合わせで、マルチアカウント戦略の一部として広く使われています。
親ドメインのHosted Zoneから、サブドメインのNSレコードを削除するだけです。削除後はTTLの期間が過ぎれば、キャッシュが消えて委任は解除されます。サブドメインのHosted Zoneも不要であれば削除します。
はい、可能です。例えば staging.example.com に対してさらに api.staging.example.com を別のHosted Zoneに委任できます。仕組みは同じで、staging.example.com のHosted Zoneに api.staging.example.com のNSレコードを追加します。ただし、階層が深くなるとDNS解決のレイテンシーが増えるため、設計には注意が必要です。
まとめ
仕組み
親ドメインのHosted ZoneにNSレコードを追加し、サブドメインのDNS管理を別のHosted Zoneに委任する
設定は2ステップ
① サブドメイン用Hosted Zone作成 → ② 親のHosted ZoneにNSレコード追加
たとえるなら
本社の受付に「支社の連絡先」を掲示して、来訪者を支社に案内するのと同じ仕組み