翻译:
原文:
NETBIOS名とホスト名の違い
今回は「NETBIOS名」と「ホスト名」について解説します。「NETBIOS名」と「ホスト名」が混ざってしまいよく理解できていない人はかなり多いです。いざという時のトラブルシュートで差が出ますのでしっかり理解しましょう。
Windowsネットワークの歴史
NETBEUIの時代
「NETBOIS名」のことをよく理解するためにはWindowsネットワークの歴史を知らなくてはいけません。
まず、今のTCP/IP全盛の時代からすると信じられないかもしれませんが、初めてWindowsにネットワーク機能が標準搭載されたWindows95では規定のプロトコルはTCP/IPでは無くてNETBEUIというものでした。そしてNETBEUIはNETBIOSというAPIを利用しています。
NETBEUIはTCP/IPとは全く異なる考え方のプロトコルです。IPアドレスなんてありません。ルーティングもしません。名前だけ決めておけばアクセスできる。そんなプロトコルです。考え方は非常にシンプルです。
このNETBIOSのAPIを利用するために「コンピューターにつける名前」が「NETBIOS名」です。
Windows95, 98の時代にはコンピューターにコンピューター名(=NETBIOS名)だけつけておいて、あとはEthernetで接続(レイヤ1で接続)だけしておいてあげれば「\\コンピューター名」という形式で他のコンピューターにアクセスしてファイル共有やプリンタ共有を利用することができました。
「NETBEUI時代に使っていたコンピューター名」が「NETBIOS名」です。
NETBEUIの限界
NETBEUIは現在ではほぼ使われていません。なぜ使われていないのかというと以下の点で現在のネットワーク環境に合わなくなってしまったからです。
- ルーティング機能が無いため大規模なネットワークには向かない
- インターネットが普及し、NETBEUIとの相互接続性に問題がある
95, 98の時にはファイルやプリンタの共有のためにはNETBEUIプロトコルを使って、インターネット接続にはTCP/IPを使って・・・と、複数のプロトコルスタックを使うようなこともありました。今では用途別に複数のプロトコルスタックを使い分けるということはもうほぼありません。
TCP/IPへの移行
Windowsネットワークもインターネット普及の流れに乗るためにTCP/IPを標準のプロトコルに採用します。時代の流れです。ですが、単純にTCP/IPに移行してしまうと今まで使っていたNETBIEUI+NETBIOSのAPIをつかったWindowsファイル共有やプリンタ共有が使えなくなってしまいますし、Windowsネットワークの特徴であった「とりあえず名前だけ決めておけば繋がる」という利点が失われてしまいます。
そこでマイクロソフトがとったのはTCP/IPの上でNETBIOSのAPIを使えるようにする、という戦略です。これをNETBIOS over TCP/IPといいます。TCP/IP上でNETBOISを使えるようにしたわけです。これにより、NETBIOSのアプリケーションそのままに、TCP/IPを使って複数セグメントに分かれた大規模なネットワークにも対応可能になりました。
このNETBIOS over TCP/IPの機能があるため、何も設定していない状態で「ping コンピューター名」に応答が返ってくるわけです。
複数セグメントになったことで起きる問題
NETBIOS over TCP/IPによって複数セグメントに対応し、大規模なネットワークに対応できるようになりました。ですが、もともとNETBEUIは「ブロードキャスト」を多様することで簡単に接続できるようになっていたため、複数セグメントに分かれてしまうとNETBIOSのAPIがきちんとネットワーク全体で使えない、という問題が出てきてしまいます。
この問題を解決するために、セグメントを越えるために、出てきた技術がWINSです。各コンピューターがNETBIOS名とIPアドレスの対応付けをWINSサーバーに登録しておき、利用したい場合にはWINSサーバーに問い合わせることで、セグメントを越えることができるようになりました。
また、lmhostsファイルというファイルにもNETBIOS名とIPアドレスの対応付けを書くことができるようになっています。
WINSサーバーを使うかlmhostsファイルにそれぞれ記述することでセグメントを越えることが出来るようになっています。
NETBIOS名
ここまで見てきたようにNETBIOS名というのはもともとTCP/IPとは別のNETBEUIというプロトコルスタック上で使われていた名前です。WindowsがNETBEUIからTCP/IPに乗り換える際に、過去の遺産を持ってきた、そういう構造になっています。ですからはじめからプロトコルスタックにTCP/IPを採用していたUNIX系のOSではNETBIOS名という考え方は存在しません。
基本的には自分のNETBIOS名をコンピューターは知っていて、それが(ブロードキャストで)呼ばれたら変事をするような仕組みになっています。
UNIX系ネットワーク(TCP/IP)の歴史
hostsファイル
TCP/IPでは他のコンピューターと通信する際にはIPアドレスを利用します。
IPアドレスを人間が全て記憶することは難しいため、hostsファイルにIPアドレスとそれにつけるコンピューターの名前(=ホスト名)を記述し、管理していました。全てのコンピューターにhostsファイルを記述する、というのがもっとも原始的な形態です。
個別のhostsファイルにホスト名とIPアドレスの対応付けを全て記述していたのでは、ネットワークにコンピュータが1台増えただけで、既存のコンピューター上の全てのhostsファイルを更新して回る必要が発生してしまいます。同じようにIPアドレスを変更したい、ホスト名を変更したいと思った場合も同様です。
このようにhostsファイルだけでは小規模なネットワークならともかく、大規模なネットワークでは事実上管理できません。
DNS
hostsファイルの問題を解決する仕組みとして考え出されたのがDNSです。クライアントはDNSサーバーに問い合わせて、ホスト名とIPアドレスの変換を行います。
ただし、この際に単純にhostsファイルに記載されていたものをDNSサーバー上に登録しただけでは何百、何千、何万というレコードを1台のサーバーで管理しなくてはいけなくなります。DNSはインターネット上でも使われていますが、インターネット上のホストとなると何百万、何千万、何億という単位です。これを1台で全て管理したり、冗長化のために複数台にコピーしたり、というのはかなり効率が悪いです。
さらにもしかしたら全く同じ名前を持っているホストが存在しているかもしれません。この場合どちらかのレコードのみを登録するわけにもいきませんのでどちらかの名前を変更しなくてはいけなくなってしまいます。
そこでDNSには、このような問題を解決するためのしくみとして、「ドメイン」という概念が導入されています。「ドメイン」ごとにレコードを管理し、ホスト名のあとにドメイン名までつけて1つのホストを表します。たとえばこのブログが稼動しているサーバーはdyndns.bizというドメイン上のebiというホストです。ebi.dyndns.biz.というのが完全修飾ドメイン名(FQDN)になります。(※完全修飾ホスト名とは言わずに、完全修飾ドメイン名といいます。)
ちなみにWINSにはこのような「ドメイン」という考え方は存在しませんので上記の問題をそのまま抱えています。ですので、マイクロソフトもWINSには見切りをつけていて、廃止の方向に向かっています。
ホスト名
見てきたように「ホスト名」はhostsファイルおよびDNSにて管理され、ドメインという概念を含んだものです。
NETBIOS名とは異なり、自分のホスト名に対してそのIPアドレスを返答するような仕組みは備わっていません。
Active DirectoryでDNSを導入
マイクロソフトはWindows2000でActive DirectoryというWindowsネットワークを管理する新しい仕組みを導入し、その中で名前解決の仕組みにDNSを導入します。ここから本格的にWindowsネットワークでもTCP/IP+DNSという仕組みを採用したわけです。
ですが、過去の資産を継承するためにNETBIOSの仕組みも存続させます。NETBIOS over TCP/IPも搭載していますし、NETBIOS名の名前解決の仕組みとしてWINSも健在です。
このようにして、WindowsネットワークはNETBIOS名とホスト名が混在するややこしい状態になりました。
ポイント
- lmhostsファイルとhostsファイル、WINSとDNSとが技術的には対応付けられる。ただし、その技術が必要となってきた経緯は異なる。
- ホスト名はTCP/IP,Unixの文化から来ている。
- NETBIOS名はNETBEUI(プロトコルスタック)+NETBIOS(API)という過去の技術を継承しているために残っている。TCP/IPへとプロトコルスタックを変更する際にNETBIOS over TCP/IPという技術が導入され、これによりTCP/IPネットワーク上でNETBIOS(API)が利用できる。
- NETBIOS名とホスト名が混在しているのはWindowsネットワークだけ。