MS_DNSServer
DNSサーバは、DNSプロトコルのサーバ側実装。
-
DNSサーバは、FQDN名をIPアドレスに変換するサーバである。
特にインターネット上のDNSサーバは、ドメイン階層に合わせて配置されたDNSサーバが
連携して動作する名前解決用の広域ディレクトリ サービスである。 -
DNSサーバの名前解決の仕組みについて以下説明する。
- DNSサーバは、UDPポート53番でDNSクエリ（ユニキャスト）を受信する
（ただし、DNSメッセージが512オクテットを超えた場合はTCPポート53番を使用する）。 - DNSクライアントに結果となるIPアドレスを返す名前解決システムである。
DNSクライアントは、UDPポート53番で応答（ユニキャスト）を受信する。 - また、ゾーン転送の際は、信頼性を確保するためTCPポート53番を使用する。
- DNSクライアントは、DNSサーバのIPアドレスを知るためにDNSサーバを使うことはできないので、
あらかじめDNSクライアントにDNSサーバのIPアドレスを設定するかDHCPを使用して配信する必要がある。
- DNSサーバは、UDPポート53番でDNSクエリ（ユニキャスト）を受信する
補足（最新化）: 512オクテット制限は EDNS0（RFC 6891）により拡張でき、 現在は UDP で 1232 オクテット程度までを推奨とする運用が一般的 （それを超えると TCP へフォールバックする）。 また、経路の暗号化として DoT（DNS over TLS, 853/tcp）や DoH（DNS over HTTPS, 443/tcp）が普及している。
DNSサーバには、
- サーバ
- コンテンツ サーバ
- フルサービス リゾルバ（キャッシュ サーバ）
- スレーブ サーバ
- フォワーダ
- クライアント
- スタブ リゾルバ
などの種類がある。次に、これらのDNSサーバの種類と特長について説明する。
- 「コンテンツ サーバ」は、自分が管理しているゾーンに対するDNSクエリだけに回答し、
名前解決ができなくても他のDNSサーバにDNSクエリを送信しないDNSサーバである。 - インターネット上に「コンテンツ サーバ」を配置する場合は、
- 上位のドメインの「コンテンツ サーバ」から「委任」されている必要がある。
- ここではDNSのドメインを指す。機能的に見て、ADのドメインとは完全に一致しないので注意する。
- DNSでは、ドメインを複数のサブドメインに分割し、「委任」により親ドメインから子ドメインを信頼して管理を分散する。
- 「コンテンツ サーバ」はドメイン階層に合ったドメイン ツリー構造をとる。
- インターネット上のドメイン ツリーは、「委任」により世界中のDNSサーバをつなぐ「信頼の連鎖」ツリーでもある。
- 上位のドメインの「コンテンツ サーバ」から「委任」されている必要がある。
補足: 「コンテンツ サーバ」は、現在の用語では 権威サーバ（authoritative server） と呼ばれることが多い。
- 「コンテンツ サーバ」はドメイン ツリー構造をとることがあるので、
- これに対して、自身がドメイン ツリー上の「コンテンツ サーバ」を走査することなく、
他のDNSサーバにこのような処理を依頼するためのDNSクエリを「再帰クエリ」と呼ぶ。- クライアントPCなどが送信する「再帰クエリ」を受信し、ドメイン ツリー上の個々の
「コンテンツ サーバ」に「反復クエリ」を送信するDNSサーバを「フルサービス リゾルバ」と呼ぶ。 - 「フルサービス リゾルバ」は、「再帰クエリ」で要求された名前解決が完了するまで、
他のDNSサーバに「反復クエリ」を送信する。- 「フルサービス リゾルバ」には、「ルート ヒント」として「ルート ネーム サーバ」のIPアドレスを設定する。
- また、各「コンテンツ サーバ」は、NSリソースレコードに
下位ドメイン（委任先）の「コンテンツ サーバ」の名前とIPアドレスを持っている。 - このため「フルサービス リゾルバ」は、「ルート ネーム サーバ」からの走査（反復クエリの実行）が可能になる。
- また、同じ問い合わせを何度も繰り返すという非効率を避けるため、
一度名前解決をした情報を内部にキャッシュして再利用することから「キャッシュ サーバ」とも呼ばれる。
- クライアントPCなどが送信する「再帰クエリ」を受信し、ドメイン ツリー上の個々の
- また、「コンテンツ サーバ」と「フルサービス リゾルバ」の両方の機能を持つようなDNSサーバも存在する。
「フルサービス リゾルバ」に「再帰クエリ」を送信する、
端末側で動作する「リゾルバ」（DNSクライアント）を「スタブ リゾルバ」と呼ぶ。
また、「再帰クエリ」を他サーバへ転送し、自身は「反復クエリ」を送信しない
「スタブ リゾルバ」機能だけを実装しているDNSサーバを俗に「スレーブ サーバ」と呼ぶ。
コンテンツ サーバがDNSクエリを処理する際、
「別のDNSサーバを紹介したり別のDNSサーバへDNSクエリを転送したりする機能」
に「条件付きフォワーダ」と「スタブ ゾーン」がある。
- 内部ドメイン（イントラネット）で名前解決できないDNSクエリなどを、
外部ドメイン（インターネット）に転送する場合、「条件付きフォワーダ」を定義してDNSクエリを転送する。 - 「条件付きフォワーダ」では、特定のドメイン名に基づいてDNSクエリを転送することもできる。
また、転送先のDNSサーバを「フォワーダ」と呼ぶ。
- 企業の合併により、2つの異なる内部ドメイン（イントラネット）で、
名前解決が必要になる場合などにも、この「条件付きフォワーダ」が利用できる。
-
「委任」では、親ドメインの管理者は子ドメインのゾーン データをホストするコンテンツ サーバの
FQDN名とIPアドレスのリソースレコードを手動で管理する必要があるが、
「スタブ ゾーン」を利用することで、この管理を自動化できる。 -
「スタブ ゾーン」には、子ドメインのマスタ サーバのIPアドレスを持つリソースレコードが含まれており、
子ドメインのマスタ サーバと通信することで最新のゾーン データを取得できる。 -
マスタ サーバは、
- 子ドメインの「プライマリ ネームサーバ」
- または「セカンダリ ネームサーバ」
である。
これにより、「スタブ ゾーン」をホストする親ドメインの「コンテンツ サーバ」では、子ドメインの管理を自動化できる。
また、「スタブ ゾーン」をホストする親ドメインのコンテンツ サーバが、
子ドメインに対するDNSクエリを受信した場合、次のような処理を実行する。
- 再帰クエリの場合
親ドメインのコンテンツ サーバは「スタブ ゾーン」のリソースレコードを使って、
子ドメインのコンテンツ サーバに「反復クエリ」を送信する。 - 反復クエリの場合
親ドメインのコンテンツ サーバは「スタブ ゾーン」のリソースレコードを使って、
子ドメインのコンテンツ サーバへの紹介を返す。
例えば、家庭LANのBBルータなどは「スレーブ サーバ」的な機能を提供する。
BBルータを使用した家庭LAN上のPCで「ipconfig /all」コマンドを実行すると、
BBルータ上のDHCPサーバから、デフォルト ゲートウェイ・DNSサーバ（スレーブ サーバ）
にBBルータのIPアドレスが設定されていることを確認できる。
>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : （ホスト名）
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter ローカル エリア接続:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : （NIC名）
Physical Address. . . . . . . . . : （NICのMACアドレス）
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : （ローカルマシンのIPアドレス）
Subnet Mask . . . . . . . . . . . : （サブネット マスク）
Default Gateway . . . . . . . . . : （BBルータのIPアドレス）
DNS Servers . . . . . . . . . . . : （BBルータのIPアドレス）
この場合、プロバイダ指定のDNSサーバがフルサービス リゾルバに相当する。
各ノードで管理されるDNS情報の単位を「ゾーン」と呼ぶ。
- 「ゾーン」は、1個から複数個のドメインの情報を記載する。
- 「ゾーン」が複数のDNSサーバに跨って保持されることは無い。
- 「前方参照ゾーン」とは、DNSによる正引き名前解決に必要なゾーン データであり、必ず作成する必要がある。
- 一般的にコンテンツ サーバのドメイン ツリー構造といった場合、「前方参照ゾーン」のツリー構造を指す。
移行メモ（正誤）: 原文は「一般的にコンテンツ サーバのドメイン ツリー構造といった場合、 **『逆引き参照ゾーン』**のツリー構造を指す」となっていたが、 直前の文（前方参照ゾーンの説明）と矛盾しており、 一般に言うドメイン ツリーは正引き（前方参照）側を指す。前方参照ゾーンに改めた。
DNSによる逆引き名前解決に必要なゾーン データである。
- 「前方参照ゾーン」のコンテンツ サーバのドメイン ツリーとは別に、
「逆引き参照ゾーン」のコンテンツ サーバのツリーも存在する。 - ルート ネーム サーバは共通のコンテンツ サーバになっている。
- 「逆引き参照ゾーン」のトップ レベル ドメインとセカンド レベル ドメインは、
「.in-addr.arpa」という特別な名前が付けられている。 - セカンド レベル ドメイン以降のドメイン名は、検索の基になるIPアドレスの各オクテットを逆順に並べたものになる。
- 例えば、「vvv.xxx.yyy.zzz」というIPアドレスのホストは、
「zzz.yyy.xxx.vvv.in-addr.arpa」というゾーンに格納される。
クラスレス アドレッシング（CIDR）が適用された環境下では、この限りではない。
移行メモ（正誤）: 原文の例は「『zzz.yyy.xxx.vvv』というIPアドレス …… は 『arpa.in-addr.xxx.yyy.zzz』というゾーンに格納される」となっていたが、 ドメイン名の並び自体が逆順に書かれており、オクテットの対応も取れていなかった。 正しくは IPアドレス
a.b.c.dに対してd.c.b.a.in-addr.arpa。 なお IPv6 の逆引きはip6.arpaを使う（ニブル単位で逆順）。
「スタブ ゾーン」で説明。
ゾーン データの単位を「レコード」、「リソース レコード」と言う。
FQDNからIPv4アドレスを調べる。
| FQDN | TTL | Class | Type | IPアドレス |
|---|---|---|---|---|
| www.example.com. | 1D | IN | A | xxx.xxx.xxx.xxx |
FQDNからIPv6アドレスを調べる。
| FQDN | Class | Type | IPアドレス |
|---|---|---|---|
| www.example.com. | IN | AAAA | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff |
移行メモ（正誤）: 原文は A / AAAA の説明を 「IPv4（v6）アドレスからFQDNを調べる」としていたが、方向が逆。 A / AAAA は FQDN → IPアドレス（正引き）のレコードで、 IPアドレス → FQDN は PTR（逆引き）が担う。
- Aレコードの別名を追加（≒ 別名に対する正式名を指定）
- 特定のホスト名を別のドメイン名に転送する時などに利用。
| 別名（FQDN） | TTL | Class | Type | 正式名（FQDN） |
|---|---|---|---|---|
| www2.example.com. | 1D | IN | CNAME | www.example.com. |
該当ドメインのゾーンの権威を持つDNSサーバのFQDNを指定する。
| ゾーン名 | TTL | Class | Type | DNSのFQDN |
|---|---|---|---|---|
| example.com. | 1D | IN | NS | ns1.example.com. |
ゾーンに関する特定のauthoritative情報。
| ドメイン | TTL | Class | Type | マスターサーバ | メールアドレス |
|---|---|---|---|---|---|
| example.com. | 1D | IN | SOA | ns.example.com. | root.example.com. |
- プライマリネームサーバ
- ドメイン管理者の電子メール
- ドメインのシリアル番号
- ゾーンのリフレッシュに関連するいくつかのタイマー
メアド用ドメインに対応するメールサーバのFQDNを指定する。
| メアド用ドメイン | TTL | Class | Type | プリファレンス値 | メールサーバのFQDN |
|---|---|---|---|---|---|
| example.co.jp. | 1D | IN | MX | 10 | mail.example.co.jp. |
逆引き専用のリソースレコード
| 逆引きドメイン | TTL | Class | Type | 正式名（FQDN） |
|---|---|---|---|---|
| 10.1.168.192.in-addr.arpa. | 1D | IN | PTR | www.example.com. |
移行メモ（正誤）: 原文の見出しは「PTR（Canonical NAME）リソースレコード」だったが、 Canonical NAME は CNAME の正式名称。PTR は Pointer。
ドメインのコメントを調べる。
| ドメイン | Class | Type | コメント |
|---|---|---|---|
| example.co.jp. | IN | TXT | www.example.com. |
※ 最近は、SPFなど機械可読データに利用されるようになった。
メール送信元ドメインの許可された送信元を調べる。
メール送信元ドメインは、エンベロープFromのもの（メールを参照）。
| ドメイン | Class | Type | コメント |
|---|---|---|---|
| example.co.jp. | IN | TXT | "v=spf1 +ip4:192.168.100.0/24 ~all" |
※ TXT（Text）リソースレコードを流用する。
※ 指定されているIPアドレスは「メール送信元ドメインの許可された送信元」である。
補足（最新化）: かつて専用の SPF レコードタイプ（Type 99）が定義されたが、 RFC 7208 で廃止され、現在は TXT レコードのみを使う。
spf2.0/praは Sender ID 用の記述で、Sender ID 自体が事実上使われていないため省略した。
メール送信元ドメインの SPF & DKIM のポリシを調べる（メールを参照）。
| ドメイン | Class | Type | コメント |
|---|---|---|---|
| _dmarc.example.co.jp. | IN | TXT | "v=DMARC1; p=none; rua=mailto:dmarc@example.co.jp" |
※ TXT（Text）リソースレコードを流用する。
※ パラメタについては、下記の表を参照。
| # | パラメタ | 概要 |
|---|---|---|
| 0 | v | バージョン番号（現状 DMARC1 のみ） |
| 1 | adkim | DKIM 認証識別子のアライメントモード (r=relaxedモード, s=strictモード) |
| 2 | aspf | SPF 認証識別子のアライメントモード (r=relaxedモード, s=strictモード) |
| 3 | p | メール受信者に要望する認証失敗時の動作 (none=なにもしない, quarantine=迷惑, reject=拒否) |
| 4 | sp | ポリシーをサブドメインに適用するかどうか (none/quarantine/reject) |
| 5 | pct | ポリシーを適用するメールの割合 (0〜100, デフォルトは100) |
| 6 | rua | 集約レポートの送り先（URI で指定） |
| 7 | ruf | 失敗レポートの送り先（URI で指定） |
| 8 | ri | 集約レポートの送信間隔（デフォルトは86400秒=24時間） |
| 9 | fo | 失敗レポートのオプション (0=全て成功しない場合, 1=何れか１つに成功しない場合, d=DKIMに成功しない場合, s=SPFに成功しない場合) |
| 10 | rf | 失敗レポートの形式（現状 afrf のみ） |
- モード（認証ドメインとヘッダFromのドメインの比較方法）
- r=relaxedモードはサブドメインを許可
- s=strictモードは完全一致
移行メモ: DMARC レコードを置くのはドメイン直下ではなく
_dmarc.<ドメイン>のサブドメインなので、表のドメイン欄をその形に改めた。
- EDNS0により定義される、特殊なリソースレコード
- DNSをDNSSECやIPv6に対応させる場合、EDNS0への対応が必須とされている。
-
コンテンツ サーバには、冗長構成を組む時のために、
- 「プライマリ ネームサーバ」
- 「セカンダリ ネームサーバ」
の区分けがある。
-
コンテンツ サーバは、冗長化による可用性の向上を要求されることがある。
- 例えば、インターネット上のjpドメインを管理するコンテンツ サーバは、
JPNIC（社団法人日本ネットワークインフォメーションセンター）の方針で、
2台のコンテンツ サーバを使い冗長化することが要求される。
- 例えば、インターネット上のjpドメインを管理するコンテンツ サーバは、
-
この冗長化の方式に
- 「プライマリ ネームサーバ」のゾーン データ（プライマリ ゾーン）を、
- 「セカンダリ ネームサーバ」のゾーン データ（セカンダリ ゾーン）に
- レプリケーションする「ゾーン転送」と呼ぶ方式がある。
「プライマリ ネームサーバ」は、「ゾーン ファイル」を自身で保存する。
- 「セカンダリ ネームサーバ」は、ネットワークを経由して
「プライマリ ネームサーバ」の「ゾーン ファイル」をレプリケーションする。 - 「セカンダリ ネームサーバ」は多くの場合、1台以上登録できる。
- 「フルサービス リゾルバ」は
- 「プライマリ ネームサーバ」・「セカンダリ ネームサーバ」を区別しない。
- 設定されている優先順位に合わせて、ネームサーバを選択し、
- 1つ目のネームサーバでうまく解決できなかった場合、
- 2つ目のネームサーバを使用する。
- また、類似した言葉に「優先DNSサーバ」・「代替DNSサーバ」があるが、
- これ自体が「フルサービス リゾルバ」（キャッシュ サーバ）であることもある。
- しかし、「優先DNSサーバ」・「代替DNSサーバ」と
「プライマリ ネームサーバ」・「セカンダリ ネームサーバ」が対応しない場合もある。
- セカンダリ ネームサーバは、セカンダリ ネームサーバの「SOA」レコードに含まれる
「更新間隔」が経過したら、「SOA要求」を送信する。 - プライマリ ネームサーバは「SOA要求」を受信し、プライマリ ネームサーバの
「SOA」レコードに含まれる「シリアル番号」を、「SOA返信」として返信する。 - セカンダリ ネームサーバは「シリアル番号」を参照し、ゾーン ファイルが更新されていることを確認する
（受信した「シリアル番号」が、自身の保持する「シリアル番号」より大きい場合、
ゾーン ファイルが更新されていることを意味する）。 - ゾーン ファイルが更新されている場合、セカンダリ ネームサーバは「ゾーン転送要求」を送信する。
- プライマリ ネームサーバは「ゾーン転送要求」を受信し、ゾーン転送を開始する。
この時、ゾーン転送の種類として「完全ゾーン転送」・「差分 / 増分ゾーン転送」を選択できる。- 「完全ゾーン転送」（AXFR）
- すべてのDNSサーバにサポートされている標準的なレプリケート処理で、
ゾーン ファイル全体が「プライマリ ネームサーバ」から「セカンダリ ネームサーバ」にレプリケートされる。
- すべてのDNSサーバにサポートされている標準的なレプリケート処理で、
- 「差分 / 増分ゾーン転送」（IXFR）
- 転送量を減らすことができる。
- 「プライマリ ネームサーバ」のゾーンの変更履歴から、
「セカンダリ ネームサーバ」のゾーン ファイルとの差分 / 増分情報のみがレプリケートされる。 - 「プライマリ ネームサーバ」が「差分 / 増分ゾーン転送」をサポートしないか、
またはゾーンの変更履歴がない場合は、「完全ゾーン転送」でレプリケートされる。
- 「完全ゾーン転送」（AXFR）
- セカンダリ ネームサーバは、この転送データをもとに、自身のゾーン ファイルを
最新の情報に更新し、新しいゾーン ファイルを有効にする。
移行メモ（正誤）: 手順5の原文は「プライマリ ネームサーバは**「SOA要求」を受信し**、 ゾーン転送を開始する」となっていたが、手順4で送信されているのは「ゾーン転送要求」。 受信するものを「ゾーン転送要求」に改めた。
※ ゾーン転送は、
- 一般的にはセカンダリ ネームサーバ側から要求がされる（プル型）。
- ただし、プライマリ ネームサーバからゾーン ファイルの更新をセカンダリ ネームサーバに
「通知」することもできる（プッシュ型、NOTIFY）。 - また、信頼性を確保するためプロトコルにはTCPを使用する。
以下に、WindowsでのDNSクライアントを構成する場合の設定方法を示す。
- [スタート] ⇒ [設定] ⇒ [ネットワーク接続] ⇒ [ローカルエリア接続]を右クリックし[プロパティ]を選択する。
- 表示されたダイアログの[全般]タブで「インターネット プロトコル（TCP/IP）」を選択し、[プロパティ]ボタンを押す。
- [全般]タブのプロパティを設定することで、「優先DNSサーバ」・「代替DNSサーバ」のIPアドレスを設定できる。設定箇所には、以下の3箇所がある。
- DHCPサーバから各DNSサーバのIPアドレスを取得する場合は、[DNSサーバのアドレスを自動的に取得する]オプション ボタンを選択する。
- 「優先DNSサーバ」・「代替DNSサーバ」の各IPアドレスを設定するには、[次のDNSサーバのアドレスを使う]オプション ボタンを設定し、DNSサーバのIPアドレスを直接入力する。
- 3台以上の「代替DNSサーバ」のIPアドレスを設定するには、
[TCP/IP詳細設定]ダイアログの[DNS]タブの[DNSサーバー アドレス]リスト ボックスにDNSサーバのIPアドレスを設定する。
リストの上から順番に問い合わせるので、一番上が「優先DNSサーバ」になる。
- ユーザがドメイン名を省略してホスト名だけでアクセスしようとした場合、
DNSクライアント（リゾルバ）がホスト名から自動的にFQDN名を生成して名前解決をする。 - このFQDN名の生成処理は、DNSの検索サフィックスとオプションを変更することで動作を変更できる。
- [ローカルエリア接続]のプロパティから「インターネット プロトコル（TCP/IP）」の[プロパティ]を開く。
- [全般]タブの[詳細設定]ボタンを押して表示される、[TCP/IP詳細設定]ダイアログの[DNS]タブにDNSの検索サフィックスを設定する。設定箇所には、以下の2箇所がある。
- [プライマリおよび接続専用のDNSサフィックスを追加する]オプション ボタン
「プライマリDNSサフィックス」と「接続専用のDNSサフィックス」をFQDN名の生成処理に使用するようになる。
同時に[プライマリDNSサフィックスの親サフィックスを追加する]チェック ボタンを選択すると、
「プライマリDNSサフィックス」の親ドメインのDNSサフィックスを順番にFQDN名の生成処理に使用するようになる。 - [以下のDNSサフィックスを順に追加する]オプション ボタン
リスト ボックスにDNSサフィックスを入力することで、リストの上のDNSサフィックスを順番に使用するようになる。
- [プライマリおよび接続専用のDNSサフィックスを追加する]オプション ボタン
WindowsにローカルPCのFQDN名を生成する元情報である
- 「プライマリDNSサフィックス」
- 「接続専用のDNSサフィックス」
を設定する手順を以下に示す。これらは、DNSの検索サフィックスとしても使用される。
ここで設定した、DNSの検索サフィックスは、「ipconfig /all」コマンドを使用して確認できる。
- [コントロール パネル] ⇒ [システム]を選択し、[システムのプロパティ]ダイアログを表示させる。次に、[コンピュータ名]タブに移動し、[変更]ボタンを押す。
- [コンピュータ名の変更]ダイアログが表示されるので、[詳細]ボタンを押す。これにより、[DNSサフィックスとNetBIOSコンピュータ名]ダイアログが表示される。
- 「プライマリDNSサフィックス」は、ここの[このコンピュータのプライマリDNSサフィックス]に入力することで設定可能である。
- [ローカルエリア接続]のプロパティから「インターネット プロトコル（TCP/IP）」の[プロパティ]を開く。
- [全般]タブの[詳細設定]ボタンを押して表示される、[TCP/IP詳細設定]ダイアログの[DNS]タブの下部のテキスト ボックスで設定できる。
下記に該当する場合に利用できる、そのホスト名とIPアドレスの対応を動的に登録・管理するための
仕組みとして「ゾーン ファイルの動的更新機能」がある。
- DHCPサーバ（または、PPPのNCPプロトコル）から動的にIPアドレスが割り当てられる場合
- 静的にIPアドレスを割り当てるが、頻繁に設定が変更される場合
この「ゾーン ファイルの動的更新機能」に対応したDNSをDDNS（Dynamic DNS）という。
DDNSは、その用途・形態から大きく以下の2通りに分けることができる。
- イントラネット内の動的更新
- DHCPサーバから動的にIPアドレスが割り当てられたホストが、
DNSサーバに対して直接、ゾーン ファイルを動的に更新する。 - このため、各ホストが「プライマリ ネームサーバ」を直接利用できる形態である必要がある。
- DHCPサーバから動的にIPアドレスが割り当てられたホストが、
- インターネット環境の動的更新
- FTTHなどの常時接続サービスにおいて、イントラネットで用いられるDDNSの発想を受けて、DDNSサービスが普及した。
-
PPPのNCPプロトコルから動的にIPアドレスが割り当てられたBBルータが、
DNSサーバに対して、ゾーン ファイルを動的に更新する。 - BBルータが動的更新機能を持たない場合、イーサネット上のホストから、
専用のDDNSクライアント ツールを使用して定期的にゾーン ファイルを動的に更新する方法もある。
-
PPPのNCPプロトコルから動的にIPアドレスが割り当てられたBBルータが、
- DDNSクライアント ツール
- DiCE DynamicDNSクライアント ツールなどが有名である。
- また、専用のHTMLフォームからゾーン ファイルを更新する機能を提供しているDDNSサービスもある。
- FTTHなどの常時接続サービスにおいて、イントラネットで用いられるDDNSの発想を受けて、DDNSサービスが普及した。
移行メモ（正誤）: 原文の「FHHTなどの常時接続サービス」は FTTH の誤記。
- Windows 2000以降のWindows OSでは、「ゾーン ファイルの動的更新」が有効になっている場合、
システム起動時のNetBIOSの名前登録に加え、
DNSサーバの「前方参照ゾーン」・「逆引き参照ゾーン」に対する名前登録も実行される。 - 「ゾーン ファイルの動的更新」は、[TCP/IP 詳細設定]ダイアログの[DNS]タブの下部の、
[この接続のアドレスをDNSに登録する] や [この接続のDNSサフィックスをDNS登録に使う]チェック ボックスで設定できる。- 前者は「プライマリDNSサフィックス」を使用してDDNSにレコードを登録する。
- 後者は「接続専用のDNSサフィックス」を使用してDDNSにレコードを登録する。
- ただし、ゾーン ファイルの動的更新は
-
「優先DNSサーバ」が、「プライマリ ネームサーバ」であり、
-
且つ動的更新をサポートする場合に限る。
-
例えば、下記の動的更新をサポートしないDNSサーバを
- 動的更新を無効にした「プライマリ ネームサーバ」
- 「セカンダリ ネームサーバ」
- 「フルサービス リゾルバ」（キャッシュ サーバ）
- 「スレーブ サーバ」
「優先DNSサーバ」に設定した場合、
-
DNSクライアントの「ゾーン ファイルの動的更新」を有効にすると、
- 無駄なトラフィックを発生するだけでなく、
- サーバのログに大量のエラーが記録されることもある。
-
移行メモ: 元 Wiki には独立した「nslookupコマンド」ページへのリンクがあったが、 そのページは 3 サイトのダンプいずれにも実体が無い（リンク切れ）ため、 本節に統合した。
- 「nslookup」コマンドを使用すると、DNSクライアントの名前解決機能を手動実行できる。
その他にも、各レコードの情報を検索できる。
C:\>nslookup
Default Server: （DNSサーバのFQDN名）
Address: （DNSサーバのIPアドレス）
>（任意のサーバのFQDN名）
Server: （DNSサーバのFQDN名）
Address: （DNSサーバのIPアドレス）
Name: （任意のサーバのFQDN名）
Address: （任意のサーバのIPアドレス）
- 「nslookup」の「ls」コマンドを実行すれば、DNSサーバに登録してある任意のドメインの
ゾーン レコードをテキスト ファイルに出力できる。- 「ls」コマンドは、「完全ゾーン転送」と同様の動作になる。
- また、「ls」コマンドが正常に完了するには、コマンドを実行しているマシンのIPアドレスが、
ゾーン転送先として許可されている必要がある。
C:\>nslookup
Default Server: （DNSサーバのFQDN名）
Address: （DNSサーバのIPアドレス）
> ls -d （任意のドメイン名） > result.txt
[（DNSサーバのFQDN名）]
######
Received 335 records.
> exit
- NSlookup.exe の使用方法
- ＠IT > nslookup - DNSサーバに名前解決の問い合わせを行う
- Linux 系では
- 「nslookup」の代用として「dig」コマンドや「host」コマンドが採用されている。
- また、BIND9など「nslookup」の「ls」コマンドが使用できないDNSサーバもある。
移行メモ: 元 Wiki には独立した「DNSLintコマンド」ページへのリンクがあったが、 そのページは 3 サイトのダンプいずれにも実体が無い（リンク切れ）ため、 本節に統合した。
「DNSLint」というコマンド ライン診断ツールを使用して、DNSクエリを検証できる。
- 例えば、次のようなクエリ ファイル（input.txt）を用意して
DNSLint
[dns~server] （DNSサーバのFQDN名）
（サーバAのFQDN名）,a,r
（サーバBのFQDN名）,a,r
- 次のコマンドを実行すれば、DNSクエリを検証できる。
>dnslint.exe /ql input.txt /v
verifying input file...input file looks valid...
processing file...
processing DNS queries...
DNS server: （DNSサーバのIPアドレス）
===========
querying for （サーバAのFQDN名）
record type: A
query type: recursive
Query result: Match found
（サーバAのIPアドレス）
Creating report called dnslint.htm
in current directory
- 出力される、dnslint.htmには以下のような情報が記録されている。
移行メモ: DNSLint は Windows Server 2003 リソースキット時代のツールで、 現在は配布・サポートともに終了している。 同等の確認は
nslookup/Resolve-DnsName（PowerShell）/dcdiag /test:dnsで行う。
- 決定的な回答が返されるまで後続のDNSサーバーを照会するクエリ。
- DNSクライアントから問い合わせされるケースが多い。
- 非再帰クエリとも呼ばれる。
- 他のDNSサーバーに照会せずに回答を返すクエリ。
- DNSサーバーから問い合わせされるケースが多い。
DDoS攻撃（DNSアンプ攻撃）の踏み台となったり、DNSキャッシュ・ポイズニングの攻撃を受ける。
- このため、DMZのDNSは、インターネットからの再帰クエリを受け付けないように設定することが多い。
- また、キャッシュ サーバ機能を分割し、
こちらをイントラネットに引き込むケースも多い。
補足（最新化）: キャッシュ ポイズニング対策としては、 ソースポート ランダマイゼーションに加え DNSSEC（署名による完全性検証）がある。 また DNS アンプ対策には Response Rate Limiting（RRL）が使われる。
Tags: IT国際標準, Active Directory, 認証基盤, ディレクトリ サービス