どちらも、DNSを触り始めた人がほぼ必ず通る疑問です。そして後者は、後から変えるのが非常に難しいのに、最初に何となく決められてしまいがちな問題でもあります。

前回（第1回）は、DNSの3つの登場人物と、キャッシュDNSがルートから順に「紹介」をたどって答えを見つける流れを見ました。第2回では、その紹介の仕組みである委任を中心に、名前の住所録は誰が管理しているのかを掘り下げます。

ドメイン名の木構造

DNSの名前は、ルート（根）を頂点とする木構造（ツリー）になっています。

www.example.jpは、ドットで区切られたwww、example、jpという3つのラベルでできています。右から左へ読むと、木を根から枝先へたどれます。

• ルートの下に、jpやcomなどのトップレベルドメイン（TLD）がある
• その下に、組織が登録したexample.jpがある
• さらにその下に、組織が自由に作るsales.example.jpやwww.example.jpが続く

英語の住所と同じく、左が細かい単位、右が大きい単位です。同じ親の下で重複しなければよいので、wwwという名前は世界中の組織がそれぞれ使えます。

名前の長さには制限があります。

• ラベル：63オクテット以内
• 名前全体：255オクテット以内（テキストで書くと最大253文字）

使える文字は、ホスト名としては英数字とハイフンが基本です（日本語などの扱いは、この記事の後半で説明します）。

ルートとTLD

木の頂点にあるルートと、その直下のTLDを整理します。

2026年9月時点で、ルートゾーンには約1,440のTLDがあります（IANAのTLD一覧）。新gTLDの2回目の募集は、2026年4月30日から8月12日まで受け付けられました。

見慣れないTLDも実在しうる、というのがポイントです。社内で勝手なTLDを使うと、後から同名のTLDが登録されて衝突する恐れがあります（後半の「内部用ドメイン名の選び方」で詳しく扱います）。

ルートサーバーは13台ではない

ルートゾーンの情報を配るのがルートサーバーです。

ルートサーバーはa.root-servers.netからm.root-servers.netまでの13の名前（13系統）で表され、12の組織が運用しています。13という数は、初期のDNSでルートサーバーの一覧が512バイトのUDPの応答1つに収まるように決められた名残です。

ただし、実際のサーバーが13台しかないわけではありません。各系統はエニーキャストという仕組みで同じIPアドレスを世界中の拠点から経路広告しており、問い合わせは経路上もっとも近い拠点に届きます。2026年9月時点で稼働中の拠点は約2,000あり、日本国内にもあります。1か所が攻撃や障害で止まっても、全体は止まりません。

もう1つ大事なのは、ルートサーバーが返すのは、ほとんどが「そのTLDは誰々に聞いて」という紹介だということです。ルートサーバーがすべての名前を知っているわけではありません。

ポイント
・ルートサーバーは13系統（a〜m）で、12の組織が運用する
・エニーキャストで約2,000拠点に分散し、近い拠点が応答する
・ルートが返すのは答えではなく、TLDのサーバーの紹介

FQDNと末尾のドット

FQDN（完全修飾ドメイン名）とは、ルートまでのラベルを省略せずに書いた名前です。正式には、ルートを表す末尾のドットを付けてwww.example.jp.と書きます。

普段は末尾のドットを省略しますが、DNSではドットの有無で意味が変わる場面があります。

1つ目はゾーンファイルです。BINDのゾーンファイルでwww.example.jpとドットを付け忘れると、ゾーン名が補われてwww.example.jp.example.jp.になってしまいます（第5回で詳しく扱います）。

2つ目は問い合わせです。OSやツールは、ドットで終わらない名前にsearchドメイン（DNSサフィックス）を付けて試すことがあります。たとえばsearchドメインがcorp.example.jpだと、www.example.comを引いたときにwww.example.com.corp.example.jpのような余計な問い合わせが発生します（第3回）。同名のレコードがあると、違う答えが返ることもあります。

調査では末尾にドットを付ける習慣をつけましょう。末尾の「.」は「ここで終わり」の印で、何も補わせません。

ドメインとゾーンの違い

冒頭の疑問に答えます。

• ドメイン：名前の木の一部分。ある名前と、その下のすべての名前を指す
• ゾーン：1組の権威DNSサーバーがまとめて管理する単位

example.jpドメインには、www.example.jpもpc01.sales.example.jpも含まれます。

ここで、example.jpの管理者がsales.example.jpを営業部のDNSサーバーに任せた（委任した）とします。すると、example.jpゾーンにはsalesより下の名前は含まれず、sales.example.jpは別のゾーンになります。この境目をゾーンカットと呼びます。

会社にたとえると、ドメインは「全部署を含めた組織全体」、ゾーンは「台帳を管理する担当の範囲」です。pc01やpc02はexample.jpドメインの一員ですが、example.jpの台帳には載っていません。example.jpの台帳にあるのは、salesへの委任（NS）だけです。

委任をしなければ両者の範囲は一致するので、違いを意識しにくいのですが、委任や条件付きフォワーディングの設計には、この区別が欠かせません。

ポイント
・ドメインは名前の木の範囲、ゾーンは管理（台帳）の単位
・委任した部分は親のゾーンから外れ、別のゾーンになる
・委任しなければ、ドメインとゾーンの範囲は一致する

委任（NS）とグルー

委任とは、親のゾーンが「この名前より下は、このサーバーに聞いて」と、子のゾーンの権威DNSサーバーを示すことです。具体的には、親のゾーンに、子のゾーン名のNSレコードを置きます。

jpゾーンにはexample.jpのNSとしてns1.example.jpなどが登録されており、jpのサーバーはこれを「紹介（リファーラル）」として返します。

グルーが必要な理由

ここで、ns1.example.jpがexample.jpの中にあると困ったことが起きます。ns1.example.jpのアドレスを知るにはexample.jpに聞く必要があり、example.jpに聞くにはns1.example.jpのアドレスが必要…という堂々巡りです。

そこで、親のゾーンにNSの名前のアドレス（A・AAAA）も置いて、紹介と一緒に返します。これをグルー（接着剤）と呼びます。RFC 9471（2023年）は、こうしたグルーを必ず応答に含め、入りきらなければTCビットを立てるよう求めています（TCビットは第4回）。

親と子のNSは一致させる

図のとおり、NSレコードは親（jp）と子（example.jp）の両方にあります。親のNSは紹介のための写しで、正本は子のゾーンにあります。

この2つが食い違うと、一部の問い合わせだけが失敗するという、非常に分かりにくい障害の原因になります（第7回）。権威DNSサーバーを入れ替えたときなどに、片方だけ直して起きがちです。

ポイント
・委任は、親のゾーンに子のゾーンのNSレコードを置くこと
・NSの名前が子のゾーンの中にあるときは、親にアドレス（グルー）も置く
・親と子のNSの食い違いは、断続的な障害の原因になる

レジストリ・レジストラ・Whois／RDAP

では、親のゾーン（たとえばjp）にある自社のNSは、誰がどうやって登録しているのでしょうか。ドメイン名を取得するときの関係者を整理します。

• レジストリ：TLDのゾーンと登録データベースを管理する組織。.jpはJPRS、.comはVerisign
• レジストラ：利用者から登録の申し込みを受けて、レジストリに取り次ぐ事業者。.jpでは「指定事業者」と呼ぶ
• 登録者：レジストラと契約する（自社）

登録者は、権威DNSサーバーの情報（NS）もレジストラ経由で親のゾーンに登録します。つまり、親ゾーンのNSは自社のDNSではなく、レジストリの台帳にあるのです。

そのため、権威DNSサーバーを変えるときは、自分のゾーンだけでなく、レジストラの画面で親のNSも変える必要があります。ここを忘れると、せっかく新しいDNSサービスにゾーンを作っても、世界中のキャッシュDNSは古いサーバーに聞きに行き続けます。

WhoisからRDAPへ

登録者や有効期限などの登録情報は、長くWhois（TCP/43）で公開されてきました。しかしgTLDでは、2025年1月28日にWhoisの提供義務がなくなり、HTTPSでJSONを返すRDAPが正式な手段になりました。ccTLDの扱いは各レジストリによります。

なお、期限切れのドメインは第三者に取得される恐れがあり、更新の管理も重要です（第9回）。

ポイント
・レジストリはTLDを管理し、レジストラは登録を取り次ぐ
・権威DNSを変えるときは、レジストラ経由で親のNSも変える
・gTLDの登録情報の照会は、2025年1月にWhoisからRDAPへ移行

内部用ドメイン名の選び方

社内のActive Directoryなどに使うドメイン名は、後から変えるのが非常に難しく、最初の選び方が重要です。

避けるべきなのは、登録していない勝手な名前です。

.local はmDNS用に予約されている

たとえば.localは、RFC 6762でマルチキャストDNS（mDNS）用に予約されています。macOSやLinux（Avahi）、プリンターなどは、.localで終わる名前をDNSサーバーに聞かず、LAN内のマルチキャスト（224.0.0.251:5353）で解決しようとします。

その結果、図のように同じ名前でも、機器によって聞き方が違う状態になり、再現しにくい障害の原因になります。「Windowsからは引けるのに、Macからは引けない」という相談の裏に、.localが隠れていることは珍しくありません。

勝手な名前の問題はほかにもある

• 本物のTLDと衝突する：社内で使っていた名前が、後から本物のTLDとして登録されて衝突した例があります（2014年に委任された.devなど）
• 公的な証明書が取れない：公的な認証局は、登録されていない内部の名前に対してサーバー証明書を発行しません
• Microsoftも推奨していない：MicrosoftはADのドメイン名に、登録済みのドメイン名またはそのサブドメインを使うよう勧めています

新しく決めるなら、自社ドメインのサブドメイン（corp.example.jp など）にしましょう。

候補の比較

推奨は自社ドメインのサブドメインです。外部に公開しない名前でも、親ドメインを保有していれば衝突せず、証明書も取れます。

なお、AWSのEC2の内部名（ec2.internalなど）のように、.internalは既にクラウドでも使われています。社内外で同じ名前に別の答えを返す構成（スプリットホライズン）は第7回、ADドメイン名の決め方は第12回の演習で扱います。

国際化ドメイン名（Punycode）

最後に、日本語のドメイン名です。DNSのホスト名に使える文字は、もともと英数字とハイフンに限られます。

そこで「日本語.jp」のような国際化ドメイン名（IDN）は、DNSの中ではPunycode（RFC 3492）という方式でASCII文字に変換し、先頭にxn--を付けた形で扱います。たとえば日本語.jpはxn--wgv71a119e.jpになります。

• 変換はブラウザーなどのアプリケーションが行う（IDNA2008、RFC 5890〜5893）
• ゾーンには変換後の形で登録する
• そのため、ゾーンファイルやdigの結果ではxn--で始まる文字列として現れる

DNSの中はASCII（xn--）だけで、日本語は表示のための姿、と覚えておくとすっきりします。

ホモグラフ攻撃に注意

注意したいのは、見た目のよく似た文字を使った偽のドメイン名（ホモグラフ攻撃）です。たとえばラテン文字の「a」とキリル文字の「а」は見分けがつきません。先頭だけキリル文字にしたаpple.comは、DNSの中ではxn--pple-43d.comという別の名前です。

主要なブラウザーは、危険な文字の混在を見つけるとPunycodeのまま表示するなどの対策をしています。

考えてみよう

1. 自社ドメインのNSが、親（TLD）側と自社の権威DNS側で一致しているかを確かめるには、どこに何を問い合わせればよいでしょうか。
2. 社内で使っているドメイン名は、どのパターン（自社のサブドメイン、.local、独自の名前など）ですか。社内のサーバー証明書はどう発行していますか。
3. 自社ドメインの有効期限、更新の担当者、支払い方法を知っていますか。担当者が異動したらどうなりますか。

ヒント：この記事の「委任とグルー」「レジストラ」「内部用ドメイン名の比較」が手がかりです。親と子のNSは、dig（WindowsではResolve-DnsName -Type NS -Server）で両方に聞くと比べられます（第8回）。

まとめ

• DNSの名前はルートを頂点とする木構造。右から左へ読むと根から枝先へたどれる
• ルートサーバーは13系統・約2,000拠点。ルートが返すのは答えではなく紹介
• 調査では末尾にドットを付けて、searchドメインの付加を避ける
• ドメインは名前の範囲、ゾーンは管理の単位。委任した部分は別ゾーンになる
• 委任は親にNSを置くこと。必要ならグルーも置き、親と子のNSは一致させる
• 社内のドメイン名は.localではなく自社ドメインのサブドメインに

次回は、キャッシュDNSサーバーが実際にどう答えを探し、どれだけの間覚えておくのか（キャッシュとTTL）を扱います。

連載「DNS入門」全12回

1. DNSとは？名前解決の全体像と3つの登場人物
2. ドメイン名の階層と委任（この記事）
3. 名前解決の流れ
4. DNSメッセージとトランスポート
5. リソースレコード 前編
6. リソースレコード 後編
7. 権威DNSサーバーの運用
8. コマンドで調べる
9. DNSのセキュリティ
10. クラウド・社内環境のDNS
11. DNSトラブルシュート
12. DNS設計演習