サブドメイン委任(Subdomain Delegation)

「本社と支社」で理解する、DNSの権限委譲のしくみ

独立した管理
サブドメインを別のホストゾーンで独立管理でき、親に影響を与えない
NSレコードで接続
親ドメインにNSレコードを設定するだけで委任が完了する
DNS解決は自動
クライアントはNSレコードをたどって自動的に正しいサーバーへ問い合わせる

本社と支社で理解するサブドメイン委任

サブドメイン委任は、大企業の本社が支社に業務を委任することと同じです。
本社の受付は「支社のことは支社に聞いてください」と案内し、
支社は独自に来訪者を対応します。

本社の受付
親ドメインのネームサーバー
(example.com の Hosted Zone)
支社の受付
サブドメインのネームサーバー
(staging.example.com の Hosted Zone)
来訪者
DNSクライアント
(Webブラウザやアプリケーション)
支社の連絡先リスト
NSレコード
(支社のネームサーバー一覧)

たとえ話の対応表

本社・支社のたとえ AWSの実際の概念
本社(example.com) 親ドメインの Hosted Zone
支社(staging部門) サブドメイン用の Hosted Zone(staging.example.com)
本社の受付デスク 親ドメインのネームサーバー(NS)
支社の受付デスク サブドメインのネームサーバー(NS)
本社に貼ってある「支社の連絡先」 親ドメインに設定するNSレコード
来訪者が支社の部屋番号を知る クライアントがIPアドレスを取得する

サブドメイン委任の全体像

親ドメインのホストゾーンにNSレコードを追加し、サブドメインの問い合わせを別のホストゾーンへ委任する構成です。

サブドメイン委任 — 構成とDNS解決フロー クライアント (来訪者) 親 Hosted Zone example.com NSレコード(委任用) staging → 子NS 子 Hosted Zone staging. example.com 親NSサーバー ns-xxx.awsdns- xx.com 子NSサーバー ns-yyy.awsdns- yy.com ① 問い合わせ ② 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レコードを追加して委任する。
Q: NSレコードとCNAMEの違いは?
→ NSレコードは「このドメインの権威サーバーはどこか」を示す。CNAMEは「このドメインの別名」を示す。委任にはNSレコードを使う。
Q: 親ゾーンにサブドメインのSOAレコードは必要?
→ 不要。SOAはサブドメインのHosted Zone内に自動生成される。親にはNSレコードのみ設定する。
Q: サブドメイン委任が正しく機能しない場合の原因は?
→ 親の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レコード追加
たとえるなら
本社の受付に「支社の連絡先」を掲示して、来訪者を支社に案内するのと同じ仕組み

Created by SSuzuki1063

AWS SAP Learning Resources