完全解剖「名前とアドレス」 第5回

複雑な関係を解きほぐして理解しよう

Windowsネットワークの名前と番号

Windows 2000以降の名前解決方法

　Windowsネットワークの初期の頃は、ファイルやプリンタの共有などNetBIOSをベースとしたアプリケーションがほとんどだった。しかし、インターネットの普及にともない、アプリケーションもUNIXのソケットを使ったものが増えてきた。たとえば、Webブラウザやインターネットメールはソケットアプリケーションの代表例だ。ソケットアプリケーションはNetBIOS名ではなく、ホスト名を使う。前述の通り、Windows NTではNetBIOS名の解決に失敗すれば、ホスト名解決に自動的に移行するし、ホスト名解決に失敗すればNetBIOS名解決を行なう。したがって、正常に動作している限りはソケットアプリケーションが増えても特に困ることはない。

　しかし、ホスト名とNetBIOS名の自動切り替えという仕組みは、トラブルシューティングが困難である。それはトラブルの要因を切り分ける要素が多すぎるためだ。そこでWindows2000では、自動切り替えの機能は残しつつ、NetBIOSを徐々に廃止する方向に舵を切った。その結果、Windows 2000以降はNetBIOSの機能を停止してもシステムの動作には支障がないように設計されている。ここではWindows 2000以降、つまり現在の名前解決について解説する。

NetBIOSとソケットアプリケーション

　NetBIOSは、RFC1001/1002などで標準化されているものの、事実上はマイクロソフト固有のプログラムインターフェイスである。一般的なTCP/IPアプリケーションはNetBIOSではなくソケットインターフェイスを使う。

　TCP/IPソケットでは、アプリケーションが通信相手のホスト名からIPアドレスを調べる必要がある。ソケットにはホスト名ではなくIPアドレスを指定しなければならないからだ。逆にいうと、もし間違ったホスト名が登録されていても、IPアドレスさえ正しければ正常な通信ができる。ホスト名からIPアドレスへの変換は、アプリケーション内部に組み込まれるライブラリを使用する。このライブラリを「リゾルバ」と呼ぶ。

　ソケットアプリケーション（正確にはリゾルバ）の名前解決順序は図5の通りである。Windows NT 4.0からは、ホスト名の解決に失敗した場合は、NetBIOS名としての検索も行なうようになった。Windowsにはhostsファイルを使った名前解決の機能があるが、LMHOSTSファイルと同様にあまり使われない。hostsファイルの不正な書き換えは「インターネット上のホストのなりすまし」という、きわめて重大なセキュリティリスクがあるため注意してほしい。最近のウイルス対策ソフトはhostsファイルの書き換えを検出する機能を持つものもあるようだ。また、Windows Vistaではhostsファイルの修正は「UAC（ユーザーアカウント制御）」の対象であり、無断で書き換えられてしまうことはない。

図5　ホスト名の検索順序

ワークグループの名前解決

　ワークグループ環境では、ISPが提供するDNSサーバをブロードバンドルータ経由で使うなど、管理者が構成を変更できるDNSサーバを持たないことが多い。その結果、必然的にNetBIOSによる名前解決が中心となる。ただし、NBTのブロードキャスト機能は、IPv6では実装されないため、代替手段が必要となる。詳しくは、後述するLLMNRを参照してほしい。

Windows NTドメイン環境

　Windows 2000以降を使っていても、Windows NTドメインと互換性を保つため、NetBIOS名が生成される。たとえば、Windows NTのドメインコントローラ（認証サーバ）には「ドメイン名+0x1C」のNetBIOS名が割り当てられる（ドメイン名が15文字に満たない場合はスペース（0x20）で埋める）。またWindows NTのPDC（プライマリドメインコントローラ）には「ドメイン名+0x1B」のNetBIOS名が追加される。参考のため、おもなNetBIOS名の一覧を表2に示す。

表2　おもなNetBIOS名

Active Directory環境

　Active Directory環境では、NetBIOS名は原則として使わず、DNSドメイン名とホスト名を使う。DNSが使えない場合に限って、NetBIOS名を使うこともあるが、その場合はグループポリシーなど、Active Directoryの機能の一部が使えない。

　Active Directoryでは、ドメインコントローラの検索にDNSを使う。ただし、従来のAレコード（ホスト名）では役割の区別や負荷分散の効果的な実現ができない。そこで、SRV（SeRVice）レコードが採用された。SRVレコードは、MXレコード（メールサーバの発見に利用）を汎用化したもので、表3のフォーマットを持つ。表3の「重さ」は、ゼロの場合は交互に選択し、重さがある場合は比例配分した確率で選択する。たとえば、ホストAの重さが100、ホストBの重さが300の場合、ホストAの選択確率は、

100÷(100+300)=25％
となる。

表3　SRVレコードのフォーマット

　SRVは、DNSレコードの中でもかなり複雑なフォーマットだが、これをさらに複雑にする要因がある。それはActive Directoryのサイト選択機能だ。Active Directoryでは、最寄りのドメインコントローラを認識するために「サイト」という情報を使う。サイト情報はActive Directoryデータベースで管理される。しかしドメインコントローラの発見はDNSを使うため、Active Directoryはドメインコントローラの情報をサイト情報とともにDNSに登録する。

　さらに、Active Directory固有のレコードが含まれていることを示すために_msdcsというサブドメイン（ゾーン）も構成される。各ゾーンには、情報参照のためのLDAPサーバ、認証のためのKerberosサーバ、パスワード変更サーバなどがある。いずれもドメインコントローラを示すが、役割が違うため複数のレコードを必要とする。このような種々の約束事の結果から、Active Directoryで利用するDNSは非常に複雑になってしまった。手作業で構成するのは現実的ではないので、DNS動的更新を使うのが一般的だ。

（次ページ、「Vista/2008の新たな名前解決」に続く）