Hosts

前回の記事で見たように、Hyper-VクラスタのCSVに配置した仮想マシンはHA構成にするしか(サポートされる)選択肢がありません。 - [Hyper-Vクラスタの高可用性のオンオフと仮想ディスクの配置先の話。(高可用性にしないとCSVにディスクを配置できない) | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2013/06/12/hyper-v%e3%82%af%e3%83%a9%e3%82%b9%e3%82%bf%e3%81%ae%e9%ab%98%e5%8f%af%e7%94%a8%e6%80%a7%e3%81%ae%e3%82%aa%e3%83%b3%e3%82%aa%e3%83%95%e3%81%a8%e4%bb%ae%e6%83%b3%e3%83%87%e3%82%a3%e3%82%b9%e3%82%af/) きちんとCSVで共有するディスク領域と、個別のノードに配置するためのディスク領域を計算し、割り当ててあげればよいわけですが、個別に割り当てる…という話になるとどうしても容量に偏りが出たり、構成が複雑になったりなど少々気乗りしない感じです。全部HAにして良いのであればこういう苦労はしなくていいわけで、そういう構成が現実的に取れるのかどうか確認してみます。 まず、気になるのは製品自体でクラスタ構成を組むようなものです。 Hyper-VのHAとExchange Server 2010以降のDAGの組み合わせはExchange Server 2010 SP1以降ではサポートされるとのこと。 - [http://technet.microsoft.com/ja-jp/magazine/hh273004.aspx](http://technet.microsoft.com/ja-jp/magazine/hh273004.aspx) Exchange Server 2013もOKです。 Exchange サーバーの仮想マシン (データベース可用性グループつまり DAG の一部となっている Exchange メールボックス仮想マシンなど) は、移動されたりオフラインになったりしたときにディスクの状態を保存または復元しないように仮想マシンが構成されている限り、ホストベースのフェールオーバー クラスター化および移行テクノロジと組み合わせることが可能です。ハイパーバイザー レベルで発生するフェールオーバー動作はすべて、フェールオーバー先のノードで仮想マシンがアクティブになったときに、コールド ブートする必要があります。計画されたすべての移行は、シャットダウンしてコールド ブートするか、Hyper-V ライブ移行のような技術を利用したオンライン移行になる必要があります。仮想マシンのハイパーバイザー移行はハイパーバイザー ベンダーがサポートするため、ハイパーバイザー ベンダーが Exchange 仮想マシンの移行をテストしており、サポートすることを確認する必要があります。Microsoft は、これらの仮想マシンの Hyper-V ライブ移行をサポートしています。 Exchange 2013 の仮想化: Exchange 2013 Help http://technet.microsoft.com/ja-jp/library/jj619301(v=exchg.150).aspx その他は、できるけれどもやる必要ある？やらないほうが良くない？という情報が見つかります。 - Hyper-V2.0のホストクラスタとゲストクラスタの共存は可能でしょうか [http://social.technet.microsoft.com/Forums/ja-JP/hypervja/thread/907fedb7-c11e-49a2-bdbe-80d105c2b441/](http://social.technet.microsoft.com/Forums/ja-JP/hypervja/thread/907fedb7-c11e-49a2-bdbe-80d105c2b441/) 今回改めて調べるまでは私も上記のような認識だったのですが、そこよりはサポートする方向に年月がたって傾いてきている印象です。 NLBはどうでしょうか？…と思って結構頑張って調べたのですが、ズバリ言及している情報を見つけることができませんでした。私は30分ほど検索して見つからない場合には「無い」ものとして扱うことにしており、それ以上探すことはしません。Googleさんのインデックス能力はそれだけ高いと思っています。 一応以下の記事では高可用性のVMにNBLを追加で構成することのメリットに言及しているので、「あり」ということのように受け取れます。 NLB の機能によってフェールオーバー クラスターのノードになっている VM では、VM のメンテナンス中でもワークロードで高可用性が実現されます。VM で更新やなんらかのメンテナンスが必要な場合は、その VM のワークロードを同じホストの別の VM に転送したり、すべてを別のホストに転送したりすることができます。 仮想化: Hyper-V と高可用性 http://technet.microsoft.com/ja-jp/magazine/hh127064.aspx 動作しない理由も特にないので、普通に動作するものと思われます。テストして確認してみようと思います。 ...

今回はマルチホーム構成時の注意点についてです。マルチホームというのは要するにNICが2つ以上あって、複数のネットワークに足を出している状態のことです。結構な頻度でマルチホーム構成を選択し、やってはいけない構成でトラブルに遭遇するケースを見ています。しっかり抑えておきましょう。 デフォルトゲートウェイは1つだけ まず、一番初めに理解してほしいのは「デフォルトゲートウェイを2つ以上設定してはいけない」ということです。よく理解していない人は多くのケースで2つNICがあったら2つゲートウェイを設定してしまうようです。 でも、ちょっとよく考えてみてください。デフォルトゲートウェイというのは、自分が所属していないネットワークに向かって通信するときにパケットを投げる相手ですよね?それが2つ設定されていたら、どっちに投げたらいいんでしょう?困ってしまいますよね? どっちに投げてもきちんと相手まで届く構成であれば問題がおきないこともあるでしょうけれども、やはりこれはよくない構成です。場合によっては通信できないことになるでしょう。 - デフォルトゲートウェイは1つだけ設定する(1つのNICだけで入力し、ほかのNICでは空白にしておく) - 必要な経路に関してはスタティックルートを記述する このようにしておかなくてはいけません。 スタティックルートを記述 スタティックルートの記述･･･といってピンとこない方も多いかもしれませんね。基本的にNICが1つであれば必要ない設定ですから。でも2つ以上になったら、「このネットワークアドレスに向けての通信は、こっちの足からあのルーターに投げる」ということをしっかりと記述してあげる必要があります。 Windowsではこの設定は「route」コマンドで実施できます。経路の追加はroute addコマンドです。コマンドの説明は例のごとく@ITにお願いしちゃいます。 - [route - ルーティングテーブルの表示／設定を行う](http://www.atmarkit.co.jp/fnetwork/netcom/route/route.html) 注意点としては、再起動しても消えないように設定するには-pオプションをつける必要があることです。route printコマンドで経路情報を表示した際に、きちんと追加した経路が「Persistent Routes」として表示されることを確認しておきましょう。そうでないと、うまくいったと思っていたら1月くらいたって再起動したらまたおかしくなったなんていうことになってしまいます。 DNSを2つ以上設定しない またデフォルトゲートウェイの次に気をつけてたいのはDNSの設定です。特にInternet側とIntranet側なんていうようにNICが分かれていた場合、Internet側のNICにはインターネットの名前解決ができるDNSを、Intranet側のNICには社内のDNSを設定したくなる人も多いかと思います。 でも、よく考えてみてほしいのですが、両方に問い合わせるわけにはいきませんよね。もしも両方のDNSに同じドメインが存在したりしていたうえに異なるレコードが登録されているような場合には(これはありえないことではありません)、通信しようとするたびに名前解決の結果が異なるようなことにもなってしまいます。これはやはりだめです。 DNSに関してはどれが正解ということはないです。そのホストの必要に応じて、正しいDNSを参照させる必要があります。「両方のDNSを参照したい」と思ってしまうのなら、それはDNSの設計、構成が間違っている可能性があります。場合によってはhostsファイルを併用してもいいでしょう。 DNSへの登録に気をつける マルチホームの場合にはDNSへの登録にも気をつけてください。特に何も考えないと、ホストについている2つ以上のIPアドレスをすべて登録して、ラウンドロビンになってしまいます。特にDCでこれをやってしまうとかなりクリティカルな障害にもつながってしまいますので、特に気をつけてください。 DCに関してはマルチホーム時のマスタブラウザの問題もあるのでそもそもマルチホームにしないほうが良いです。でも、それでもどうしてもDCをマルチホームにしたいのであれば、Aレコードの自動登録をやめさせる必要があります。DCはNetlogonサービスが定期的に自身のDCとして動作するためのレコードをDNSに定期的に登録に行くようになっているからです。このあたりの手順は以下のKBを参考にしてください。 - [Active Directory communication fails on multihomed domain controllers](http://support.microsoft.com/?scid=kb%3Ben-us%3B272294&x=7&y=17) その他まだまだありますが･･･ 今回紹介したこと意外にもマルチホーム構成の時の注意点は色々あります。特にDMZとLANに足をだしていて、DMZ側のIPでサービスを提供しているようなときに、入力と出力で使うNICが異なるようになってしまったりとか･･･。2つ経路があるときに意図的に片方のネットワークを使わせようと思ってもうまくいかなかったりとか･･･。バックアップ専用のネットワークを作ろうとしたりするときとか･･･。 このあたりはちょっと複雑になりすぎるので、また機会を改めて解説させてもらおうと思います。とりあえず今回紹介した注意事項が基本中の基本ですので、まずはここから気をつけていってみていただければと思います。 参考URL - [マルチホーム コンピュータのデフォルト ゲートウェイ設定](http://support.microsoft.com/kb/157025/ja) - [[NT]同一ネットワークに複数のアダプタを接続した場合の障害](http://support.microsoft.com/kb/175767/) - [マルチホーム化されたブラウザに関する問題](http://support.microsoft.com/kb/191611/ja)

今回は「インターネット」ではなくて、「イントラネット」に繋がらないというケースについて書いてみます。 今、Active Directoryで構成されたWindowsネットワーク(ドメイン名sample.lcoal)があるとして、そこにintraという名前のメンバサーバーがあり、そこでイントラサイトが稼働しているとしましょう。このときのURLは何になるでしょうか? - http://intra/ - http://intra.sample.local/ さて、どちらが正解でしょうか? 正解は、「どちらも正解」です。 「なんだ、それは」と思うかもしれませんが、これがなかなか奥深い話もあったりします。たとえば1のhttp://intra/というアドレスを使っている場合。クライアントの設定によってはつながったりつながらなかったりします。繋がる場合でも、名前解決の方法が異なったりします。ちょっと詳しく見てみましょう。 名前解決の手段は何か? まず、http://intra/というURLですが、実際にはintraというホストのIPアドレスを知らなくてはいけません。最終的にはTCP/IPで接続するわけですから。 名前解決の手段としては様々なものがある、という話は以前しました。 - 参考：[NETBIOS名とホスト名の違い](https://windowsadmin.ebisuda.net/2009/02/10/netbios%e5%90%8d%e3%81%a8%e3%83%9b%e3%82%b9%e3%83%88%e5%90%8d%e3%81%ae%e9%81%95%e3%81%84/) この場合intraを名前解決する方法は以下のパターンがあるわけです。 - hostsファイル(ホスト名) - DNS(ホスト名) - lmhostsファイル(NETBIOS名) - WINS(NETBIOS名) - ブロードキャスト(NETBIOS名) で、厄介なのが2に関してです。 ドメインサフィックス DNSとして考えたときに「intra.」なんていうホスト名はあり得ないわけです。本来は「intra.sample.local」です。なので「intra」を裏で「intra.sample.local」に変更してくれている仕組みが存在するわけです。 マイネットワーク→プロパティ→(対象NIC)→プロパティ→インターネットプロトコル(TCP/IP)→プロパティ→詳細設定→DNSタブ (なんてわかりづらい所にあるんでしょう…) - 「プライマリおよび接続専用のDNSサフィックスを追加する」 - 「プライマリDNSサフィックスの親サフィックスを追加する」 - 「以下のDNSサフィックスを順に追加する」 - 「この接続のDNSサフィックス」 そしてもう一か所あります。 マイコンピュータ→プロパティ→コンピュータ名タブ→変更→詳細 (なんてわかりづらい所にあるんでしょう…) - 「このコンピューターのプライマリDNSサフィックス」 - 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」 これらの設定が"仕組み"になります。 勝手にドメインサフィックスが追加される理由 通常は以下のような流れで、勝手に適切なドメインサフィックスが追加されるようになっています。 - Active Directoryに参加する - 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」が既定で有効であるため、ドメイン名(sample.local)が「このコンピューターのプライマリDNSサフィックス」として設定される - DNSを使った「intra」の名前解決の際に「プライマリおよび接続専用のDNSサフィックスを追加する」および「プライマリDNSサフィックスの親サフィックスを追加する」が有効であるので「intra.」だけではなくて「intra.sample.local」も検索される うまくいかないケース ここまでの説明が理解できれば、http://intra/ではアクセスできないケースがあることが理解できるのではないかと思います。 具体的なケースを示します。まず前提として以下のケースで、 - hostsファイルに記載されていない - lmhostsファイルに記載されていない - WINSが構成されていない - 対象サーバーと同一サブネットに無い(ブロードキャストでの名前解決はできない) これらすべてに加えて、以下のどれかの条件に当てはまる時です。 ...

今回はWindows Serverをインストールしたあとで確認しておくべきことをまとめてみます。 i386フォルダの配置 i386フォルダというのはWindowsのインストールCD内にあるフォルダです。これがWindowsのインストラーの実態で、これさえあればWindowsコンポーネントの追加のときにCDを別途用意しなくてすみます。 i386フォルダを配置しておき、サーバーに対してSPを適用するときにはスリップストリームにてi386フォルダの内容も更新しておくことで、後日追加コンポーネントが必要になったときにSP適用済みのメディアがなくてあせるようなことになりません。 もちろんそれなりに容量をとりますので、別にサーバーのローカルディスクに必ず配置する必要があるわけではないですが運用形態によってはこのようなルールも便利だと思います。 ツールのインストール Support Tools マイクロソフト製のツールです。インストールCDやサービスパックなどの「\SUPPORT\TOOLS\SUPTOOLS.MSI」というファイルがSupport Toolsのインストーラーになっています。非常に便利なツールが多数入っていますので必ずインストールしておくことをお勧めします。(ツールの内容は別エントリで解説予定です。) Resource Kit Tools これもマイクロソフト製のツールです。昔は書籍にしかついていない時期もありましたが、今はWebからダウンロードできます。こちらも非常に便利なツールが多数入っていますので必ずインストールしておくことをお勧めします。(ツールの内容は別エントリで解説予定です。) 管理タスクの Windows 2000 リソース キット ツール Download details: Windows Server 2003 Resource Kit Tools adminpak こちらは必須というわけではないですが、自身のサーバーには導入されていないサービスだけれども、リモートサーバーを管理したい、と言うようなときにはadminpakを導入しておくと便利です。 インストーラーは「%windows%\system32\adminpak.msi」です。これを導入すると、管理コンソールのみすべて導入されます。 各種更新作業 ドライバ更新 ドライバはインストール時に自動的に適用されているはずですが、きちんとドライバが適用されているかどうかを確認し、必要があれば更新を行うようにしましょう。 基本的にドライバのアップデートは各サーバーベンダーから出ているドライバのバージョンを一括管理できるツールを使って行いますが、きちんとデバイスマネージャーを見て、異常が無いことを確認しておきましょう。 黄色の感嘆符が出ないようにしましょう。 Service Pack, Hotfix 基本的にはWindows Server構築時には最新のService Packを適用した上でさらに全てのHotfixを適用しておくべきです。台数が少なければ個別に適用するべきものがなくなるまでMicrosoft Updateを実行すればいいでしょう。 一度Service Packを実行して、再起動したあとで再度Microsoft Updateを実行する･･･というように何度も繰り返す必要がありますので注意してください。 Microsoft UpdateはProxy接続の環境ではうまく動かないことがあります。この場合にはInternet explorerでのProxy設定だけではなく、proxycfg.exeコマンドでProxyを設定、再起動の上で再度実行するとうまくいくことがあります。 自動構成スクリプトの指定方法によって Windows Update が失敗する 上でも述べましたが、SP適用済みの環境に対して、SP的用済みではないメディアからWindowsコンポーネントを追加してしまった場合には、再度SPの再適用が必要ですので気をつけましょう。必ずスリップストリーム済みのi386フォルダからコンポーネントを追加しましょう。 イベントログの確認 インストール後には必ずイベントログの確認を行いましょう。警告、エラーが記録されている場合には、必ずそれに対して対処を行い、問題が無い状態にしましょう。 エラーの解消には以下のようなサイトが有効です。 マイクロソフト サポート オンライン EventID.Net 中には出ていても問題のないエラーなども存在しますので、それもあわせて確認しましょう。 Windows FireWall 現在のWindows ServerではWindows FireWallが自動的に有効になります。なんらかのサービスを提供するサーバーであれば必ずそのポートは開放する必要がありますので、忘れずに設定しましょう。 また、場合によってはWindows FireWallは無効に設定するポリシーのところもあるでしょう、いずれにしてもきちんと目的に合った設定にしましょう。 ...

今回は「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ネットワークだけ。 参考 - [Insider's Computer Dictionary [NetBEUI] － ＠IT](http://www.atmarkit.co.jp/icd/root/14/5787514.html) - [DNSの仕組みの基本を理解しよう](http://www.atmarkit.co.jp/fnetwork/rensai/dns01/dns01.html) - [＠IT：基礎から学ぶWindowsネットワーク](http://www.atmarkit.co.jp/fwin2k/serial/index/index.html#baswinlan)