ブログ投稿「ドメインの「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レコードを追加する
必要なDNSレコードは次のとおりです。
go.example.com. IN CNAME ghs.google.com.
go.ext.example.com. IN A 64.32.179.5
go-redirector.example.com IN A 64.32.179.5
最初のDNSレコード（go.example.com）は、手順1の一部として既に存在している必要があります。
2番目のDNSレコードが（。行く内線 .example.comと）でA設定している新しいWebサーバのIPアドレスの記録指します。
3番目のDNSレコード（go-redirector）は、デバッグ時に役立ちます。
ステップ5：Webサーバーを構成する
Webサーバーにリダイレクトを追加します。（これは、Webサーバーが既にインストールされ、実行されていることを前提としています）。
Apache設定スニペットは次のとおりです。
<VirtualHost *:80>
ServerName go-redirector.example.com
ServerAlias go, go.ext, go.ext.example
RewriteEngine on
RewriteRule ^(.*)$ http://go.example.com$1 [R=permanent]
</VirtualHost>
これをテストする方法。 http://go-redirector.example.comこの時点で動作するはずです。
このテストが機能するまで続行しないでください。赤ちゃんのステップ。
ステップ6：クライアントのDNS検索パスを構成する
DNS検索パスに「ext.example.com」が含まれるように、マシン（Webブラウザーを実行しているもの）を構成します。
DHCPサーバーとVPNサーバーで、次のDNS検索パスを送信します。
corp.example.com。
（リダイレクトホストのあるサブドメイン、その後に「。」が続きます）
または、次のような検索パスを使用できます。
corp.example.com example.com。
しかし、それは私たちが行くすべてのくそなウェブページのために追加のDNSルックアップを追加しようとしています。彼らは99％の確率で失敗するので、それはウェブサーフィンを遅くするだけです。
ワークステーションおよびラップトップでは、サブドメインがDNS検索パスに含まれていることを確認する必要があります。このように、ユーザーが「go」と入力すると、ソフトウェアはドメイン内でそれを見つけます。
マシンの検索パスを設定して、検索パスを設定できるあらゆる方法でこのサブドメインを含めるようにします。
元々、DNS検索パスはDHCPを介して設定できませんでした。これは新しく追加された機能であり、すべてのDHCPクライアントがサポートするわけではありません。それをサポートするDHCPクライアントでさえも、ラップトップが（たとえば）インターネットカフェにいるとき、あなたが制御できないDHCPサーバーと通信しているため、修正する必要があります。ラップトップがVPNを使用する場合、VPNクライアントソフトウェアは実際にDHCPを使用しませんが、VPNサーバーが通常DHCPサーバーから取得する設定を送信する方法がいくつかあります。
したがって、これらすべての場所でDNS検索パスを設定する必要があります。
- DHCPサーバーはDNS検索パスオプションを送信する必要があります
- 静的に構成されたマシンには、DNS検索パスが設定されている必要があります
corp.example.comDHCPサーバーを使用していない場合、DHCP を使用するクライアントは、ドメインを検索パスの前に追加するように構成する必要があります。
以下は、さまざまなDHCPサーバーとオペレーティングシステムでこれを行う方法の手順です。
DNS検索パスを含めるためのDHCPサーバーの構成：
- Windows DHCPの手順
TODO
- ISC DHCPの手順
検索パスがマシンのあるべきドメインだけである場合：
option domain-name "corp.example.com";
クライアントが検索パスを提供するためにRFC 3397をサポートしている場合、これを行うことができますが、DNSホストのシーケンスであるデータタイプのネイティブサポートがないため、厄介です。レコードの配列として定義されたオプションの値を書き込む方法はありません。レコードには別のレコードの配列が含まれているため、データ文字列を使用して手動でエンコードすることになります。
option dns-search-domains code 119 = string;
option dns-search-domains concat(
encode-int(4,1), "corp", encode-int(7,1), "example", encode-int(3,1), "com", encode-int(0,1),
encode-int(7,1), "example", encode-int(3,1), "com", encode-int(0,1)
);
（未テスト）2アイテムの検索リストを生成する必要があります。
- dnsmasq DHCPの手順
TODO
静的に構成されたマシンの構成：
- ウィンドウズ
TODO
- Linux / Unix
編集/etc/resolv.confと確認（1）「ドメインcorp.example.com」最初の行がある、（2）追加/編集「検索」の行が含まれるようにしますcorp.example.com追加のドメイン、（3）「オプションndotes：2」の行にDNSサーバーの負荷を減らします。
domain corp.example.com
search corp.example.com exmaple.com
options ndots:2
他のDHCPサーバー上で動作するようにDHCPクライアントを構成する
Windows、LinuxなどのTODO入力
ステップ7：テスト、テスト、テスト！
これで、ユーザーは次を指定できるようになります。
http：// go / foo http：//go.example/foo http://go.example.com/foo
実際、信頼性テストとして、すべての状況でこれらのURLをテストする必要があります。
( each OS you support ) * ( internal LAN / at an Internet cafe / while on the VPN )
ステップ8：その他のアドバイス
最後に、ちょっとしたアドバイス：完璧な仕事をしたとしてもhttp://go/foo、DNS検索を強制するように構成していないコンピューターでユーザーがリンクを入力しようとすると、リンクが機能しないリスクがありますドメインを含めるパス。したがって、完全なURLを使用してリンクを公開する必要がありますhttp://go.example.com/foo。そして、あなたの会社のPR部門や他の人々を教育して、常にそのように指定するように時間をかけてください。
または、少なくともリンクテキストに「go」が表示されるようにHTMLでエンコードしますが、実際のHREFはFQDNに送られます。
<a href="http://go.example.com/lunch">go/lunch</a>
これを行うようにPR部門の人々に教えることは難しいかもしれません。go.example.com短い "go / lunch"は偶然にしか機能しないため、作成するものに長いバージョン（）を使用する必要があることを伝えたい場合があります。
ステップ8：HTTPS
TODO：HTTPSの使用方法を検討します（認証は、不可能ではないにしても、非常に難しくなります）。