普段何気なく使っているドメインですが、レジストラと権威DNSの関係性を理解しておくと様々な場面で柔軟な対応ができるようになります。私自身、この仕組みを理解したことで、複数プロジェクトのドメイン管理がスムーズになりました。
DNS について以下では DNS レジストラ（登録管理） と 権威 DNS ホスティング（名前解決） を切り分け、そのうえで実務でよく使う3つの構成パターンを紹介します。
- ドメインを お名前.com で登録したまま Route 53 を権威 DNS として使う（最もよくあるケース）
- ドメインを Route 53（AWS）で登録し、名前解決だけ お名前.com DNS に任せる
- サブドメイン単位で片方に再帰委任する
お名前.com でドメインを取得するメリットは以下の通りです。
- 安い
- 顧客でも簡単に取得できる
会社で安く取得したドメインを使いやすい Route53 に移譲するというパターンが多いかと思います。
0. そもそも「移譲（Delegation）」とは
DNS移譲は意外とシンプルな概念です。簡単に言うと：
- 親ゾーン ⇒ 子ゾーンの NS レコード を書き換えて、「この名前空間の正解はあちらで聞いてね」と公告すること。
- 通常の「ドメイン移管（Transfer）」＝レジストラの変更とは別物。今回は registrar を変えずに 名前解決だけ切り替えるイメージです。
私がこの仕組みに注目したのは、更新タイミングが異なるドメインを同じDNS管理下に置きたいときでした。移管手続きの手間を省きつつ、管理を一元化できる点が大きなメリットです。
1. レジストラ＝お名前.com → 権威 DNS＝Route 53
これは最もよくあるパターンで、私のプロジェクトでもよく使っています。お名前.comで取得した既存ドメインをAWSの各種サービスで使いたい場合に便利です。
流れ
| ステップ | 目的 | 操作場所 | 具体的操作 |
|---|---|---|---|
| 1 | Route 53 で "ホストゾーン" を作成 | AWS Console | example.com を Public Hosted Zone で作成 ⇒ 4 つの NS 値（例: ns-123.awsdns-45.net 等）が払い出される |
| 2 | SOA/NS 以外のレコードを Route 53 に追加 | AWS Console | A/AAAA, MX, TXT, CNAME など必要なレコードを作る |
| 3 | お名前.com 側で NS を書き換え | お名前.com ドメインNavi | 「ネームサーバー変更」→「その他を使う」→ 上記 4 つをコピペ |
| 4 | 伝播確認 | dig, whois 等 | TLD キャッシュ TTL（.com で最長 48h）を待って確認 |
仕組みポイント
- 書き換え後は TLD (.com) が返す NS が Route 53 になるので、世界中のリゾルバは最初から AWS へ問い合わせる。
- レジストラはあくまでお名前.com のまま（更新料もそちら）。
実際の開発現場では、この手順をCLIでスクリプト化しておくと、新規プロジェクト立ち上げ時に数分で環境構築ができるようになります。
2. レジストラ＝Route 53 → 権威 DNS＝お名前.com
これは少し珍しいケースですが、例えば「AWS でドメインを取得したが社内標準がお名前.comのFreeDNS」といった理由で名前解決だけ移したいときに使います。
| ステップ | 目的 | 操作場所 | 具体的操作 |
|---|---|---|---|
| 1 | お名前.com DNS でゾーンを作成 | onamae.com 管理画面 | "DNS"→"ZONE 設定"で example.com 追加。NS 値（ns01.onamae.com, ns02.onamae.com）を控える |
| 2 | Route 53 ドメイン登録画面で NS を書き換え | AWS → Route 53 → Registered domains | "Add/Edit name servers" に上記 2 件を入力し保存 |
| 3 | 再帰伝播を待つ | dig, whois 等 | TLD キャッシュが更新されると、以後は onamae DNS に到達 |
注意
- AWS 側に「Hosted Zone」が残っていても参照されなくなるため、混乱防止に 削除 か private zone 化 する。
- お名前.com FreeDNS は NS を 2 件だけ要求するが、Route 53 のフォームは 2〜13 件対応なので問題なし。
私の経験では、AWS側にHosted Zoneを残したまま運用してしまい、後日別メンバーが混乱したことがあります。きちんと削除するか、名前を変更して「使用中断」などと明記しておくと良いでしょう。
3. サブドメインだけを相手側に再帰委任する
これは複雑な構成を持つプロジェクトで特に役立ちます。例えば、メインシステムはAWS、特定のAPI機能だけ別環境で動かしたいケースなどです。
例：example.com は Route 53、本番 API ドメイン api.example.com だけ onamae.com の GSLB に渡す。
- 子ゾーン（api.example.com）を 受け側 DNS に用意。
- 親ゾーン（Route 53 側）に NS レコード（子） を追加：
api.example.com. 300 IN NS ns01.onamae.com.
api.example.com. 300 IN NS ns02.onamae.com.
- 必要なら glue A レコード も併記（子の NS が api.example.com 配下になる特殊ケースのみ）。
私はこの方法で、大規模プロジェクトの一部機能だけを分離したことがあります。メイン環境は安定性重視のAWS、実験的機能だけ開発環境用のDNSに切り分けることで、リスクを最小化できました。
よくあるハマりどころ
どんな技術でも習得過程で落とし穴があります。私も何度かハマった経験から、以下の点は特に注意です：
| 症状 | 原因 | 対策 |
|---|---|---|
| SERVFAIL が返る | ・NS 変更後すぐに掘っている・受け側 DNS ゾーン未作成 | 伝播待ち or ゾーン側 SOA/NS を先に整備 |
| onamae.com で「他社 NS 反映に 24h」 | レジストラキャッシュ & 手動審査 | 反映完了まで作業ウィンドウを確保 |
| メール配送だけ失敗 | SPF/DKIM/MX を旧 DNS に残し忘れ | Route 53 側で必ず TXT/MX 移植 |
特にメール関連のレコードは忘れがちです。移行前にすべてのレコードをエクスポートしておき、チェックリストを作っておくと安心です。
まとめ
DNS移譲の仕組みを理解すると、インフラ構築の自由度が大きく広がります：
- 移譲＝NS レコードの置き換え。シンプルな概念ですが応用範囲は広い。
- 「誰がレジストラか」と「どこが権威 DNS か」を分離して整理すると理解しやすい。
- AWS → onamae.com / onamae.com → AWS いずれも、受け側でゾーンを先に用意→親で NS 更新→伝播確認 が鉄則。
この知識をベースに、プロジェクトに合わせた最適なDNS構成を選択できるようになるはずです。各パターンの特性を理解し、状況に応じて使い分けることで、柔軟で堅牢なインフラ構築が可能になります。
最後に
Purpom Media Labでは、クラウドインフラ構築の知見を生かしたMVP/PoC開発を提供しています。DNSを含むインフラ設計から開発まで、スピーディな構築を強みに各種プロジェクトをサポートしています。
もし興味がありましたらお気軽にお問合せください。
Discussion