どちらも、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設計演習

DNSは、Webの閲覧、メールの配送、Active Directoryへのログオン、クラウドのサービス間の通信など、ほとんどすべての通信の最初に動いている仕組みです。普段は意識されませんが、止まったり、誤った答えを返したりすると、原因の分かりにくい障害として表に出てきます。

この連載では、名前を引いたときに裏側で何が起きているかを、登場人物と委任の流れから順に説明します。そのうえで、dig（WindowsではPowerShellのResolve-DnsName）で応答を読んで障害を切り分ける方法、ゾーンやTTLを安全に設計・変更する方法、DNSSECや暗号化DNSといった守り方、Route 53やAD統合DNSといったクラウド・社内環境での使い方までを扱います。仕様や数値は2026年9月時点の情報に合わせています。

第1回は、DNSの全体像です。

この図のとおり、どの通信もまず名前を引いて答え（IPアドレスなど）を得てから、本来の通信が始まります。裏を返すと、DNSが止まると、どの通信も入口で止まるということです。

この連載の進め方

全12回で、次の順に進めます。第1回〜第3回が土台です。特に今回の「登場人物」と、第2回の「委任」は、この後のすべての回で使うので、確実に押さえてください。

コマンドの詳しい使い方は第8回にまとめ、それまでの回では説明に必要な範囲でdigの出力を示します。各回の最後にある「考えてみよう」は、自分の職場や自宅の環境を思い浮かべながら答えてみてください。

hostsファイルからDNSへ

コンピューター同士はIPアドレスで通信しますが、数字の並びは人間には覚えにくいものです。

そこで初期のインターネット（ARPANET）では、名前とアドレスの対応を1つのファイル（HOSTS.TXT）にまとめてSRI-NICが一元管理し、各ホストが定期的にダウンロードしていました。全員が同じ電話帳のコピーを持つ状態です。

しかしホストが増えると、更新の手間、ファイルの肥大化、名前の重複が限界に達しました。そこで1983年のRFC 882・883で生まれ、1987年のRFC 1034・1035で現在の形になったのがDNSです。

DNSは電話帳を分割し、各組織が自分の部分だけを管理する分散型のデータベースです。上の図の下半分のように、ルートの下のjpはJPRSが、comはVerisignが管理し、その下のexample.jpはA社が、example.comはB社が、それぞれ自分の部分だけを管理します。「1か所に集める方式」から「各組織が自分の部分を持つ方式」への転換が、DNSのいちばん大きな発想です。

hostsファイルは今も残っている

なお、hostsファイルは今もOSに残っています。

• Linux / macOS：/etc/hosts
• Windows：C:\Windows\System32\drivers\etc\hosts

多くの場合、hostsはDNSより先に参照されます。検証のために一時的に書いた行を消し忘れると、DNSをいくら直しても、そのサーバーだけ古いアドレスに接続し続ける、ということが起きます。「このサーバーだけおかしい」ときは、まずhostsを疑う習慣をつけておくと役に立ちます。

ポイント
・昔は1つのファイル（HOSTS.TXT）を全員に配って使っていた
・DNSは名前の管理を分割し、各組織が自分の部分を持つ分散データベース
・hostsは今も残り、DNSより先に参照される。書き残しに注意

名前解決とは：通信は「2段階」で行われる

名前解決とは、www.example.jpのような名前から、通信に必要なIPアドレスなどの情報を求めることです。

• 正引き：名前 → アドレス（例：www.example.jp → 192.0.2.10）
• 逆引き：アドレス → 名前（例：192.0.2.10 → www.example.jp）

ブラウザーでWebサイトを開くときは、まず名前解決でアドレスを得て、次にそのアドレスへ接続するという2段階の通信が行われます。図の①②が名前解決、③が本来の通信です。

この2つは別々の通信です。そのため「つながらない」と言われたら、名前解決で失敗しているのか、その後の接続で失敗しているのかを最初に切り分けます。①②が失敗すると、③は始まりもしません。逆に、名前解決は成功しているのに③で失敗しているなら、DNSではなくネットワークやサーバー側の問題です。

DNSが答えるのはアドレスだけではない

DNSが答えるのはIPアドレスだけではありません。

• メールの配送先（MX）
• Active Directoryのドメインコントローラーの場所（SRV）
• 送信ドメイン認証の情報（TXT）

など、さまざまな情報（リソースレコード、第5回・第6回で解説）を引けます。

また、逆引きも軽視できません。SSHのログインが遅い、vSphereの構築が失敗するといった問題は、逆引きが引けないことが原因になっている場合があります（第10回・第11回）。

ポイント
・名前解決と、その後の本来の通信は別。まずどちらで失敗したかを見る
・正引き（名前→アドレス）と逆引き（アドレス→名前）がある
・アドレス以外に、メールの配送先やサービスの場所なども引ける

DNSの3つの登場人物

DNSを理解するうえで、いちばん大事なのがここです。DNSの登場人物は3種類です。

1. スタブリゾルバー（依頼者）
PCやサーバーのOSに組み込まれた、問い合わせを出す側の部品です。自分では答えを探さず、設定されたDNSサーバーに「調べてきて」と頼むだけです。

2. フルサービスリゾルバー（受付係）
一般にはキャッシュDNSサーバーと呼ばれます。頼まれた名前について、ルートから順に答えを持つサーバーを探し回り、得た答えを一定時間覚えておきます（キャッシュ）。「代わりに探します」という役です。

3. 権威DNSサーバー（台帳係）
自分が担当する範囲（ゾーン）の「正解」を持ち、その範囲についてだけ答えます。「担当の範囲だけ答えます」という役です。

たとえるなら、スタブリゾルバーは依頼者、フルサービスリゾルバーは調べ物を代行する受付係、権威DNSサーバーは各部署の台帳係です。

ここで大事なのは、PCのネットワーク設定に書く「DNSサーバー」は、原則としてフルサービスリゾルバー（キャッシュDNS）だということです。PCは権威DNSサーバーに直接は聞きません。必ず受付係を通して聞きます。

ポイント
・問い合わせる側（スタブ）、調べ回る側（フルサービス）、答えを持つ側（権威）
・PCに設定するDNSサーバーは、原則としてフルサービスリゾルバー
・権威DNSサーバーは、担当するゾーンについてだけ答える

1回の名前解決の全体の流れ

では、PCがwww.example.jpを初めて引く場合を追ってみましょう。

1. ① PCのスタブリゾルバーは、設定されたキャッシュDNSサーバーに問い合わせます。
2. キャッシュに答えがなければ、キャッシュDNSサーバーは ② ルートサーバーに聞きます。
3. ルートは答えを持っていませんが、③「jpのことはjpのサーバーに聞いてください」と担当を紹介します（委任、第2回）。
4. 続いて ④ jpのサーバーに聞くと、⑤ example.jpのサーバーを紹介されます。
5. ⑥ example.jpの権威DNSサーバーに聞くと、⑦ ようやく「192.0.2.10です」という答えが返ります。
6. キャッシュDNSサーバーは ⑧ その答えをPCに返し、同時にキャッシュに保存します。

面白いのは、②④⑥はどれも同じ質問「www.example.jpのAレコードは？」だという点です。キャッシュDNSは同じ質問を投げ続け、答えが見つかるまで紹介をたどります。

電話のたとえでいえば、受付係が本部、支部、担当部署と順に電話をかけ、担当者の答えを依頼者に伝える流れです。図の青（①⑧）が再帰問い合わせ、オレンジ（②〜⑦）が反復問い合わせで、この違いは第3回で詳しく扱います。

そして、2回目以降はキャッシュから答えるため、②〜⑦は行われません。インターネット全体でDNSが軽快に動いているのは、このキャッシュのおかげです。

ポイント
・キャッシュDNSが、ルート→TLD→担当ゾーンの順に紹介をたどる
・各段階の「紹介」が委任。最後に権威DNSが答えを返す
・答えはキャッシュされ、2回目以降は②〜⑦が省かれる

用語の整理（RFC 9499）

DNSは歴史が長いので、同じものがいろいろな名前で呼ばれています。この連載での呼び方と、RFC 9499（2024年、RFC 8499を置き換えたDNSの用語集）の用語、現場での呼び方を対応させておきます。

注意したいのは、単に「DNSサーバー」と言うと、キャッシュDNSと権威DNSの両方を指してしまうことです。会話やチケットで「DNSサーバーを変更しました」と出てきたら、「キャッシュ」の話か「権威」の話かを必ず確かめましょう。ここを取り違えると、話がまったく噛み合いません。

身の回りのDNS

普段使っている端末は、どのキャッシュDNSに聞いているのでしょうか。場面ごとに整理してみます。

特に最後のブラウザーは見落としがちです。OSのDNS設定を確認して「正しいサーバーを向いている」と思っても、ブラウザーが独自にDoHで外部のサーバーに聞いていると、社内の名前が引けない、といったことが起きます。

自分がどのDNSサーバーを使っているかは、次のコマンドで確認できます（詳しくは第3回・第8回）。

# Windows
ipconfig /all

# Linux（systemd-resolved）
resolvectl status

# Linux（従来の設定ファイル）
cat /etc/resolv.conf

答えの出どころを確かめる

最後に、少しだけdigを使ってみます。同じ名前を引いても、キャッシュDNSに聞いた場合と、権威DNSに直接聞いた場合とで、応答の見え方が違います。

$ dig www.example.jp
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
www.example.jp.		259	IN	A	192.0.2.10

$ dig @ns1.example.jp www.example.jp +norec
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
www.example.jp.		300	IN	A	192.0.2.10

（出力は要所のみの抜粋です）

• 1つ目は、設定されたキャッシュDNSへの問い合わせです。flagsにaaがないので、キャッシュDNSが調べてきた答えだと分かります。
• 2つ目は、権威DNSに直接、再帰なし（+norec）で聞いた結果です。aa（Authoritative Answer）が立っています。
• TTLにも注目してください。権威DNSは設定値の300のまま、キャッシュDNSは残り時間（259）を返しています。

Windowsには標準でdigがないため、PowerShellのResolve-DnsNameを使います。

PS> Resolve-DnsName www.example.jp -NoRecursion -Server ns1.example.jp
Name              Type   TTL   Section    IPAddress
www.example.jp    A      300   Answer     192.0.2.10

Resolve-DnsNameではフラグは表示されませんが、TTLが設定値のままか、減っているかで同じように見分けられます。

なぜこれが大事かというと、出どころを取り違えると、切り分けの方向を誤るからです。

• 「権威DNSでは正しいのに、キャッシュDNSでは古い」→ キャッシュの問題
• 「権威DNSから間違っている」→ ゾーンの設定の問題

digの読み方は第8回で詳しく扱います。

考えてみよう

1. 自分のPCが使っているDNSサーバーを調べてください。それはキャッシュDNSですか、権威DNSですか。社内、VPN接続中、自宅で違いはありますか。
2. hostsファイルに何か書かれているサーバーはありませんか。書かれている理由と、消し忘れたときに起きることを説明できますか。
3. 「Webサイトが開けない」と言われたとき、名前解決の失敗とその後の通信の失敗を、どうやって見分けますか。

ヒント：この記事の「2段階の通信」、「身の回りのDNS」の確認コマンド、「答えの出どころを確かめる」のaaフラグとTTLが手がかりです。

まとめ

• DNSは、名前の管理を各組織に分担させた分散型のデータベース。hostsは今もDNSより先に参照される
• 通信は「名前解決」と「本来の通信」の2段階。障害時はまずどちらで失敗したかを見る
• 登場人物はスタブリゾルバー（依頼者）・キャッシュDNS（受付係）・権威DNS（台帳係）の3つ
• キャッシュDNSがルート→TLD→担当ゾーンと紹介をたどって答えを見つけ、キャッシュする
• 「DNSサーバー」と聞いたら、キャッシュか権威かを必ず確かめる

次回は、DNSの名前がどのような階層で管理され、委任によってどう分担されているかを扱います。

連載「DNS入門」全12回

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

• DNS に関するお話
  • DNS (Domain Name System) 概要 (1)
  • DNS (Domain Name System) 概要 (2)
  • DNS (Domain Name System) 概要 (3)
  • DNS (Domain Name System) – nslookup を使いこなそう
  • DNS (Domain Name System) – Windows DNS サーバーの設定・オプション
  • DNS (Domain Name System) – DNS ゾーンの作成
  • DNS (Domain Name System) – DNS ゾーンの設定とレコードの登録
  • DNS (Domain Name System) – サブドメインと委任
  • DNS (Domain Name System) – フォワーダーの構成
  • DNS (Domain Name System) – DNS の動的更新

DNS 動的更新とは

DNS の動的更新については「DNS (Domain Name System) – DNS ゾーンの作成」で文章で書いていますが，文章だけなのでもう少しわかりやすく説明します．

2つの動的更新の仕組み

Active Directory ドメインサービス環境では，ドメインに参加しているクライアントの DNS A と PTR レコードの DNS 動的更新を利用しているケースが多いと思います．
(DNS 動的更新は Active Directory 環境に限った話ではないですが，本記事は Windows DNS のお話ですので Active Directory ドメインサービスを前提に説明します)

まず，動的更新の方法として二つあります．

• クライアントが DNS サーバーに対して直接レコード更新のリクエストを行う
• DHCP サーバーが代行して DNS サーバーに対してレコード更新のリクエストを行う

どういった違いがあるのかを次で説明します．

クライアントが DNS サーバーに対して直接レコード更新のリクエストを行う

Windows (サーバーもクライアントも) はデフォルトでクライアントが DNS の自動更新を行う設定が有効になっています．

IP アドレスを設定した，DHCP からリースを受け取った，NIC の切断と接続を行った．などのタイミングで DNS サーバーに対してレコード更新のリクエストを送信します．

この動作は Active Directory ドメインに参加している，していないに関わらず，以下の画面の箇所の設定が動的更新要求の動作に関わってきます．

その後，更新要求を DNS サーバーが受け取った後に DNS サーバー側でどのように判断，処理するのかは設定によります．

クライアントが直接更新を行う (DNSサーバー側)

「DNS (Domain Name System) – DNS ゾーンの作成」でも説明していますが改めて説明します．

DNSサーバーのゾーンプロパティをみると，動的更新は「セキュリティ保護のみ」がデフォルトの設定となっており，「認証」が成功したクライアントからのみ更新を受け付ける．という動作になります．

従って，デフォルトは Active Directory ドメインに参加クライアントからのみ DNS 更新要求を受け付け，更新が行われるという動作になります．
Active Directory ドメイン参加すると DNS レコードが自動で追加されようになる．という動作はこの設定と更新の動きによるものです．

お薦めはしませんが，設定を「非セキュリティ保護およびセキュリティ保護」に変更する事で，ドメイン参加していないクライアントからの更新要求も受け付ける事ができます．

DHCP サーバーが代行して DNS サーバーに対してレコード更新のリクエストを行う

先に… 説明はしますが，Windows DNS のセキュリティの兼ね合いから，基本的には Active Directory ドメイン参加クライアントのみ，直接更新の方式．を推奨します．

Windows DHCP サーバーは DNS サーバーに対してレコード更新要求を代行する機能を持っています．
Windows DHCP サーバー以外でも，例えば Linux などで利用される ISC DHCP も同様の機能を持っています．

上で説明している直接クライアントが更新する方法を取らずに代行の方法をとるケースは以下の場合です．

• クライアントからの直接更新を止めたい
• クライアントから直接更新する機能が無い
• ドメインに所属していないクライアントも動的に管理したい

というケースが考えられますが，DHCP サーバーが代行して DNS レコードの更新を行う場合は直接更新と代行の併用は推奨しません．

DHCP サーバーが代行する (DHCP サーバー観点)

DHCP サーバーが代行する場合「動的更新を有効にする」が設定されている必要があります．
この設定は，スコープを作ると規定で有効です．

となると，Windows クライアントも DHCP もそれぞれ DNS 更新要求出すのか? となりますが，次の DHCP のオプションによって挙動が制御されています．

DHCPクライアントから要求があったときのみ DNS レコードを動的に更新する

この設定にしている場合，DHCP REQUEST 内で Option 81 のフラグが「0x1」の場合に DHCP が更新を行う動作となります．
Windows クライアントは Option 81 のフラグは「0x0」固定の為、DHCP が代行する事はありません．

DNS レコードを常に動的に更新する

この設定にしている場合，Option 81 のフラグに関係なく DHCP サーバーが DNS 更新要求を代行します．

DNS 動的更新のトラブル事例

DNS レコードの権限の問題 (クライアントと DHCP サーバーのバッティング)

「DNS レコードを常に動的に更新する」の場合かつ，クライアント側設定がデフォルトのままの場合，クライアントと DHCP サーバーの両方が DNS レコードの更新を行います．
(クライアントは Active Directory ドメインに参加しているクライアントです)

この際，Windows DNS のゾーン設定で「セキュリティ保護のみ」の場合は，生成されたレコードの権限問題が浮上します．

DNS レコードにも ACL (アクセスコントロールリスト) が存在しており，基本的には DNS レコードを作成したアカウントのみが以降更新可能となります．
(Domain Admins 等の管理権限を持つアカウントは作成，更新，削除のいずれも可能です)

そのため，以下のような場合は DHCP サーバーからの DNS 更新クエリーは権限不足の為更新ができません．
じゃぁ「保護無し」にしよう！ はやめてください．

DNS レコードの権限の問題 (冗長化された DHCP サーバーのバッティング)

DHCP サーバーが冗長化されており，DNS 動的更新を DHCP サーバーで行う場合も権限問題が発生します．
デフォルトでは DHCP サーバーのコンピューターアカウントで認証してレコードを作成，更新が行われます．
この例の場合，AD01 がレコードを作成した為，以降このレコードを更新できるのは AD01 のみとなります．AD02 が更新の要求を行っても権限がありませんので更新ができません．

こうなると DHCP サーバーからの DNS 動的更新の運用上問題になる為，動的更新用のユーザーアカウント(DNSUpdateProxyアカウント)を用いて更新を行う方式を取ります．

この問題を解消するための設定を説明していきます．

DNS Update Proxy の設定

冗長化されている DHCP サーバーで DNS 更新を行う場合，DNS Update Proxy アカウントを用いた更新を行う必要があります．

流れとしては次のとおりになります．

• DNS Update 用アカウントを作成する
• 作成したアカウントを DNSUpdateProxy グループに所属させる
• DHCP サーバーで動的更新用アカウントを設定する

DNS Update 用アカウントの作成

サーバーマネージャーの「ツール」選択し「Active Directory ユーザーとコンピューター」をクリックします．

作成したい OU や CN を選択し，右クリックでメニューを表示して「新規作成」-「ユーザー」をクリックします．
ユーザーアカウントを作成する OU はどこでも大丈夫です．

ユーザー作成画面が表示されますので，アカウント情報を入力して「次へ」をクリックします．

DHCP サーバーでアカウント情報を入力しますので，パスワードは無期限にした方が扱いは楽です．セキュリティを考慮するのであれば定期的に更新していく運用を行いましょう．

今回は「パスワードを無期限にする」にチェックを入れて「次へ」をクリックします．

「完了」をクリックしてアカウント作成を完了します．

アカウントが作成されたことを確認します．

DnsUpdateProxy グループに所属させる

先ほど作成したアカウントを「DnsUpdateProxy」に所属させます．

「DnsUpdateProxy」グループを選択，右クリックでメニューを表示し「プロパティ」をクリックします．

「メンバー」タブを選択して「追加」をクリックします．

先ほど作成したアカウントを入力して「OK」をクリックします．

所属するメンバーに作成したアカウントが表示されていることを確認し，「適用」をクリックの上「OK」をクリックしてウィンドウを閉じます．

DHCP サーバーで動的更新用アカウントを設定する

上で作成，グループに登録したアカウントを DHCP サーバーに設定します．
1台だけ説明をしていますが，冗長化している DHCP サーバーすべてで実施する必要がありますので注意してください．

サーバーマネージャーより「ツール」-「DHCP」をクリックします．

DHCP サーバーを展開し「IPv4」を選択，右クリックでメニューを表示して「プロパティ」をクリックします．

「詳細設定」タブを選択し「資格情報」をクリックします．

アカウント情報の入力画面が表示されますのでアカウント情報を入力して「OK」をクリックします．
ドメイン名は NetBIOS 名 (短縮名) で入力する必要がありますので注意してください．

元の画面に戻りますので「OK」をクリックします．

動作確認

DHCP でアドレスを取得し，更新された DNS レコードを確認しましょう．
この際，既にレコードが存在している場合は権限が DHCP サーバーのコンピューターアカウントになっていると思います．そうなると更新に失敗しますので一度レコードを削除してから動作確認をしてください．

以上，DNS 動的更新についての解説でした．

次回以降は，ちょっと今後の雲行きが微妙なのですが，VMware (現 Broadcom) の vSphere について解説していこうと思います．

• DNS に関するお話
  • DNS (Domain Name System) 概要 (1)
  • DNS (Domain Name System) 概要 (2)
  • DNS (Domain Name System) 概要 (3)
  • DNS (Domain Name System) – nslookup を使いこなそう
  • DNS (Domain Name System) – Windows DNS サーバーの設定・オプション
  • DNS (Domain Name System) – DNS ゾーンの作成
  • DNS (Domain Name System) – DNS ゾーンの設定とレコードの登録
  • DNS (Domain Name System) – サブドメインと委任
  • DNS (Domain Name System) – フォワーダーの構成
  • DNS (Domain Name System) – DNS の動的更新

条件付きフォワーダー

条件付フォワーダーは，指定したドメインの名前解決を指定した DNS サーバーに転送する仕組みです．
イメージとしてはこのようになり，今回設定する例ですと「seichan.org」の名前解決はフォワーダーで転送します．それ以外の名前解決は自前で DNS ルートサーバーから一連の再帰問合せで解決を行う形です．

条件付フォワーダーの設定

「条件付きフォワーダー」を選択，右クリックでメニューを表示し「新規条件付きフォワーダー」をクリックします．

「DNS ドメイン」にフォワード (転送) したいドメインを入力し，そのドメインを管理している DNS サーバーを「マスターサーバーの IP アドレス」に入力します．
今回は2台の DNS サーバーが存在するので2つの IP アドレスを入力しています．

また「この Active Directory に条件付きフォワーダーを保存し、次の方法でレプリケートする」にチェックを入れることで，フォワーダーの設定を Active Directory 内に保存することが出来るようになります．
そのため，それぞれの DNS サーバーで同じような設定が不要になりますので，AD 統合 DNS の場合は積極的に利用しましょう．

レプリケートの範囲については「DNS (Domain Name System) – DNS ゾーンの作成」で説明しているレプリケーション範囲と同様です．今回は「このドメインのすべての DNS サーバー」としています．

設定 (入力) が終わったら「OK」をクリックします．

設定が完了すると「条件付フォワーダー」にドメインが作成され，フォワード先 IP アドレスが確認することができます．

動作確認

実際にフォワードができているのかを確認します．纏めて実施をしていますが次のことを行っています．

• seichan.org の NS の確認
  NS 自体も自サーバーは保持しておらず，フォワード先によって応答がある状態ですので正常に動作していることが確認できます．
• www.seichan.org の A レコードの確認
  A レコードは seichan.org の権威サーバーが管理していますので，これも正常に動作していることが確認できます．

すべてのクエリをフォワードする

条件付フォワーダーは，指定したドメインのみフォワードする設定となります．組織内に DNS リゾルバーが存在する場合はそこに集約したいということが多いと思います．
そんな場合を想定した設定方法について解説します．

先ほど設定した条件付フォワーダーを止める

記事の流れとして記載しています．元々条件付フォワーダーを設定していない場合は無視してもらって大丈夫です．

また，以下の構成のような場合は条件付フォワーダーは継続して残り続けます．
(このような構成をとるなら，中央のリゾルバーで全部制御したほうが良いと思いますが…)

「条件付フォワーダー」にあるドメインを選択，右クリックでメニューを表示して「削除」をクリックします．

確認が促されるので，ドメイン名を確認して問題がなければ「はい」をクリックします．

「Active Directory 統合」されている場合，警告が表示されます．「はい」をクリックして Active Directory から情報を削除します．

フォワーダーを設定する

フォワーダーを設定するサーバーを選択，右クリックでメニューを表示し「プロパティ」をクリックします．

「フォワーダー」タブを選択して「編集」をクリックします．

フォワーダーとして DNS リクエストを送信したいサーバーを追加して「OK」をクリックします．

「フォワーダーが利用できない場合にルートヒントを使用する」のチェックを外して「適用」をクリックします．
チェックがついている場合，フォワード先が応答がない場合自身がフルリゾルバーとして動作します．
条件付フォワーダーではなく，ここで設定を行うケースは完全なフォワーダーとしての動作を期待している場合が多いと思います．チェックの有無は考慮したうえで行ってください．

チェックの有無による挙動の違い

「OK」をクリックしてウィンドウを閉じます．

フォワーダーの設定は，サーバー毎に実施する必要がありますので，必要台数分同じ処理を実施してください．

以上，フォワーダーの解説となります．
次回は DNS の動的更新について解説しようと考えています．

• DNS に関するお話
  • DNS (Domain Name System) 概要 (1)
  • DNS (Domain Name System) 概要 (2)
  • DNS (Domain Name System) 概要 (3)
  • DNS (Domain Name System) – nslookup を使いこなそう
  • DNS (Domain Name System) – Windows DNS サーバーの設定・オプション
  • DNS (Domain Name System) – DNS ゾーンの作成
  • DNS (Domain Name System) – DNS ゾーンの設定とレコードの登録
  • DNS (Domain Name System) – サブドメインと委任
  • DNS (Domain Name System) – フォワーダーの構成
  • DNS (Domain Name System) – DNS の動的更新

サブドメイン

サブドメインを作成するには既存の DNS ゾーンの中で作るか新規の DNS ゾーンを作るかの2つの方法があります．

既存の DNS ゾーンの中でサブドメインを作成する

サブドメインを作成したいゾーンを選択，右クリックでメニューを表示し「新しいドメイン」をクリックします．

サブドメイン名を入力して「OK」をクリックします．

サブドメインがフォルダーとして作成されます．
この場合，サブドメインは親ゾーン(親ドメイン)の中にあり，NS などは親ゾーンが持つ形となります．

サブドメインフォルダーの中をみても NS や SOA は存在しません．

新規のゾーンとしてサブドメインを作成する

「前方参照ゾーン」を選択，右クリックでメニューを開き「新しいゾーン」をクリックします．

ウィザードが開始されますので「次へ」をクリックします．

ゾーンの種類を選択して「次へ」をクリックします．
詳細については「DNS (Domain Name System) – DNS ゾーンの作成」を参照ください．

レプリケーションのスコープを選択して「次へ」をクリックします．
詳細については「DNS (Domain Name System) – DNS ゾーンの作成」を参照ください．

ゾーン名 (ドメイン名) を入力して「次へ」をクリックします．

動的更新の設定を選択して「次へ」をクリックします．
詳細については「DNS (Domain Name System) – DNS ゾーンの作成」を参照ください．

作成する内容を確認して「完了」をクリックします．

このようにして作成したサブドメインの場合，親ドメイン (今回の場合だと lab.seichan.org) に薄いサブドメインフォルダーアイコンが作成されています．

そのフォルダーを展開すると NS レコードの存在が確認できます．

もう一つ，前方参照ゾーンのツリーに作成したサブドメインが作成されており，この中をみると NS と SOA が存在します．

どちらが良いのか

動作だけで見るとどちらでも違いはありません．大きな違いは今後のゾーンのポータビリティだと思います．
後者 (新規ゾーン) として作成した場合，親ドメイン (lab.seichan.org) から「委任」されてサブドメイン (sub1.lab.seichan.org) が作成されています．
現状は同じ DNS サーバーが管理しているため違いはありませんが，新規の DNS サーバーを構成，サブドメインだけ引っ越したい．というような場合は委任先を変えるだけで成立します．

一方，前者 (新しいドメイン) として作成した場合，ドメインの引っ越しの場合は一から委任の設定が必要になり，切り替えの際に停止時間を設ける必要があります．

そのような意味から，新規ゾーンとして作成する方法が望ましいと考えます．

委任

さて，今更ではありますが，ここで言っている親ドメイン (lab.seichan.org) は seichan.org のサブドメインです．
今回 Active Directory ドメインサービスとして新規に lab.seichan.org を作成した為，関連性がないままの状態となっています．

ですので，本来の親ドメインである seichan.org から lab というサブドメインは ad01.lab.seichan.org および ad02.lab.seichan.org がドメインを管理している．ということを示す「委任」を設定していきたいと思います．

委任の構成

委任を行う DNS サーバー (今回だと seichan.org を管理している DNS サーバー) にて，委任を行いたいドメインを選択，右クリックでメニューを表示し「新しい委任」をクリックします．

ウィザードが開始されるので「次へ」をクリックします．

委任するサブドメインを入力して「次へ」をクリックします．

委任されたドメインの DNS サーバー情報を設定します．最初は何もない状態ですので「追加」をクリックします．

「サーバーの完全修飾ドメイン名」に委任するサブドメインを管理している DNS サーバーの FQDN を入力します．
また，「この NS レコードの IP アドレス」にその DNS サーバーの IP アドレスを入力して「OK」をクリックします．

元の画面に戻ります．lab.seichan.org は2台の DNS サーバーが存在していますので再度「追加」をクリックします．

先ほどと同様に NS レコードを生成するための DNS サーバーの FQDN と対応する IP アドレスを入力して「OK」をクリックします．

委任する DNS サーバー情報が入力出来たことを確認して「次へ」をクリックします．

ウィザードの完了画面になりますので「完了」をクリックします．

サブドメイン作成時に「新規ゾーン」で作成した時と同じように「lab」が薄いフォルダーアイコンで表現され，NS レコードのみが存在する状態となります．

以上で委任の設定は完了です．

nslookup で確認する

構成した委任が正しく動作するのかを確認します．画像では確認結果を纏めてしまっていますが，次のことを確認しています．

• lab.seichan.org の NS レコードの確認
  正しく解決できています．ですが，これ自体は seichan.org でも持っている情報となります．
• www.lab.seichan.org の A レコードの確認
  これは lab.seichan.org が管理するサーバーにしかない情報ですので，正しく委任先に問合せが行われていることが確認できます．
• sub1.lab.seichan.org の NS レコードの確認
  これも同様に，lab.seichan.org が管理するサーバーにしかない情報ですので，正しく委任先に問合せが行われていることが確認できます．

以上，サブドメインと委任について解説を終わります．

次回はフォワーダーについて解説します．

• DNS に関するお話
  • DNS (Domain Name System) 概要 (1)
  • DNS (Domain Name System) 概要 (2)
  • DNS (Domain Name System) 概要 (3)
  • DNS (Domain Name System) – nslookup を使いこなそう
  • DNS (Domain Name System) – Windows DNS サーバーの設定・オプション
  • DNS (Domain Name System) – DNS ゾーンの作成
  • DNS (Domain Name System) – DNS ゾーンの設定とレコードの登録
  • DNS (Domain Name System) – サブドメインと委任
  • DNS (Domain Name System) – フォワーダーの構成
  • DNS (Domain Name System) – DNS の動的更新

ゾーンのプロパティ

DNS サーバー自体の設定項目については「DNS (Domain Name System) – Windows DNS サーバーの設定・オプション」で解説しました．
今回はゾーンの設定について解説していきます．内容が重複している部分がありますので，適宜「DNS (Domain Name System) – Windows DNS サーバーの設定・オプション」に誘導しますのでご容赦ください．

DNSサーバー 管理画面の起動

サーバーマネージャーの「ツール」をクリックして「DNS」をクリックします．

DNS ゾーンのプロパティの確認

確認したい DNS ゾーンを選択，右クリックで「プロパティ」をクリックします．

「全般」設定

「全般」の設定は，DNS ゾーンを作成した際に選択した項目が表示されます．
項目の内容の詳細は「DNS (Domain Name System) – DNS ゾーンの作成」を参照ください．

• 状態
  この DNS ゾーンを応答するかどうかを制御できます．
  「起動中」の場合はこのゾーン(ドメイン)の問い合わせに対して DNS 応答を返します．
  「一時停止」にすると応答を返さなくなります．大規模にメンテナンスを行う際に中途半端にサービスを動作させたくない場合に利用します．
• 場所
  ゾーン情報を格納する場所を変更できます．
  項目の内容の詳細は「DNS (Domain Name System) – DNS ゾーンの作成」を参照ください．
• レプリケーション
  レプリケーションの範囲を変更できます．
  項目の内容の詳細は「DNS (Domain Name System) – DNS ゾーンの作成」を参照ください．
• 動的更新
  動的更新の有無，セキュリティ保護の状態を変更できます．
  項目の内容の詳細は「DNS (Domain Name System) – DNS ゾーンの作成」を参照ください．
• エージング
  動的更新を行っている際に，古いレコードを定期的にクリーンアップできます．
  「DNS (Domain Name System) – Windows DNS サーバーの設定・オプション」でも同様のことについて触れていますが，こちらはこのゾーンのみ対象となります．

エージングの設定です．こちらの内容詳細は「DNS (Domain Name System) – Windows DNS サーバーの設定・オプション」で触れていますので参照ください．

SOA 設定

SOAについては「DNS (Domain Name System) 概要 (3)」で説明をしていますので参照ください．
AD 統合ゾーンの場合，ここの設定はあまり影響はおよぼさないです．変更するのであれば「責任者」の箇所を受け取れるメールアドレスに変える位かと思います．

WINS 設定

WINS (Windows Internet Naming Service) は TCP/IP 以前に用いられていた名前解決手法の一つです．現在においてはほぼ利用されませんし新規で WINS を必要とする構成はありませんので気にしなくてよいと思います．

ゾーンの転送 設定

Active Directory 統合ゾーンの場合は本設定は意味を持ちません．
統合ゾーンではない通常の DNS ゾーンの場合，ゾーン転送を許可するサーバーをここの設定で指定，制限を行います．
通常であれば「ネームサーバー一覧にあるサーバーのみ」を選択します．もっと絞りたい場合に「次のサーバーのみ」とするケースがある．という形になります．

レコードの登録

ここまで来るのにずいぶん長かったですが，ようやく DNS レコードの登録 (作成) について解説します．

A レコードおよび PTR レコードの登録

登録したい DNS ドメイン (DNS ゾーン) を選択，右クリックし「新しいホスト (A または AAAA)」をクリックします．

「名前」にホスト名を入力します．入力すると「完全修飾ドメイン名(FQDN)」が補完されます．
名前に対応する「IP アドレス」を入力します．

続いて「関連付けられたポインター (PTR) レコードを作成する」にチェックを入れます．
ここにチェックを入れることで逆引きレコードが一緒に登録されますので手間が減らせます．
逆引きレコードのゾーンについては「DNS (Domain Name System) – DNS ゾーンの作成」を参照して先に作成しておいてください．

「ホストの追加」をクリックすると登録されます．

完了した旨のウィンドウが表示されますので「OK」をクリックします．

追加でホストを登録したい場合は引き続き同じように「名前」と「IP アドレス」を入力して「ホストの追加」をクリックすることで連続してレコードを登録することができます．

これで完了でいい場合は「完了」をクリックしてウィンドウを閉じます．

ゾーンのレコード一覧に登録したレコードが表示されていることを確認します．
ここの一覧には 1,000 件ほどのレコードしか表示されません．もし大量にレコードがある場合は実際に「nslookup」で名前解決を行って確認することをお薦めします．

「関連付けられたポインター (PTR) レコードを作成する」にチェックを入れた場合は逆引きゾーンも更新されていますので合わせて確認しましょう．
登録されていないな．という場合は「更新」や「F5」を実施しましょう．

CNAME レコードの登録

登録したい DNS ドメイン (DNS ゾーン) を選択，右クリックし「CNAME」をクリックします．
(ただし…「DNS (Domain Name System) 概要 (3)」で解説しているとおり，CNAME はお薦めしません)

「エイリアス名」につけたい名前を入力します．「完全修飾ドメイン名 (FQDN)」が補完されます．
ターゲットホストは FQDN で入れる必要があります．ここでは先ほど A レコードで登録した「www.lab.seichan.org」を入力しています．

「エイリアス名」と「ターゲットホスト」の入力ができたら「OK」をクリックします．

ゾーンのレコード一覧に登録したレコードが表示されていることを確認します．

MX レコードの登録

登録したい DNS ドメイン (DNS ゾーン) を選択，右クリックし「新しいメール円クスチェンジャー(MX)」をクリックします．

「ホストまたは子ドメイン」の欄は空白にすると該当ゾーンのドメインを指定していることになります．今回の場合は「@lab.seichan.org」宛ての MX レコードという意味になります．
個別のホストを指定する場合は例えば「smtp」と入力すると「@smtp.lab.seichan.org」宛てという形で指定することができます．
「メールサーバーの完全修飾ドメイン名」は配送先ホストを指定します．
優先順位は整数で表し，番号が小さいホストが優先されます．
(MX レコードの詳細については「DNS (Domain Name System) 概要 (3)」を参照ください)

入力が終わったら「OK」をクリックします．

ゾーンのレコード一覧に登録したレコードが表示されていることを確認します．
「親フォルダーと同じ」は該当ゾーンのドメイン名である事をあらわしています．

以上で，DNSゾーンの設定とレコードの登録について解説を終わります．

次回はサブドメインと委任について解説します．

• DNS に関するお話
  • DNS (Domain Name System) 概要 (1)
  • DNS (Domain Name System) 概要 (2)
  • DNS (Domain Name System) 概要 (3)
  • DNS (Domain Name System) – nslookup を使いこなそう
  • DNS (Domain Name System) – Windows DNS サーバーの設定・オプション
  • DNS (Domain Name System) – DNS ゾーンの作成
  • DNS (Domain Name System) – DNS ゾーンの設定とレコードの登録
  • DNS (Domain Name System) – サブドメインと委任
  • DNS (Domain Name System) – フォワーダーの構成
  • DNS (Domain Name System) – DNS の動的更新

Windows DNS サーバーの ゾーンの持ち方

Active Directory 統合ゾーン

Active Directory 統合ゾーンは，ゾーン情報を Active Directory のディレクトリー内に格納する方式です．この場合は両方がプライマリーサーバーとして機能し，どちらで更新を行っても Active Directory の複製機能で DNS ゾーンも同期されます．

すなわち，Active Directory にゾーン情報を格納する場合は「プライマリー」と「セカンダリー」の区別が無くなります．
AD DS を構成しているサーバーの場合は「プライマリゾーン」を選択し「Active Direcotry にゾーンを格納する」にチェックを入れることが通常となります．

プライマリ，セカンダリ

• プライマリゾーン
  DNS の情報を主に管理するサーバーをプライマリーサーバーといいます．複製を受ける側をセカンダリーサーバーといいます．
  
  AD DS を構成していないサーバーの場合はゾーン情報を Active Directory に格納はできないので，明示的にプライマリー，セカンダリーを選択することになります．
• セカンダリゾーン
  プライマリゾーンの複製を受けるサーバーになります．ゾーン情報の編集はプライマリーサーバーで行い，その複製を受け取るサーバーです．

通常の (Active Directory にゾーン情報を格納しない場合) の プライマリー と セカンダリー のゾーン転送はこのように行われます．

プライマリーサーバーでゾーン情報を修正 (新しいレコードを作成するなど) が行われると，更新されたことをセカンダリーに通知 (notify) を出します．

セカンダリーは通知を受け取り，新しいゾーン情報の取得を試み，通信が成功すれば新しいゾーンを取得します．転送と書いていますが，セカンダリーが「取得」する流れになります．

なお，Active Directory 環境ではプライマリゾーンは通常統合ゾーン (Active Directory にゾーン情報を格納する) にしますのでこの動作にはならず，Active Directory の複製によってゾーン情報の複製が行われます．

スタブゾーン

• スタブゾーン
  セカンダリーに近いのですが、NS(ネームサーバー) と SOA (Start of Authority) のみを持つゾーンです．

スタブゾーンはこの図のように SOA / NS および NS に対応する A レコードのみを保持するゾーンです．
サブドメインを構成している場合，委任を構成するために親ドメイン側で委任の設定を行う必要があります．サブドメインで DNS サーバーの入れ替えなどで「削除」と「追加」を行う場合2回の依頼，作業を行う必要があり煩雑になります．

スタブゾーンを用いることでサブドメイン側での設定を反映できるため，ゾーンを構成するだけであとは放置できるようになります．
ただ，親ドメイン管理者側で都度管理を行いたい．というケースももちろんありますので，どちらで構成するのかは検討が必要です．

正引きゾーンを作成する

Active Directory ドメインサービスを構成している場合，Active Directory ドメインのゾーンは既に作成されています．
ですので，ここでは追加のゾーン (ドメイン) を作成する場合を想定して解説します．

DNSサーバー 管理画面の起動

サーバーマネージャーの「ツール」をクリックして「DNS」をクリックします．

正引きゾーンを作成する

DNS サーバーを選択，右クリックで「新しいゾーン」をクリックします．

「新しいゾーン」のウィザード画面が開きますので「次へ」をクリックします．

ゾーンの種類を選択する画面が表示されます．解説は上部の「Windows DNS サーバーの ゾーンの持ち方」に記載していますので参照ください．

• プライマリゾーン
• セカンダリゾーン
• スタブゾーン

ここでは「プライマリゾーン」かつ「Active Directory にゾーン情報を格納する」を前提としていますのでそのまま「次へ」をクリックします．

Active Directory 統合ゾーンとする場合，ゾーンを複製する範囲を選択することになります．

• このフォレストのドメインコントローラー上で実行しているすべての DNS サーバー
  DNS 情報をフォレスト内のドメインコントローラー上で動作している DNS サーバーすべてに対してレプリケートを行います．
  利点はフォレスト内のドメイン情報がどこのドメインコントローラー (DNS サーバー) に接続されても同じものを持っているため，委任やフォワーダーに頼らずに完結することです．
  欠点は全て同じ情報をもってしまうため管理権限の分離などができなくなることが挙げられます．
  通常のケースではこれを選ぶことは少ないと思います．
• このドメインのドメインコントローラーで実行しているすべての DNS サーバー
  デフォルトで選択されるものです．同一 Active Directory ドメイン内のドメインコントローラーで動作している DNS サーバーにのみ複製が行われます．
• このドメインのすべてのドメインコントローラー
  Windows 2000 の場合，上記二つの概念 (DNS パーティションの概念) が無く，DNS サーバーとして構成されていないドメインコントローラーにも DNS 情報が複製されていました．
  これと同様の動きをさせたい場合の選択になります．
  これを選ぶケースはほぼ無いと思います．

デフォルトの「このドメインのドメインコントローラーで実行しているすべての DNS サーバー」を選択して「次へ」をクリックします．

ゾーンの種類の選択画面になります．正引きゾーンと言っているものが「前方参照ゾーン」になります．
正引きゾーン / 前方参照ゾーンは「名前」から「IPアドレス」を解決するためのゾーンです．

「前方参照ゾーン」を選択して「次へ」をクリックします．

「ゾーン名」を入力します．DNS ドメイン名を指します．

ここでは「example.com」としていますが，管理したい DNS ドメイン名を入力して「次へ」をクリックします．

DNS の動的更新 (ダイナミック DNS) の設定画面が表示されます．

• セキュリティで保護された動的更新のみ許可する
  デフォルトで選択されています．Active Directory ドメインサービスに参加しているクライアントからのみ動的な更新を受け付ける設定です．
  クライアント端末，特にノートPCなどネットワーク (サブネット) が移動する端末の DNS 情報は手動で管理はしていられませんので，基本的にはこの「セキュリティで保護された動的更新のみ許可する」を選択するで問題はありません．
  これが選択されている場合，サーバーもクライアントも AD DS ドメインに参加していれば DNS 情報は動的に更新されます．
  もちろん，動的に生成された情報を削除して手動で作成・管理を行うことも可能です．
• 非セキュリティ保護及びセキュリティ保護の両方による動的更新を許可する
  これを選択すると，AD DS に参加していないクライアントからの DNS 更新要求を受け付けるようになります．
  警告にあるとおり，ドメインに非参加の端末 (認証されていないクライアント) からの更新も受け取るようになるため，セキュリティの観点では脆弱になります．
  非 AD DS 参加端末もDNS レコードとして生成，管理したい場合を除いて利用するケースは少ないと思います．
• 動的更新を許可しない
  動的更新を一切利用しない場合に選択します．
  AD DS 環境において，クライアント端末の DNS レコードは無くても動作はしますのでこれを選んでも問題は生じませんが，全体的な管理の面では AD DS 環境においてこれを選択するメリットは無いと思います．
  AD DS と関係がないドメイン (例えば今回のような追加のドメインゾーン) であれば「動的更新を許可しない」は選択肢として有用です．

今回は「動的更新を許可しない」でもよかったのですが「セキュリティで保護された動的更新のみを許可する」を選択して「次へ」をクリックします．
(ちなみに設定は後でも変えられます)

確認画面が表示されますので確認の上「完了」をクリックして終了させます．

作成されたゾーンが確認できれば完了です．

このまま正引きゾーンのレコードに進んでもよいのですが，逆引きゾーンを作ろうと考えている場合は先に逆引きゾーンを作る事をお薦めします．
理由は，正引きレコードを作成する際に，逆引きレコードを一緒に作成してくれるオプションが存在しているため，のちの手間が削減できるから．となります．

逆引きゾーンを作成する

では，逆引きゾーンの作成に移ります．

逆引きゾーンを作成する

DNS サーバーを選択，右クリックで「新しいゾーン」をクリックします．

「新しいゾーン」のウィザード画面が開きますので「次へ」をクリックします．

ゾーンの種類を選択する画面が表示されます．解説は上部の「Windows DNS サーバーの ゾーンの持ち方」に記載していますので参照ください．
ここでは「プライマリゾーン」かつ「Active Directory にゾーン情報を格納する」を前提としていますのでそのまま「次へ」をクリックします．

Active Directory 統合ゾーンとする場合，ゾーンを複製する範囲を選択することになります．
範囲の説明は「正引きゾーンの作成の箇所」で行っていますので参照ください．

デフォルトの「このドメインのドメインコントローラーで実行しているすべての DNS サーバー」を選択して「次へ」をクリックします．

ゾーンの種類の選択画面になります．
逆引き参照ゾーンは「IPアドレス」から「名前」を解決するためのゾーンです．

「逆引き参照ゾーン」を選択して「次へ」をクリックします．

IPv4 アドレスの逆引きゾーンを作るのか，IPv6 の逆引きアドレスゾーンを作るのか選択が必要になります．

今回は「IPv4 逆引きゾーン」を選択して「次へ」をクリックします．

逆引き参照ゾーンの名前 (アドレス範囲) を決定します．

• ネットワークID
  IPネットワーク，セグメントを入力してゾーン名を作成する方法です．/24 や /16 および /8 のレンジで逆引きゾーンを作成する場合はネットワークIDで作成するのが簡単です
• 逆引き参照ゾーンの名前
  逆引きゾーンの名前を明示して作成する方法です．IPネットワークを逆に並べて「in-addr.arpa.」を付ける形となります．
  「192.168.250.0/24」の場合は「250.168.192.in-addr.arpa.」になります．
  「172.16.0.0/16」の場合は「16.172.in-addr.arpa.」になります．
  
  /24 などではないサブネットマスクで委任されているような場合は委任元の指定のとおりの名前を入力することになります．

今回は「192.168.250.0/24」の逆引きゾーンを作成するため，ネットワークIDにアドレスを入力して「次へ」をクリックします．

DNS の動的更新 (ダイナミック DNS) の設定画面が表示されます．
動作の説明は「正引きゾーンの作成の箇所」で行っていますので参照ください．

今回は「セキュリティで保護された動的更新のみを許可する」を選択して「次へ」をクリックします．

確認画面が表示されますので確認の上「完了」をクリックして終了させます．

作成されたゾーンが確認できれば完了です．

以上，正引きゾーン (正引き参照ゾーン) と逆引きゾーン (逆引き参照ゾーン) の作成でした．

次回は，正引き，逆引きレコードの登録やゾーンの設定について解説します．

• DNS に関するお話
  • DNS (Domain Name System) 概要 (1)
  • DNS (Domain Name System) 概要 (2)
  • DNS (Domain Name System) 概要 (3)
  • DNS (Domain Name System) – nslookup を使いこなそう
  • DNS (Domain Name System) – Windows DNS サーバーの設定・オプション
  • DNS (Domain Name System) – DNS ゾーンの作成
  • DNS (Domain Name System) – DNS ゾーンの設定とレコードの登録
  • DNS (Domain Name System) – サブドメインと委任
  • DNS (Domain Name System) – フォワーダーの構成
  • DNS (Domain Name System) – DNS の動的更新

DNS サーバーのオプション

今回は DNS サーバーの管理のうち，サーバーオプションについて解説します．

DNS の管理を行うには，サーバーマネージャーのツールより「DNS」をクリックします．

DNS 管理画面が表示されますので，DNS サーバーを選択し右クリックで「プロパティ」を選択します．

DNS サーバーのプロパティが表示されます．

インターフェイス

インターフェイス設定では，DNS サービスをどのインターフェイスで待ち受けするかを決定できます．

デフォルトは「すべての IP アドレス」となっており，DNS サーバーの全てインターフェイスで待ち受けされていますが，「指定した IP アドレス」を選択のうえ，待ち受けしたい IP アドレスのみチェックを入れることで待ち受けインターフェイスを制限することが可能です．

バックアップ用ネットワーク向けなどの複数のインターフェイスを搭載しており，そこでは応答したくない場合などで利用したりします．

フォワーダー

フォワーダーは，この DNS サーバーに届いた名前解決要求を他の DNS サーバーに転送する場合に利用されます．

フォワーダーは複数設定可能で，指定した順番のとおりに問合せクエリーを転送します．

例えば，以下のイメージ図左側のように組織内に別のリゾルバーが存在しており，そこに集約したい場合．あるいは右側のように ISP などが提供している DNS サーバーに転送したい場合に利用します．

理由は様々なケースが考えられますが組織内部に DNS リゾルバーが乱立しても管理がしづらいため集約したい．であったり，セキュリティを考慮して ISP などの特定の DNS サーバーにだけトラフィックを投げたい．などが挙げられます．

また「フォワーダーが利用できない場合にルートヒントを使用する」にチェックが入っている場合，最初にフォワーダーを試行し，名前解決ができない場合は自身が直接名前解決を行う動作になります．

チェックが入っている場合は ① で問合せを転送します．この際に名前解決ができない場合は ② のとおり，自身がルートヒントを元に名前解決を試みる．という動作になります．

フォワーダーを有効にしている場合，先に述べた理由が多いと思いますので，自身が名前解決を行う動作は期待動作ではない可能性が高いです．

詳細設定

「詳細設定」はサーバーの挙動を決定するオプションが幾つかあります．

サーバー オプション

各オプションの解説を行います．

• 再帰を無効にする (フォワーダーも無効になります)
  再帰問合せを無効にします．再帰問合せが有効な場合はリゾルバー (キャッシュサーバー) として動作します．
  ですので，再帰問合せを行わないということは権威 DNS サーバー専用とする場合に利用します．
  Active Directory ドメインサービスの DNS サーバーの場合，通常このオプションを有効にすることはないと思います．出来ないわけではありませんが，クライアントが参照する DNS サーバーが別に正しく存在しており，Active Directory ドメインへのフォワーダーが適切に設定されているのであれば可能です．
• BIND セカンダリを有効にする
  有効にすると，複数台の DNS サーバー構成において，DNS ゾーンの転送の際に BIND の転送方式を用いて BIND DNS サーバーへのゾーン転送を可能になります．
• ゾーンデータが正しくない場合は、ロード時に失敗する
  デフォルトではゾーンデータのエラーが検出された場合でもゾーンの読み込みを継続し，エラーをログに記録して動作を継続します．
  このオプションを有効にすると，ゾーンデータのエラーが検出された場合，ゾーンのロードを停止します．
• ラウンドロビンを有効にする
  DNS ラウンドロビンは，同じ名前のレコードが複数存在した場合，問合せ毎に違う IP アドレスを返す機能です．
  このように「www」に対する IP アドレスが3つある場合，1回目は「192.168.1.1」を，2回目は「192.168.1.2」を，3回目は「192.168.1.3」を返します．4回目は「192.168.1.1」という形でローテートされます．

• ネットマスクの順序を考慮する
  このオプションが有効な場合，DNS ラウンドロビンの動作が変わります．
  問合せクライアントと同じサブネットのホストが登録されている場合，そのサブネットの IP アドレスが返ります．
  以下のイメージのとおり，接続元クライアントが「192.168.1.x」の場合は必ず「192.168.1.1」が返ります．接続元クライアントが全く違うサブネットにいる「192.168.4.x」などからの接続の場合は DNS ラウンドロビンが想定どおりに動作します．
  
  ですので，DNS ラウンドロビンを有効にする環境の多くでは，本オプションは無効にした方が想定どおり動作になるケースが多いと思います．

• Pollution に対してセキュリティでキャッシュを保護する
  DNS キャッシュの汚染は，DNS クエリの応答に権限のないデータや悪意のあるデータが含まれているときに発生します．
  このオプションはデフォルトで有効になっています．そのため，攻撃者が DNS サーバーが要求していないリソース レコードを使用した DNS サーバーのキャッシュを汚染することを防げます．
  無効にすると本セキュリティ機構が無効になるためチェックを外さないようにしましょう．
• リモート応答の DNSSEC 検証を有効にする
  リゾルバー (キャッシュサーバー) として利用する際，DNSSEC という公開鍵暗号を用いた DNS セキュリティ機構の検証有効にするかどうかを決定します．
  このオプションはデフォルトで有効になっています．今後 DNSSEC の利用はもっと増えていくため利用することを前提にしておいた方が安全性は高まります．

名前の確認

DNS レコードとしてどのようなラベルを利用できるかを決定します．デフォルトは「マルチバイト (UTF8)」になっています．通常変更する必要はないと思います．

• 厳密な RFC (ANSI)
  大文字，小文字の A から Z，数字およびハイフン「-」が利用可能です．また，先頭に限りアンダースコア「_」が利用できます．
• 非 RFC (ANSI)
  厳密な RFC に加えて，任意の場所でアンダースコア「_」が利用可能です．
• マルチバイト (UTF8)
  非 RFC に加えて UTF-8 のマルチバイト文字列が利用可能です．
• すべての名前
  マルチバイト (UTF8) に加えて任意の文字が利用可能です．

起動時にゾーンデータを読み込む

ゾーンデータをどこから読み込むのかを決定します．Active Directory ドメインサービスの統合 DNS の場合はデフォルトの「Active Directory とレジストリから」一択です．

古いレコードの自動清掃を有効にする

ダイナミックを利用しており，動的に DNS レコードが登録される環境において，更新されずに古いままとなっているレコードをクリーンアップ (削除) する場合にこのオプションを利用します．
デフォルトは無効ですが，有効にすることをお薦めします．

有効にした場合のデフォルトは「7日」となり，7日間更新されないままのレコードが清掃の対象となります．
デフォルトの「7日」は，DHCP リース期限のデフォルトに合わせているものと考えられますので，DHCP のリース期限で一番最長のリース期限に合わせるのが最良となります．

ルートヒント

リゾルバーとして動作させ，自身が名前解決を行う際に利用するルート DNS サーバーの一覧です．
a.root-servers.net から m.root-servers.net の13個があります．

通常は Windows Update を行うことで更新されますが，何らかの理由で更新が出来ない場合は適宜手動で更新する必要があります．

ルートヒントは IANA より「https://www.iana.org/domains/root/files」で公開されています．

デバッグのログ

DNSサーバーの動作をログファイルに出力できます．デバッグ用途で用いられる場合が多いのですが，DNS クエリーのログを保持しておきたい．という場合などでも利用されます．

ただし，ログのローテーションの機能は無いためタスクスケジューラーとスクリプトで実装する必要があります．

• パケットの方向
  • 発信
    チェックを付けると DNS サーバーから見て発信する方向のパケットのログを記録します．
  • 着信
    チェックを付けると DNS サーバーから見て着信する方向のパケットのログを記録します．
• トランスポート プロトコル
  • UDP
    チェックを付けると UDP パケットのログを記録します．
  • TCP
    チェックを付けると TCP パケットのログを記録します．
• パケットの内容
  • クエリ/転送
    チェックを付けると DNS 問合せに関するログを記録します．
  • 更新
    チェックを付けると DNS レコードの更新に関するログを記録します．
  • 通知
    チェックを付けると DNS ゾーンのレプリケーション (DNS Notify) に関するログを記録します．
• パケットの種類
  • 要求
    チェックを付けると DNS サーバーに対する要求に関するログを記録します．
  • 応答
    チェックを付けると DNS サーバーからの応答に関するログを記録します．
• 一致しない着信応答パケットのログを記録する
• 詳細
  チェックを付けるとログの内容が詳細になります．細かすぎるので使う必要はあまりないと思います．
• IPアドレスでパケットにフィルターをかける
  DNS サーバーへの問い合わせのクライアントや DNS サーバーから特定のホストへの再帰問合せなど，IP アドレスでマッチしたホスト間のログだけに絞る事ができます．

イベントのログ

イベントログにどのようなイベントを記録するかを決定します．デフォルトは「すべてのイベント」で，通常これを変える必要はないと思います．

監視

DNS サーバーの構成が正しく行われているかの検証を行うことができます．
NS のクエリーを送信しての動作確認を行っているようですが，正直言ってこれで OK と言えるようなテストにはなっていないように思えます．

設定を行ったら自分で確認を行う．および別途監視の仕組みを用いて任意のレコードの応答を確認する仕組みを用意したほうが良いです．

エージング / 清掃

Windows DNS サーバーは DNS レコードの動的更新が可能です．動的更新の動作については「次回」説明をします．
動的更新で登録されたレコードはデフォルトでは自動削除がなされず，長い時間を経過すると不要なレコードであふれる場合があります．

そのため，定期的な清掃が必要になります．これは DNS サーバー全体の設定として行うこともできますし，個々の DNS ゾーンで設定することもできます．

ここではDNS サーバー全体でエージング，清掃の設定を行う場合について説明します．

サーバーを選択，右クリックで「すべてのゾーンに対してエージング/清掃を設定する」をクリックします．

プロパティ画面が表示され，3つの設定項目が表示されます．

• 古いリソースレコードの清掃を行う
  この設定を有効(チェックを付ける)と自動清掃が有効になります．
• 非更新間隔
  非更新期間の間で REFRESH の要求を DNS サーバーが受取っても，DNS レコードのタイムスタンプは更新されません．
  REFRESH ではなく UPDATE の要求を受け取った場合はレコードを更新します．
  (DNS レコードのタイムスタンプも更新されます)
• 更新間隔
  更新期間には，REFRESH と UPDATE のどちらの要求も更新します．

清掃を行うため「古いリソースレコードの清掃を行う」にチェックを入れて「OK」をクリックします．

清掃にチェックを入れると確認画面が表示されます．「OK」をクリックすると，今後作成する AD 統合ゾーンについてはこの設定が反映される事になります．
また，ここで「この設定を既存の Active Directory 統合ゾーンに適用する」にチェックを入れると，既存の AD 統合ゾーンすべてに適用されます．設定の統一化を考えるとチェックを入れることをお薦めします．

自動清掃と清掃期間，更新間隔の補足

自動清掃の動作は，上のサーバープロパティで設定したの「清掃期間」と「非更新間隔」および「更新間隔」が関連してきます．

DNS のサービス起動後、「清掃期間」で設定されている時間の間隔清掃の処理が行われますが，実際に削除の処理が行われるのは「非更新期間」と「更新期間」を超えて一切更新が発生していない DNS レコードに対してのみとなります．

ですので，その間に更新 REFRESH や UPDATE が入ったレコードは対象外となりますので安心してください．

以上，DNS サーバーのオプションについての解説でした．
次回はゾーンの管理，レコードの登録について解説します．

本記事では一歩進んで Windows で利用可能な DNS クライアント，調査ツールである nslookup を使いこなすための解説を行います．

DNS 問合せのレスポンスコードや挙動，どういった場合にそれらが返るのかがわかるようになります．

• DNS に関するお話
  • DNS (Domain Name System) 概要 (1)
  • DNS (Domain Name System) 概要 (2)
  • DNS (Domain Name System) 概要 (3)
  • DNS (Domain Name System) – nslookup を使いこなそう
  • DNS (Domain Name System) – Windows DNS サーバーの設定・オプション
  • DNS (Domain Name System) – DNS ゾーンの作成
  • DNS (Domain Name System) – DNS ゾーンの設定とレコードの登録
  • DNS (Domain Name System) – サブドメインと委任
  • DNS (Domain Name System) – フォワーダーの構成
  • DNS (Domain Name System) – DNS の動的更新

nslookup の使い方

コマンドプロンプトを起動する

「cmd」を検索すると「コマンドプロンプト」が表示されますのでクリックしてコマンドプロンプトを表示します．

「nslookup」を実行すると nslookup プログラムが起動し，プロンプトが「>」に変わります．

それぞれのレコードの確認方法

正引きアドレス (Aレコード) を確認する

「www.google.com」の A レコードを確認するには，「www.google.com.」と入力します．
「www.google.com」の IP アドレスは IPv4 アドレスだと「142.250.207.4」，IPv6 アドレスだと「2404:6800:4004:820::2004」であることが分かります．

> www.google.com. [Enter]
サーバー:  UnKnown
Address:  192.168.250.2

権限のない回答:
名前:    www.google.com
Addresses:  2404:6800:4004:820::2004
          142.250.207.4

nslookup 起動時，規定では「type=any」が指定されていますので，何も考えずに FQDN を入力することで正引きの名前解決ができます．明示的に指定する場合は次のように type を指定してから実行します．

type=a は A レコードの解決をします．を明示しているため，上の例と違って IPv6 のアドレスは返ってきません．

> set type=a
> www.google.com
サーバー:  UnKnown
Address:  192.168.250.2

権限のない回答:
名前:    www.google.com
Address:  142.250.207.4

逆引きアドレス (PTR) を確認する

逆引きアドレスを確認するには「type=ptr」を指定の上検索したい IP アドレスを入力します．
本来正しくない入力方法ですが，このように IP アドレスを入力するだけでも Windows の nslookup は正しい逆引きアドレスを返してくれます．

> set type=ptr
> 142.250.207.4
サーバー:  UnKnown
Address:  192.168.250.2

権限のない回答:
4.207.250.142.in-addr.arpa      name = nrt13s54-in-f4.1e100.net

正しい逆引きアドレスの解決方法は，IP アドレスを逆順に入力してドメイン名に「.in-addr.arpa.」を入力します．
140.250.207.4 の逆引きアドレスは「4.207.250.140.in-addr.arpa.」になります．

> set type=ptr
> 4.207.250.142.in-addr.arpa.
サーバー:  UnKnown
Address:  192.168.250.2

権限のない回答:
4.207.250.142.in-addr.arpa      name = nrt13s54-in-f4.1e100.net

DNS サーバー (NS レコード) を確認する

あるドメインの権威 DNS サーバーを調べるには「type=ns」を指定の上，確認したいドメインを入力します．

「google.com」の場合は ns1.google.com ～ ns4.google.com が権威 DNS サーバーとなっており，それぞれのサーバーの IPv4 / IPv6 アドレスが分かります．

> set type=ns
> gooogle.com.
サーバー:  UnKnown
Address:  192.168.250.2

権限のない回答:
gooogle.com     nameserver = ns2.google.com
gooogle.com     nameserver = ns1.google.com
gooogle.com     nameserver = ns3.google.com
gooogle.com     nameserver = ns4.google.com

ns2.google.com  internet address = 216.239.34.10
ns2.google.com  AAAA IPv6 address = 2001:4860:4802:34::a
ns1.google.com  internet address = 216.239.32.10
ns1.google.com  AAAA IPv6 address = 2001:4860:4802:32::a
ns3.google.com  internet address = 216.239.36.10
ns3.google.com  AAAA IPv6 address = 2001:4860:4802:36::a
ns4.google.com  internet address = 216.239.38.10
ns4.google.com  AAAA IPv6 address = 2001:4860:4802:38::a

MX レコードを確認する

MX レコードを確認するには「type=mx」を指定の上，確認したいドメインや FQDN を入力します．

> set type=mx
> google.com.
サーバー:  UnKnown
Address:  192.168.250.2

権限のない回答:
google.com      MX preference = 10, mail exchanger = smtp.google.com

smtp.google.com internet address = 142.251.170.26
smtp.google.com internet address = 142.251.170.27
smtp.google.com internet address = 173.194.174.26
smtp.google.com internet address = 142.251.8.26
smtp.google.com internet address = 142.251.8.27
smtp.google.com AAAA IPv6 address = 2404:6800:4008:c19::1a
smtp.google.com AAAA IPv6 address = 2404:6800:4008:c19::1b
smtp.google.com AAAA IPv6 address = 2404:6800:4008:c15::1b
smtp.google.com AAAA IPv6 address = 2404:6800:4008:c15::1a

TXT レコードを確認する

TXT レコードを確認するには「type=txt」を指定の上，確認したいドメインや FQDN を入力します．
TXT レコードには SPF などの情報の他，ドメインの所有者証明に利用されると説明をしています．
google.com の TXT レコードはそのような情報が沢山記載されていることが確認できました．

> set type=txt
> google.com.
サーバー:  UnKnown
Address:  192.168.250.2

権限のない回答:
google.com      text =

        "onetrust-domain-verification=de01ed21f2fa4d8781cbc3ffb89cf4ef"
google.com      text =

        "atlassian-domain-verification=5YjTmWmjI92ewqkx2oXmBaD60Td9zWon9r6eakvHX6B77zzkFQto8PQ9QsKnbf4I"
google.com      text =

        "apple-domain-verification=30afIBcvSuDV2PLX"
google.com      text =

        "google-site-verification=wD8N7i1JTNTkezJ49swvWW48f8_9xveREV4oB-0Hf5o"
google.com      text =

        "google-site-verification=TV9-DBe4R80X4v0M4U_bd_J9cpOJM0nikft0jAgjmsQ"
google.com      text =

        "MS=E4A68B9AB2BB9670BCE15412F62916164C0B20BB"
google.com      text =

        "v=spf1 include:_spf.google.com ~all"

nslookup のオプションを理解する

先ほどより type=XXX と type は幾つか出していますが，nslookup はその他にも様々なオプションがあります．

検索ドメインの付与とは

search / nosearch の挙動について説明します．

規定の「search」の状態の場合，DNS 問合せの際に最後に「.」を付けない場合，検索ドメイン名を付与した問合せが先に行われます．画像内の「DNSサフィックス一覧」に記載のドメイン名です．

「lab.seichan.org」がサフィックス一覧にありますので，「.」を最後につけない場合は，従って次のような順番で DNS 問合せが行われます．

www.google.com.lab.seichan.org.
www.gooogle.com.

これはドメイン名を省略した問合せの場合に自動的に付加してくれるため，組織内の名前解決を行うには役に立ちますが，トラブルシュートを行う場合はこれによって混乱が生じる可能性があります．

ですので，明示的に「.」で終える癖をつけておくことをお薦めします．

nosearch を有効にすることで「.」を付けなくても付加を行わないようになります．

debug を使いこなす

debug を使いこなすことで DNS のトラブルシュートにおおいに役立ちます．
まずは代表的な DNS レスポンスコードについて知っておきましょう．

DNS レスポンスコード

その他のレスポンスについて知りたい方は以下の URL を参照ください．
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

nslookup の set debug の見方

1. 権威DNSサーバーからの回答なのかどうか
   非表示: 権威 DNS サーバーからの回答
   権限のない回答: リゾルバー (キャッシュサーバー) からの回答
2. Got answer: DNS 問合せのサマリー
   • rcode: レスポンスの結果
   • questions: 問合せの数
   • authority records: 権威サーバーの数
   • additional: 付加 (グルー)情報の数
3. QUESTIONS：問合せした内容
4. ANSWERS: 問合せの回答
5. AHTHORITY RECORDS:
   委任応答 (リゾルバーが回答) の場合，問い合わせたドメインの権威サーバーの情報が記載されます．
   権威 DNS サーバーが複数ある場合はその数分記載されます．
6. ADDITIONAL RECORDS:
   権威サーバーの IP アドレス (A や AAAA) を付加した情報が返されます．
   グルー (糊付け) レコードです．委任先の権威サーバー名と IP アドレスを一緒に返すことで名前解決のループを排除することができます．

NOERROR の DNS レスポンス

set debug を有効にした後の「www.google.com.」確認時の結果です．

rcode が NOERROR で応答があり，Answers が 1 以上なので，問合せに対して回答が返って来ていると判断できます．

NODATA の DNS レスポンス

set debug を有効にした後，MX レコードを検索しようとして「www.google.com.」を対象にした際の結果です．

rcode が NODATA ではなく，NOERROR で応答がありますが，Answers が 0なので，指定したリソース (MX) としては存在していないけれど，その他のリソースレコードとしては存在しているということになります．

このような場合，実行結果に権威 DNS サーバーの SOA の情報が表示されます．
この結果になった場合，指定したリソースレコード以外では存在するということがわかりますので 「type=any」で再度検索を行うとどのようなリソース種別で登録されているのか確認することができるはずです．

NXDOMAIN の DNS レスポンス

set debug を有効にした後，「hogehoge.google.com.」という存在しない名前を引いた場合のの結果です．

先の例と違いレスポンスが NXDOMAIN で返って来ていることから，指定したリソースおよびその他のリソースとしてもレコードは登録されていないということがわかります．

この場合の nslookup としての最終結果は「Non-existend domain」が表示されます．

今までの違いとしての NOERROR / NODATA / NXDOMAIN の応答の違いについて理解できたでしょうか．

SERVFAIL の DNS レスポンス

set debug を有効にした後の「www.google.com.」確認時の結果です．

レスポンスが SERVFAIL のため，リゾルバーには到達できたけど，その後の問合せを行ったドメインの権威 DNS サーバーまで到達ができなかった．などのリゾルバーと権威 DNS サーバーの間の何らかのエラーによって発生します．

このようなケースでは，実行結果としては「Server failed」が返ります．

権威 DNS サーバーまで到達できていないことから NODATA / NXDOMAIN と違って権威 DNS サーバーの情報も表示されません．

このような結果が返ってきた場合は以下が調査のポイントとなります．

• リゾルバー (キャッシュサーバー) から先 (フォワードを行っていればフォワード先，行っていなければインターネット) のネットワークの疎通性があるか
• 全てのドメインで発生するのか，一部のドメインだけなのか
  • 一部のドメインだけ．の場合，条件付きフォワードが一番疑われます．また本当にそのドメインの権威 DNS サーバーが動作していないかもしれません
  • 全てのドメインの場合，問題はこちら側にあります．疎通性の確認などを一つ一つ明らかにしていく必要があります．

REFUSED の DNS レスポンス

set debug を有効にした後の「www.google.com.」確認時の結果です．

レスポンスが REFUSED のため，リゾルバー (や問合せを行っている DNS サーバー) が問合せを拒否している状態となります．

この場合の実行結果としては「Query refused」が返されます．

もちろん，問合せの段階で拒否されていますので NODATA や NSDOMAIN と違い権威 DNS サーバーの情報も表示されません．

このような結果が返ってきた場合は以下が調査のポイントとなります．

• リゾルバー自体の ACL の確認．クライアントからの問い合わせを許可しているのか
• ネットワーク，Firewall の確認 DNS サーバーアクセスを拒否していないか

FORMERR の DNS レスポンス

FORMERR を Windows の nslookup で実現させることが難しく，Linux などでよく用いられる dig コマンドを利用しています．

EDNS0 を有効にして問合せを行っていますが，リゾルバーが対応しておらず，512 byte 内に収まらないため FORMERR という結果が返ります．

通常であれば，ここで TCP Fallback するのでこのようなエラーになる事は稀です．

もしこのような結果になった場合の調査ポイントは次のとおりです

• UDP Port 53
  512 byte 超のパケットがとおるようになっているか
  • クライアント – リゾルバーの間の Firewall やルーター
  • リゾルバー – 権威 DNS サーバーの間 の Firewall やルーター
• TCP Port 53
  TCP Fallback した際に TCP Port 53 を利用した通信が可能な状態か

以上で nslookup についての解説を終わります．
次回は Windows DNS の設定について解説していきますので引き続き見て頂ければと思います．

DNS の動き，仕組みを理解することでインターネットに留まらず Active Directory ドメインサービスなどのイントラネットにも役に立ちますので是非理解しましょう．

本記事では，DNS レコードについて解説していきます．

• DNS に関するお話
  • DNS (Domain Name System) 概要 (1)
  • DNS (Domain Name System) 概要 (2)
  • DNS (Domain Name System) 概要 (3)
  • DNS (Domain Name System) – nslookup を使いこなそう
  • DNS (Domain Name System) – Windows DNS サーバーの設定・オプション
  • DNS (Domain Name System) – DNS ゾーンの作成
  • DNS (Domain Name System) – DNS ゾーンの設定とレコードの登録
  • DNS (Domain Name System) – サブドメインと委任
  • DNS (Domain Name System) – フォワーダーの構成
  • DNS (Domain Name System) – DNS の動的更新

押さえておきたい DNS レコード

DNS レコードにはいくつかの種別があります．押さえておきたいレコード種別と役割を表にまとめました．

SOA

SOA (Start Of Authority) は，ゾーンの起点を示し，ゾーンの管理情報を定義するレコードです．
SOA リソースレコードは，一つのゾーンに一つだけ記述されます．

SOA リソースレコードの中には次の情報が定義されます．

Windows DNS で SOA リソースレコードのプロパティを表示した際，以下のとおりにマップされます．

MINIMUM の扱われ方の注意点

MINIMUM に指定する値は、昔 (RFC 1035) と現在 (RFC 2308) で目的が変わっています．

• 【昔 (RFC 1035) 】該当ゾーン(ドメイン)にあるレコードのデフォルトTTL
• 【現在 (RFC 2308)】ネガティブキャッシュのTTL

以前はゾーン(ドメイン) のデフォルト TTL として利用されていましたが，現在はネガティブキャッシュの TTL として利用されています．

このことから，古いドキュメントや Web サイトを参考に設定してしまうとトラブルを起こしてしまう場合があります．
例えば，古いドキュメントでよくある記載例 86400(1日) で設定されていると，ネガティブキャッシュ TTL が 1日となってしまい，レコード情報を変更しても名前解決の結果が更新されない事象が発生します．
nslookup 等で値が更新されないけど DNS キャッシュサーバーを再起動したら，新しいレコード情報を取得できるようになった．という場合はこのような要因が考えられます．

NS

NS (Authoritative Name Server) はゾーンを管理する権威 DNS サーバーを指定するレコードです．
複数の権威 DNS サーバーがある場合はそのサーバーの数だけレコードを記載する必要があります．
NS レコードで指定したホストは A または AAAA レコードでアドレスが解決出来る必要があります．
NS レコードのホスト名は CNAME のホスト名は許されません．

Windows DNS サーバーの NS レコードは次のように指定されます．

NS レコードに対応する A レコードが必要です．先にも述べましたが，CNAME は許されていませんので注意してください．

MX

MX (Mail eXchange) レコードはメールを配送するホスト (メールサーバー) を記載するレコードです．
ホストが複数いる場合は複数記載することができます．複数記載されている場合，プリファレンス値が小さい (優先度が高い) ホストがメール配送において優先して利用されます．

ドメインしか記載できないと思われることがありますが，そうではありません．ホスト (FQDN) 宛てを MX として登録することも可能です．
以下は lab.seichan.org (この DNS ゾーン) の他，mail.lab.seichan.org の MX レコードを登録した場合を掲載します．

プレファレンス値は必ず大小付けなければならないという訳でもありません．上の画像のとおり「mail.lab.seichan.org」の MX レコードのプレファレンス値は両方とも「10」で登録をしています．
この場合，どちらのホストに配送するのかは送信元の判断になります．

A と AAAA

ホストに対応する IP アドレスを記載するレコードです．IPv4 アドレスの場合は A レコード，IPv6 アドレスの場合は AAAA レコードを使用します．

ホスト名が一つでも，A/AAAA レコードは複数用意する事が出来ます．その場合，例えば「www.lab.seichan.org」のレコードが複数あり，IP アドレスが違う場合というケースになりますが，アクセス元がいずれかのホスト (IP アドレス) に対して接続を行います．

DNS ラウンドロビンを期待してこの手法を用いるケースが多いですが，DNS ラウンドロビンが行われるかはリゾルバーの挙動によります．
(一部リゾルバーではランドロビンしない実装もありますし，ラウンドロビンを無効化する設定もあります)

ホスト名が違っていても，A/AAAA レコードで記載する IP アドレスは重複しても構いません．
必ず CNAME にしないといけないという訳ではありません．

例として，「www.lab.seichan.org」と「ftp.lab.seichan.org」で同じ IP アドレスを登録しているケースを掲載します．

SRV

SRV (SeRVice) レコードは，ドメインに対するサービスの場所を指定するレコードです．一番メジャーな利用形態は Active Directory ドメインサービスで利用されています．

あるサービス (例えば LDAP サーバー) のがどこにあるか (IP アドレスは何か) を調べる為に利用されます．

これによって，クライアントの設定で明示的に指定しなくても適切なサーバーを探してアクセスできるようになります．

レコードは「_ldap._tcp.lab.seichan.org」のように記載され，付随して優先度，ポート情報などをレコード情報として登録します．

Windows DNS サーバーで SRV レコードは次のように Active Directory ドメインサービスの各サービスにアクセスするために用いられます．

PTR

PTR (PoinTeR) レコードは，IP アドレスに対するドメイン名 (FQDN) を記載するレコードです．逆引きレコードと呼ばれます．

逆引きレコードが存在しない場合，逆引きを行うサービスのレスポンスが遅くなる (または失敗する) 場合があります．例えば Linux サーバー等への SSH 接続が遅い．などがあります．

殆どの場合，逆引きの名前解決を必要としないものが多いのですが，要件として必須になっている製品もありますので，必要・不必要は十分判断する必要があります．

TXT

TXT (TeXT) レコードは任意の値を記載するレコードです．最長255文字 (255オクテット) を記載する事ができます．

主な利用用途としては，メールサーバーの SPF や DKIM，DMARC などに用いられます．
また，クラウドサービスなどの利用の際にドメインの所持者であることを確認するために TXT レコードに文字列を定義して確認する．などの利用もあります．

CNAME

CNAME (Canonical NAME) は正式名に対する別名を記載するレコードです．トラブルの元になる為，よく理解して利用する必要があります．

A または AAAA は上述していますが，同じホスト名で複数の A レコードを持つことも，同じ IP アドレスで複数の A レコードを持つこともできますので，A や AAAA の利用を検討しましょう．

NS や MX レコードの値に CNAME のホストを記載することはできません

NG の例①

lab.seichan.org NS dns.lab.seichan.org
lab.seichan.org MX 10 mail.lab.seichan.org

ad01.lab.seichan.org A 192.168.250.1

dns.lab.seichan.org CNAME ad01.lab.seichan.org
mail.lab.seichan.org CNAME ad01.lab.seichan.org

正しい例①

lab.seichan.org NS dns.lab.seichan.org
lab.seichan.org MX 10 mail.lab.seichan.org

ad01.lab.seichan.org A 192.168.250.1

dns.lab.seichan.org A 192.168.250.1
mail.lab.seichan.org A 192.168.250.1

または

lab.seichan.org NS ad01.lab.seichan.org
lab.seichan.org MX 10 ad01.lab.seichan.org

ad01.lab.seichan.org A 192.168.250.1

CNAME の別名に対しての別 CNAME を定義してはいけません

NG の例②

ftp.lab.seichan.org CNAME www.lab.seichan.org
www.lab.seichan.org CNAME ad01.lab.seichan.org
ad01.lab.seichan.org A 192.168.250.1

正しい例 ②

ftp.lab.seichan.org CNAME ad01.lab.seichan.org
www.lab.seichan.org CNAME ad01.lab.seichan.org
ad01.lab.seichan.org A 192.168.250.1

CNAME と 別名は 1:1 である必要があります

NG な例 ③

www.lab.seican.org CNAME ad01.lab.seichan.org
www.lab.seichan.org CNAME ad02.lab.seichan.org
ad01.lab.seichan.org A 192.168.250.1
ad02.lab.seichan.org A 192.168.250.2

正しい例 ③

www.lab.seican.org A 192.168.250.1
www.lab.seichan.org A 192.168.250.2
ad01.lab.seichan.org A 192.168.250.1
ad02.lab.seichan.org A 192.168.250.2

以上，DNS レコードの解説でした．
次回は，nslookup を用いた DNS 問合せやトラブルシューティング時に役立つお話について解説します．