FQDNが不要になるように、ドメインにGoogle ShortNameサービスを設定する方法
ブログ投稿「ドメインの「tinyurl」サービス」では、Google Appsを使用してドメインのShortNameサービスを設定する方法について説明しています。たとえば、ドメインがexample.comあり、Google Appsを使用しているhttp://go.example.com場合、企業の個人的なShortNameサービスになるように構成できます。 注：これは、世界が使用する「tinyurl」サービスの作成に関するものではありません。これは企業向けです。 内部ページへのリンクを作成できるように、ユーザーのみが使用できるショートネームサービスがあると便利です。長く難しいURLを人々に伝えるのではなく、「今日のランチメニューはhttp://go.example.com/lunchにあります」と言うことができます。ブログの投稿には、人々が独自のリンクを設定できるようにすることの利点のいくつかが記載されています。（最も重要なのは、新しいリンクを設定するためにあなたを煩わせる必要がないことです！） 問題 システムの問題は、URLがまだかなり長いことです。人々はむしろウェブブラウザに「go / lunch」とタイプして、それを機能させたいと思うでしょう。残念ながら、HTTPプロトコルの動作方法の技術的な理由により、Google Appsはこれをサポートできません。HTTP 1.1の「Host：」ヘッダーには、ユーザーがFQDNではなくWebブラウザーに入力したドメインがリストされます。つまり、Google Appsが「http：// go / lunch」のHTTPリクエストを取得すると、ウェブサーバーは「go」をホスト名として受け取ります。Google Appsは多くのドメインにこのサービスを提供しているため、必要go.example.comかどうかを判断できませんgo.some-other-example.com。 その結果、ユーザーは毎回「go.example.com/lunch」と入力する必要があり、これは「go / lunch」よりもはるかに長くなります。 ソリューション Googleは、Web Cookieまたはその他のスキームを使用してこれを解決できます。どれも特にきれいでも簡単でもありません。それらが完了するまで、要求を「実行」として受け入れてリダイレクトする独自のマシンをセットアップすることにより、問題を解決できます。 サーバーは、「go」というサイトのHTTP要求を受け入れ、要求をにリダイレクトしgo.example.comます。次に、適切なDNSレコードを作成して機能するようにし、DHCP構成をいじってラップトップ/ワークステーションが正しく動作するようにします。 このServer Faultドキュメントのポイントは、プロセスを説明し、サイトでこれを行うのに役立つ構成例を提供することです。私は世界中のすべてのオペレーティングシステムにアクセスしたり、それらの知識を持っているわけではないので、これを「コミュニティwiki」にして、人々が動作するように構成スニペットを記入できるようにします。特に改善が必要な領域に「TODO」を配置しました。 詳細 この例では、ドメインとして「example.com」を使用します。 ステップ1：通常の方法でGoogle Appsサービスを設定します。 go.example.com通常どおりにサービスを構成します。テストして、URLがhttp://go.example.com/foo機能することを確認してください。これが完了していない場合は、続行しないでください。それはあなたが車を所有する前にあなたの車を修理しようとするようなものです。 ステップ2：リダイレクタのホスト名を選択する ショートgo.example.comネームサービスがの場合、理想的にはリダイレクタの名前を作成しますgo.example.com。悲しいことに、物理学は2つの物体が同じ場所に同時に存在することを防ぎ、DNSは物理学の法則に従います。 コツは、リダイレクタをShortNameサービスと同じホスト名にすることですが、別のドメインに配置することです。たとえば、go.corp.example.com、go.ext.google.com、またはgo.this-is-different.example.com。 大企業には通常、外部に公開されない内部サブドメインがあります。通常、内部ホストはINSIDEHOST.corp.google.comです。そこでリダイレクタを配置します。 一部の企業は、社内外からアクセスする必要があるサービスを指すCNAMEでいっぱいのサブドメインを割り当てています。この方法では、人のDNS検索パスに配置する必要がある1つのサブドメインがあります。（Unixの人々は、これ/usr/local/binをシンボリックリンクで満たされたサブディレクトリであると考えることができます）伝統的に、このサブドメインはext.example.comです。そのサブドメインでのCNAMEは次のようにしているmail.ext.example.com、calendar.ext.example.com、vpn.ext.example.com、など。） 警告：DNS検索パスにさらに別のアイテムを追加することは、コンピューターの動作を遅くするもう1つの方法です。毎回追加のDNSクエリを実行すると、時間がかかり、Webサーフィンが著しく遅くなります。複数のサブドメインにCNAMEを追加することを意味する場合でも、マシンのDNS検索パスにすでにあるサブドメインにこのリダイレクタを追加することをお勧めします。たとえば、内部マシンとVPNに接続されているマシンのcorp.example.com検索パスがすでにある場合、そこにCNAMEを追加します。VPNに接続されていない外部マシンがリダイレクタにアクセスできるようにする場合、それがcorp.example.com外部から決してアクセスされないマシンのサブドメインである場合、検索パスにハードコーディングするのは奇妙かもしれません。その場合、別のCNAMEを外部サブドメインに追加できます（たとえばext.example.com）リダイレクタを指す。Webサーバー構成を更新して、両方をサポートします。 この例では、リダイレクタがになるように選択したと仮定しますgo.ext.example.com。マシンは任意の名前で呼び出すことができます。DNSとWebサーバーの構成ですべての魔法を行います。 ステップ3：リダイレクターの計画 設定するWebサーバーは、既存のWebサーバーまたはこの目的のために構築された新しいWebサーバーに配置できます。重要なのは、ShortNameサービスを機能させたい場所であればどこからでもマシンにアクセスできる必要があるということです。ユーザーがVPN経由で接続している場合は、社内、社外を問わずです。（セキュリティ上の理由から、これを社外で行うことをやめることもできます。セキュリティ上の理由から、1台のマシンを内側に、もう1台のマシンを外側に設定することもできます。） 注：このために新しいWebサーバーをセットアップする必要はありません。構成が存在しない限り、これを既存のWebサーバーに追加できます。 注：これはかなり複雑な場合があります。最も単純なケースでこれを機能させることに焦点を合わせ、動作してテストした後、他の状況で機能させることができます。特に、次の順序で動作するようにします。1.会社内のワークステーション/ラップトップ2. VPNで接続されたマシン、次に会社外のマシン（インターネットカフェなど）。3. VPNを使用せずにネットワークの外部にあるマシンをTHENします。4.他のオペレーティングシステムでテストします この例では、社内または社外に関係なく、同じIPアドレスでアクセスできるWebサーバーがあると想定します。 私たちの「行く。ではCORP .example.comと」たとえば、この手段は「行く」インサイダーにのみアクセス可能であるサブドメインであり、かつ短縮名サービスを使用するようにVPNが必要です。Google Appsは通常、VPNなしで動作するように構成されているため（すべてのアクセスがHTTPSであるため）、これは最適ではありません。 私たちの「行く。で内線 .example.comと」たとえば、この手段サブドメインは、社内外の両方からアクセス可能であり、かつA外部IPアドレスにレコードポイント。 ステップ4：リダイレクターのDNSレコードを追加する …