☰

問題

tag-icon • tag-icon domain-name-system dhcp service url
問題

ブログ投稿「あなたのドメインのための「tinyurl」サービス「」では、Google Apps を使用してドメインの ShortName サービスを設定する方法について説明します。たとえば、ドメインが で、Google Apps を使用している場合は、 を企業個人の ShortName サービスとしてexample.com設定できます。http://go.example.com

注意: これは、世界中で使用できる「tinyurl」サービスを作成することではありません。これは企業向けです。

社内ページへのリンクを作成できるように、ユーザーだけが使用できる短縮名サービスがあると便利です。長くてわかりにくいURLをユーザーに伝える代わりに、「今日のランチメニューはhttp://go.example.com/ランチ「ブログ記事では、ユーザーが独自のリンクを設定できるようにすることで得られるメリットの一部について説明しています。（最も重要なのは、新しいリンクを設定するためにユーザーがあなたに迷惑をかける必要がないことです！）

問題

このシステムの問題は、URL がまだかなり長いことです。ユーザーはむしろ、ウェブブラウザに「go/lunch」と入力して、それを実行したいでしょう。残念ながら、Google Apps は、HTTP プロトコルの動作の技術的な問題により、これをサポートできません。HTTP 1.1 の「Host:」ヘッダーには、ユーザーがウェブブラウザに入力したドメインがリストされます。完全修飾ドメイン名つまり、Google Appsが「http://go/lunchgo.example.com「ウェブサーバーはホスト名として「go」を受け取ります。Google Apps は多くのドメインにこのサービスを提供しているため、ユーザーが希望するかどうかを判断できませんgo.some-other-example.com。

その結果、ユーザーは毎回「go.example.com/lunch」と入力しなければならなくなり、「go/lunch」よりもずっと長くなります。

ソリューション

Google は、Web クッキーやその他のスキームを使用してこの問題を解決できます。いずれも、特にクリーンで簡単なものではありません。Google がこれを実行するまでは、リクエストを「実行」として受け入れてリダイレクトする独自のマシンを設定することでこの問題を解決できます。

サーバーは、「go」というサイトへの HTTP リクエストを受け入れ、そのリクエストを にリダイレクトしますgo.example.com。次に、サーバーが機能するように適切な DNS レコードを作成し、ラップトップ/ワークステーションが正しく動作するように DHCP 構成を調整します。

この Server Fault ドキュメントの目的は、プロセスを説明し、サイトでこれを実行するのに役立つ構成例を提供することです。私は世界中のすべてのオペレーティング システムにアクセスしたり、それらについて知識を持っているわけではないので、これを「コミュニティ ウィキ」にして、人々が動作を確認しながら構成スニペットを入力できるようにしています。特に改善が必要な領域には「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。そのサブドメインにはmail.ext.example.com、calendar.ext.example.com、vpn.ext.example.com、 などの CNAME があります。)

警告: DNS 検索パスにさらに別の項目を追加すると、コンピュータの動作が遅くなります。毎回追加の DNS クエリを実行すると遅くなり、Web の閲覧が著しく遅くなります。このリダイレクタを、マシンの DNS 検索パスにすでに含まれているサブドメインに追加する方がはるかに適切です。このため、複数のサブドメインに CNAME を追加することになりますが、これは問題ありません。たとえば、内部マシンと VPN に接続されたマシンの検索パスにcorp.example.comすでに が含まれている場合は、そこに CNAME を追加します。VPN に接続されていない外部マシンがリダイレクタにアクセスできるようにしたい場合、それが外部からアクセスされることのないマシンのサブドメインであれば、検索パスにハードコードするのは奇妙かもしれません。その場合は、別の CNAME を外部サブドメイン ( など) に追加して、リダイレクタを指すことcorp.example.comができます。Web サーバーの構成を更新して、両方をサポートしてください。ext.example.com

この例では、リダイレクタを に選択したと仮定しますgo.ext.example.com。マシンの名前は自由に付けることができます。DNS と Web サーバーの構成はすべて私たちが行います。

ステップ3: リダイレクタの計画

セットアップする Web サーバーは、既存の Web サーバー上にあっても、この目的のために構築された新しいサーバー上にあってもかまいません。重要なのは、ShortName サービスが機能する場所、つまり社内、社外、ユーザーが VPN 経由で接続している場合など、どこからでもマシンにアクセスできる必要があることです。(セキュリティ上の理由から、これを社外から機能させないことを選択する場合もあります。また、セキュリティ上の理由から、社内に 1 台のマシン、社外にもう 1 台のマシンをセットアップすることもできます。)

注: このために新しい Web サーバーをセットアップする必要はありません。構成が存在しない限り、既存の Web サーバーにこれを追加できます。

注: これはかなり複雑になる可能性があります。最も単純なケースで動作させることに重点を置き、動作してテストしたら、他の状況でも動作させるとよいでしょう。特に、次の順序で動作させてください: 1. 社内のワークステーション/ラップトップ 2. 次に VPN で接続されたマシン、次に社外のマシン (インターネット カフェなど) 3. 次に VPN が起動していないネットワーク外のマシン 4. 次に他のオペレーティング システムでこれをテストします

この例では、社内でも社外でも同じ IP アドレスでアクセスできる Web サーバーがあると想定します。

私たちの「行く」では。企業たとえば、「.example.com」の場合、「go」は内部者のみがアクセスできるサブドメインにあり、ShortName サービスを使用するには 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 レコード (go.内線.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 。

しかし、そうすると、私たちがアクセスするすべての Web ページに対して追加の DNS ルックアップが追加されることになります。99% の確率で失敗するため、Web サーフィンが遅くなるだけです。

ワークステーションやラップトップでは、サブドメインが DNS 検索パスに含まれていることを確認する必要があります。 そうすれば、ユーザーが「go」と入力したときに、ソフトウェアがドメイン内でサブドメインを見つけます。

検索パスを設定できるあらゆる方法で、このサブドメインが含まれるようにマシンの検索パスを構成します。

もともと、DNS 検索パスは DHCP 経由で設定できませんでした。これは新しく追加された機能であり、すべての DHCP クライアントがサポートしているわけではありません。サポートしている DHCP クライアントでも変更が必要です。なぜなら、ラップトップが (たとえば) インターネット カフェにある場合、ラップトップはユーザーが制御していない DHCP サーバーと通信するからです。ラップトップが VPN を使用する場合、VPN クライアント ソフトウェアは実際には DHCP を使用しませんが、通常、VPN サーバーは DHCP サーバーから取得する設定を何らかの方法で送信します。

したがって、次のすべての場所で DNS 検索パスを設定する必要があります。

  • DHCPサーバーはDNS検索パスオプションを送信する必要があります
  • 静的に構成されたマシンではDNS検索パスを設定する必要があります
  • corp.example.comDHCP を使用するクライアントは、DHCP サーバーにドメインがまだ含まれていない場合は、検索パスの先頭にドメインを追加するように構成する必要があります。

以下に、さまざまな DHCP サーバーおよびオペレーティング システムでこれを行う方法を説明します。

DNS 検索パスを含めるように DHCP サーバーを構成する:

  1. Windows DHCP の手順

やるべきこと

  1. ISC DHCP の説明

検索パスがマシンが存在するドメインだけである場合は、次のようになります。

option domain-name "corp.example.com";

クライアントが検索パスを提供するために RFC 3397 をサポートしている場合は、これを行うことができますが、DNS のように長さプレフィックス付きのラベルとしてそれぞれエンコードされた 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 つの項目の検索リストを生成するはずです。

  1. dnsmasq DHCP の説明

やるべきこと

静的に構成されたマシンの構成:

  1. ウィンドウズ

やるべきこと

  1. Linux/Unix

編集して/etc/resolv.conf、(1)「domain corp.example.com」が最初の行であることを確認します。(2)ドメインを含めるように「search」行を追加/編集しますcorp.example.com。(3)DNSサーバーの負荷を軽減するために「options ndotes:2」行を追加します。

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: その他のアドバイス

最後に、アドバイスを 1 つ。この作業を完璧に実行したとしても、http://go/fooDNS 検索パスにドメインを含めるように設定していないコンピューターでリンクを入力しようとすると、リンクが機能しないというリスクが残ります。したがって、完全な URL を使用してリンクを公開する必要があります。http://go.example.com/fooまた、会社の PR 部門やその他の関係者に、常にそのように指定するように指導してください。

または、少なくとも HTML でエンコードして、リンク テキストに「go」が表示されるようにしますが、実際の HREF は FQDN になります。

<a href="http://go.example.com/lunch">go/lunch</a>

PR 部門の人々にこれを教えるのは難しいかもしれません。短い「go/lunch」は偶然にしか機能しないので、何を書くときも長いバージョン ( ) を使用する必要があるgo.example.comと伝えるだけでよいかもしれません。

ステップ8: HTTPS

TODO: HTTPS の使用方法を検討します (認証を正しく取得するのは、不可能ではないにしても、非常に困難になります)。

答え1

この質問は、何らかの形で「回答済み」としてマークされるべきです。このようにして、https://serverfault.com/unansweredURL は正しいままです。この質問に対する「回答」を (投稿して) 承認してください。ありがとうございます!

私の「答え」は、リンク短縮サービスの構築 (またはインストール) は非常に簡単で、上記のすべての手順を踏むのではなく、Web サーバーに「go.example.com」に応答するローカル リンク短縮サービスを設定し、DNS が search example.com に応答することを確認するだけです。そうすれば、内部 URL が世界に漏れることはありません。(おそらく、私は要点を理解していないのでしょう。)

代替案:

  • 非常に小規模な会社またはワークグループの場合は、全員にお気に入りのブックマークを尋ね、それをイントラネットのフロント ページに配置するためのスペースを確保します。

  • あるいは、小規模な会社やグループ向けのイントラネットを Wiki として展開し、共有ホットリンクの便利なリストを用意して、ユーザーが目的の場所に簡単にアクセスできるようにします。

乾杯、ダニー

関連情報