DNSのサブドメインの権限移譲について

DNSにおけるサブドメインの権限移譲とは、親ドメインが管理している名前空間の一部を切り出し、その範囲のDNS管理を別の権威DNSサーバーに任せる仕組みです。

たとえば example.com を管理しているとき、shop.example.com 以下だけを別チームや別のDNSサービスに管理させたいことがあります。

そのような場合に、shop.example.com を独立した子ゾーンとして扱い、親ゾーンから子ゾーンへ管理権限を渡します。

このとき重要なのは、単にサブドメインを作ることと、サブドメインを委譲することは別だという点です。

サブドメインを作ることと、委譲することの違い

まず、親ゾーンに次のようなレコードを追加したとします。

shop.example.com. IN A 203.0.113.10

これは、shop.example.com という名前を親ゾーン example.com がそのまま管理している状態です。

サブドメイン名は存在していますが、まだ権限移譲は行われていません。

一方、次のようにNSレコードを設定すると話が変わります。

shop.example.com. IN NS ns1.dns-provider.net.
shop.example.com. IN NS ns2.dns-provider.net.

この設定によって、親ゾーンは「shop.example.com 以下の名前は、このネームサーバー群に問い合わせてください」と示すことになります。

つまり、Aレコードを追加するだけでは委譲ではなく、NSレコードによって初めて委譲が成立するということです。

権限移譲の基本的な考え方

権限移譲では、親ゾーンと子ゾーンの役割が分かれます。

親ゾーンの役割

親ゾーンは、どこで管理範囲を区切るのか、そしてその先をどの権威DNSサーバーに任せるのかを示します。

つまり親ゾーンは、子ゾーンの細かな中身を管理するのではなく、委譲先を案内する役割を持ちます。

子ゾーンの役割

子ゾーンは、自分自身のゾーンとして

• SOA
• NS
• A / AAAA / MX / TXT などの実レコード

を持ちます。

つまり、実際の名前解決に必要な情報は、委譲先である子ゾーン側に置かれます。

具体例

たとえば shop.example.com を委譲する場合、設定は概ね次のようになります。

親ゾーン example.com

shop.example.com. IN NS ns1.dns-provider.net.
shop.example.com. IN NS ns2.dns-provider.net.

子ゾーン shop.example.com

shop.example.com.      IN SOA ns1.dns-provider.net. hostmaster.shop.example.com. (
                        2026032401 3600 900 1209600 300 )
shop.example.com.      IN NS  ns1.dns-provider.net.
shop.example.com.      IN NS  ns2.dns-provider.net.
shop.example.com.      IN A   198.51.100.50
www.shop.example.com.  IN A   198.51.100.20
api.shop.example.com.  IN A   198.51.100.21

この構成では、親ゾーンは shop.example.com をどこへ委譲するかだけを示し、www.shop.example.com や api.shop.example.com といった実際のレコードは、子ゾーン側で管理されます。

名前解決はどのように進むのか

たとえば利用者が www.shop.example.com にアクセスすると、DNSリゾルバは大まかに次の順序で情報をたどります。

1. ルートDNSに問い合わせる
2. .com の権威DNSに問い合わせる
3. example.com の権威DNSに問い合わせる
4. そこで shop.example.com は別のNSへ委譲されていると分かる
5. 委譲先の権威DNSに問い合わせて、www.shop.example.com のAレコードを取得する

このように、親ゾーンは最終的なIPアドレスを返すのではなく、その先を担当する権威DNSを示す役割を果たします。

委譲に必要なレコード

サブドメインの委譲では、主に次のものが必要です。

親ゾーン側

親には、子ゾーンへの委譲を示す NSレコード が必要です。

shop.example.com. IN NS ns1.dns-provider.net.
shop.example.com. IN NS ns2.dns-provider.net.

子ゾーン側

子ゾーンには、そのゾーンとして成立するために少なくとも

• SOA
• NS

が必要です。

その上で、実際に使うA、AAAA、MX、TXTなどのレコードを持ちます。

Glueレコードとは何か

委譲では、Glueレコードが必要になる場合があります。

たとえば、委譲先のネームサーバー名が次のようになっていたとします。

shop.example.com. IN NS ns1.shop.example.com.
shop.example.com. IN NS ns2.shop.example.com.

この場合、shop.example.com の問い合わせ先として ns1.shop.example.com を知る必要があります。

しかし、その名前自体が shop.example.com の中にあるため、先にそのIPアドレスが分からないと問い合わせに進めません。

そのため親ゾーン側に、補助的に次のようなアドレス情報を置きます。

shop.example.com. IN NS ns1.shop.example.com.
shop.example.com. IN NS ns2.shop.example.com.
ns1.shop.example.com. IN A 192.0.2.10
ns2.shop.example.com. IN A 192.0.2.11

この ns1.shop.example.com や ns2.shop.example.com のAレコードが Glueレコード です。

重要なのは、委譲後に親ゾーンが通常のサービス用レコードを持つべきではない一方で、Glueだけは委譲を成立させるための例外として親に置かれることがあるという点です。

CNAMEと委譲はまったく別

CNAMEとNS委譲は混同されやすいですが、役割は異なります。

CNAMEの例

shop.example.com. IN CNAME shops.example.net.

これは、shop.example.com が shops.example.net の別名であることを示しているだけです。

管理権限をどこかに渡しているわけではありません。

委譲の例

shop.example.com. IN NS ns1.dns-provider.net.
shop.example.com. IN NS ns2.dns-provider.net.

これは、shop.example.com 以下の名前解決を別の権威DNSへ任せる設定です。

つまり、

• CNAMEは名前の別名
• NS委譲は管理責任の移譲

という違いがあります。

ゾーン頂点をCNAMEにできない理由

DNSでは、ゾーン頂点には SOA と NS が必要です。

そのため、ゾーン頂点をCNAMEにすることはできません。

たとえば shop.example.com を独立した子ゾーンとして運用するなら、そこにはSOAとNSが必要になります。

そのため、同じ shop.example.com をCNAMEとして定義することはできません。

この点は、DNS設計で非常に重要です。

特に「サブドメインを丸ごと外部に任せたい」と考えたとき、CNAMEで代用できると誤解されることがありますが、それはできません。

DNSSECを使う場合

DNSSECを利用する場合、親子ゾーンの間には DSレコード と DNSKEYレコード の関係が入ります。

• 親ゾーンが DS を持つ
• 子ゾーンが DNSKEY を持つ

これにより、親から子へ信頼の連鎖が作られます。

通常の委譲では親が子のNSを示せば動きますが、DNSSECではさらに「この子ゾーンの鍵は正当か」を検証できるようになります。

そのぶん設定ミスの影響も大きく、DSとDNSKEYの不整合があると名前解決に失敗することがあります。

実務でよくある誤解

NSを設定すれば、その名前のWeb接続先も決まる

そうではありません。

NSは問い合わせ先を示すだけで、WebサーバーのIPアドレスを示すものではありません。

shop.example.com 自体をWebで使いたいなら、子ゾーン側でA/AAAAレコードが必要です。

委譲したあとも親ゾーンで www.shop.example.com を管理してよい

通常は避けるべきです。

委譲後、その配下の実データは子ゾーン側で管理するのが原則です。

親側に通常レコードを持つと、運用が不整合になりやすくなります。

サブドメインを使うなら必ず委譲が必要

そうではありません。

単に blog.example.com や lp.example.com を追加したいだけなら、親ゾーンでAやCNAMEを定義すれば十分なことも多いです。

委譲は、管理主体を分けたいときに使うものです。

どんな場面で委譲するのか

サブドメイン委譲は、次のような場面で有効です。

• 部門ごとにDNS管理を分けたい
• 外部ベンダーに一部サブドメインを任せたい
• 開発環境や検証環境を本番と分離したい
• 運用責任や障害範囲を分けたい

たとえば、

• dev.example.com を開発部門が管理する
• shop.example.com をEC部門が管理する
• campaign.example.com をマーケティングツールの事業者に任せる

といった形です。

一方、管理者も用途も同じなら、無理に委譲せず親ゾーンでまとめて管理した方がシンプルな場合もあります。

digで確認する方法

委譲が正しく設定されているか確認するには、dig が便利です。

親ゾーン側の委譲確認

dig @親DNSサーバー shop.example.com NS

子ゾーン側の応答確認

dig @ns1.dns-provider.net www.shop.example.com A

委譲の流れ全体を見る

dig +trace www.shop.example.com

+trace を使うと、ルートからどのようにたどって委譲先へ進んでいるか確認できるため、設定ミスやGlue不足、lame delegationの調査に役立ちます。

まとめ

DNSのサブドメインの権限移譲とは、親ゾーンに子ゾーンのNSレコードを設定し、その配下の名前解決を別の権威DNSサーバーへ任せる仕組みです。

ポイントを整理すると、次のようになります。

• サブドメインを作ることと、委譲することは別
• 委譲はNSレコードによって行う
• 親ゾーンは委譲先を示し、子ゾーンは実際のレコードを持つ
• 委譲先NSが子ゾーン内にある場合はGlueが重要
• CNAMEは委譲の代わりにはならない
• ゾーン頂点はCNAMEにできない
• DNSSECでは親がDS、子がDNSKEYを持つ

つまり本質的には、親は「この先は誰が管理するか」を示し、子は「自分の範囲の実データ」を管理するという構造です。

以上、DNSのサブドメインの権限移譲についてでした。

最後までお読みいただき、ありがとうございました。