インターネットとLAN上におけるDNSとドメインコントローラーの考え方

インターネット上のドメインは、DNSサーバー上にプロバイダのルーターのIPアドレスを人間が理解しやすい文字列にマッピングさせたものであり、LANの中でドメインの場合は、ドメインコントローラー上にサーバーのIPアドレスをユーザーとPCの大枠の管理単位でマッピングしたものです。

既存のメールサーバーをGoogleに移すということはメールボックスの保存先を移すということであり、ドメインのあるレンタルサーバーのルートディレクトリにGoogle指定のファイルをアップロードすることでGoogleにドメインの所有を確認してもらい、DNSサーバーのMXレコードのあて先をレンタルサーバーのIPからGoogleのIPに変更します。

WEBホスティングサーバー自体を移す場合は、DNSサーバーのAレコード（ドメインのIPアドレス）を変更します。

インターネット上のドメイン

ドメインはユーザーとPCの管理単位であり、ドメインの下のローカル環境がインターネット上にあったりLAN（WAN）上にあったりするわけで、ネットワーク上のIPアドレスとドメインとのマッピングを行なうのがインターネットの場合がDNSであり、LANの場合がドメインコントローラーです。

WEBサイトを開設するためにプロバイダと契約するということは、ドメイン取得を代行（URLを打ち込むとプロバイダのルータのIPに飛ぶ）してもらい、サーバースペースも貸してもらってメールBOXも置かせてもらえるということです。

このサイトのドメイン名bahtera.jpはロリポップのサーバースペースを借りて、ムームードメインでドメインを管理してもらっており（2018年にXServerへ移転）、ドメイン名はDNS（ドメインネームサーバー）にIPアドレスとマッピングされて管理されています。

もっとも個人でIPアドレスを取得するのは手間がかかるので、プロバイダのルーターのIPアドレスでマッピングされ、ドメインごとにはプロバイダーのローカルIPで管理されています。

要はブラウザでbahtera.jpと打ち込めば、DNSのIPアドレスを元にロリポップの所定のサーバーに繋がるルーターまで到達し、それ以降はロリポップ側でよろしくやってくれるということです。

インターネットの世界で最終的にキーになるのはIPアドレスなので、ドメイン名なしでもIPアドレスをとればPINGも通るし、ブラウザからIPアドレスを打ち込むことでサイトにアクセスもできます。

ローカルLAN上のメンバーサーバー

社内ドキュメントの一元管理をしよう、ということでファイルサーバーを導入する際に具体的にやりたいことは、サーバーをLANに繋いで部門ごとのフォルダを作成し、部門のメンバーごとにアクセス制限をしたいということがほとんどです。

この場合にサーバーはワークグループの中のメンバーサーバーとして設定し、メンバーサーバーとしてユーザーの一元管理のためには、コントロールパネルの管理ツールから、ユーザーやグループの設定をすることになります。

ただネットワークコンピュータの中に見えない（インターネット上でドメインを取得していないとドメイン名でアクセスできないのと同じ）ので、IPアドレスをコマンドラインから打ち込む、またはネットワークパス「\\server1\xxx\yyy」を打ち込むことによってユーザーIDとパスワードが聞かれ（朝一のみ）ログインすることによってアクセスできるようになります。

各クライアントPCにサーバー上の所定のフォルダへのマッピングを設定し、ショートカットをデスクトップに置いておけばIDとパスワード入力でアクセスできるようになります。

ローカルLAN上のドメインネームサーバー

1フロアの中の部門LANだけならこれで十分ですが、更に上の部署、支店、地域等を結んだ全社的な大規模ネットワークを構築する際には、ドメイン（ユーザーとPCの管理単位）という概念を導入し、アクティブディレクトリを設定することによってドメインサーバーとしての機能を実装します。

つまりアクティブディレクトリを設定するにあたって必ずドメインコントローラーにhogehoge.comみたいに会社名（部署・支店・地域）に.comをつけたドメイン名をサーバーのIPアドレスとマッピングさせる必要があります。

インターネット上のドメインは、DNSサーバー上にプロバイダのルーターのIPアドレスを人間が理解しやすい文字列にマッピングさせたものといった理解が簡単ですが、ローカルLANの中でドメインの場合は、ドメインコントローラー上にサーバーのIPアドレスをユーザーとPCの大枠の管理単位でマッピングさせるというほうが理解しやすいはずです。

アクティブディレクトリを利用すれば、ドメインや資源に階層構造を設けて管理することができるため、ネットワークの規模が大きくなっても容易に管理することができます。

1台目をプライマリドメイン、2台目をセカンダリドメインに設定しておけば、プライマリドメインがクラッシュした際にもセカンダリドメインにシンクロされ保存されているディレクトリ情報により、引き続きドメインのユーザー認証が可能なので、LANの継続運転が可能です。

クライアントPCをドメインメンバーに登録（Join Domain）

クライアントPCをワークグループではなくドメインメンバーにすると、これまでのクライアントPC上でのWindowsログインからサーバーのドメインコントローラーによるユーザー管理に移行されるので、LAN上へのアクセスコントロールという観点からセキュリティレベルが格段に上がります。

PC起動時にドメインにログインすると、以降はドメイン内の資源へのアクセスで再ログインの必要はなくなり、ドメインコントローラーが認証代行してくれます。

ネットワークコンピュータから、他のドメインメンバーと共に見えるようになるので、アクティブディレクトリで権限さえ設定されていれば、ドメイン上の資源にユーザー名とパスワードなしに視覚的にアクセスできます。

ちなみにWindows XP Home EditionやWindows7 Home PremiumがインストールされたPCをドメインネットワークに登録することはできません。

しかし、これはドメインネットワーク上のネットワーク資源を利用できない、という意味ではなく、あくまでドメインコントローラのディレクトリにコンピュータを登録できないだけです。

ユーザー名とパスワード、そしてドメイン名を正確に入力すれば、ネットワーク資源にアクセスすることはでき、パスワードを保存することも可能なので、使い勝手はほとんど変わりません。

クライアントPCのメンバー設定は「システムのプロパティ」の「コンピュータ名」からドメインを選択して再起動すると、プロファイルがサーバーからクライアントにダウンロードされます。

ドメインからワークグループに戻すのは簡単にでき、変更後ネットワークへのアクセス時ドメイン名は聞かれなくなります。

ドメイン取得と管理の代行契約

インドネシアのホスティング会社でレンタルサーバー契約して独自ドメインを取得（ドメイン取得と管理の代行契約）した場合、自動的に独自ドメインのメールアドレスが使えるようになります。

メールボックスはレンタルサーバー内に保存されるので、レンタルサーバー契約を打ち切れば当然メールも使えなくなります。

具体的にはまずホスティング会社のルーターのIPアドレスとドメイン名のリンク情報を上位のDNSサーバーに登録してくれます。

次にホスティング会社のDNSサーバーにAレコード（ドメインのアドレス）、CNAMEレコード（サブドメイン作成に使用）、MXレコード（メール配信先サーバーアドレス）などを登録してくれます。

このMXレコードにレンタルサーバーのIPアドレスを指定することによって「あなたの独自ドメイン宛のメールはレンタルサーバーのIPアドレスのメールボックスに送られますよ」ということになります。

なんらかの理由でドメインの移管（転入）を行なう場合、まず移管先のプロバイダと契約したら旧プロバイダからEPP key （AuthCode）を発行してもらい、これをもってDNS登録を行なってもらいます。

Google APPS（Gmail）にメールサーバーを移す方法

既存のメールサーバーをGoogleに移すということはメールボックスの保存先を移すということであり、ドメイン契約はそのまま既存レンタルサーバー会社にお願いしてメールボックスのみGoogleに移すということは可能です。

Googleへのドメインの所有者証明

まずGoogleのサイトに「独自ドメインの所有者は本当に私ですよ」という証明をしてあげる必要があり、簡単な方法はレンタルサーバーのルートディレクトリにGoogle指定のファイルをアップロードしてGoogleに確認してもらうことです。

FTPでファイルをアップできるのはそのドメインの所有者だけですから。

つまりこの方法ではDNSサーバーのAレコードで指定されているレンタルサーバーにアクセスする権限が必要で、要はレンタルサーバーは先に解約してはマズイということです。

別の方法としてDNSサーバーのCNAME(Canonical NAME＝エイリアス)にGoogleの設定をするというのがあるが、これが何故かなかなかうまくいかないんですよね。

DNSサーバーのMXレコードの宛先をGoogleに変更（旧ドメイン管理画面から）

Googleに独自ドメインの本人確認が認証されれば、次はDNSサーバーのMXレコードのあて先をGoogleに変更します。本人確認されるまで半日くらいかかるので、その間にメールアカウントの設定を済ませておきます。

過去メールをIMAPでGoogleにアップロード

Outlookなどのローカルメーラーに溜まっている過去メールをIMAPでGoogleにアップロード 回線速度が遅い環境で端末台数が多い場合、地獄のような作業になります。

クライアントのメーラーの設定

ポートの設定がOutlook Express, MS Outlook等メーラーごとに違うので、出来ればブラウザでGmailにアクセスしてもらいます。

3通りのマルチサイト構築方法

WordPressにはマルチサイト管理機能という1つのコントロールパネルから複数の子サイトを管理できる機能がありますが、現在マルチサイト管理機能は使わず、サブディレクトリに独立したWordPressをインストールして運用しています。

複数のジャンルのサイトをWordPress上で何らかの区分けをした上で運用するには、サブドメイン化するか、サブディレクトリ化するか、別ドメイン化するかの3通り考えられます。

それぞれのメリットとデメリットを理解しておかないと、後からマルチサイト化したものを分離したり、サブディレクトリ化したものをマルチサイト化したりするのは大変です。

まず以下の2つの話は全く別問題であることを認識しておかないと後々混乱します。

ホスト名・サブドメイン・ドメインの関係

当サイトのドメインは2011年に日本とインドネシアの友好関係の持続的発展を願って付けたものです（現在はbahtera.jpに移行）。

ロリポップへの依頼の仕方はこうですが、この自分が欲しいドメインは正確に書くと以下のようになります。

これを受けたロリポップはざっくり3つの作業をしてくれます。

一旦ドメインを取得してしまえば、「ロリポップのDNSサーバーにサブドメインを設定し、取得したサーバースペースのディレクトリとマッピングする」という作業がコントロールパネルから簡単にできるようになります。

昔からの慣習としてドメイン名の頭にwww（World Wide Web）がついていることが多いので、wwwというサブドメインを設定し、ルートディレクトリにマッピングします。

ロリポップのコントロールパネルではwwwをサブドメインとして設定するようになっていますが、本来はwwwはホスト名としてWEBサーバーに設定されます。

このサイトは、システム導入に関する内容はメインドメインのWordPressで、システムに直接関係しない内容はサブディレクトリ「blog」配下のWordPressに投稿しています。

つまり「blog」というサブディレクトリに独立したWordPressをインストールし、サブディレクトリに別ドメインを割り当てることなく、ディレクトリ名付きのままアクセスさせることにより、1つのドメインの中で別ジャンルの記事を分けて管理しながら一体感を保ちます。

余談ですが、ホスト名wwwをサブディレクトリとして設定してしまうと、独自SSLがwww付きのURLで機能しないという問題が発生します。

WordPressのマルチサイト機能

ではマルチサイト機能って何？という話ですが、マルチサイト管理設定を行う最大のメリットはやはりWordPressは1つだけで、配下に子サイトを作成（コントロールパネルは1つ）なので管理が楽ということだと思います。

マルチサイト機能の具体的設定の流れとしてはwp-config.phpにマルチサイト有効化の記述を追加します。

/** マルチサイト機能 */
define('WP_ALLOW_MULTISITE', true);
// 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。

するとコンパネのツールの中に「ネットワークの設置」というメニューが追加されます。

プラグインを全部一旦停止してからネットワークを作成します。

そして子サイトの作成を行う、という流れになりますが、その後の詳細は主旨とは外れるので省略。

サブドメインとサブディレクトリ

「サブドメインとサブディレクトリはどっちがSEO上効果的か？」というのはお約束のテーマですが、サイトを訪問してくるユーザー目線で考えた場合、サブディレクトリのほうがいいと考えます。

そしてもし全く異なるジャンルのサイトを立ち上げるのであれば、完全に別ドメインで分けるべきだと思います。

サイト運営者がサブドメインまたはサブディレクトリにするというのは、別ドメインにするほどではないが色違いを出したいという意図があると思います。

重要なのは、URLのディレクトリ構造が視覚的に変わることで、訪問者に負担がかかることを理解した上で、判断すべきということです。