DNSでは SRVレコード は、特定のサービスがホストされている場所をリモートクライアントに通知するかなり一般的な形式です。現時点では、インターネット経由でSIPクライアントを使用して電話をかけることができるようにするために使用しています(非常にうまく機能します)。
SRVレコードの利点の1つは、サービスに異なるポートを指定でき、同じシステム(または同じシステムと異なるポート上の複数のインスタンス)に複数のシステムを設定できることです。したがって、[〜#〜] iff [〜#〜]は機能し、干渉なしに1つのシステム上に複数のWebサーバーを配置できます。
したがって、これをDNSに含めることができます。
_http._tcp SRV 10 50 8080 myserver.basjes.nl
_http._tcp SRV 10 50 8081 myserver.basjes.nl
ただし、このすべての長所には1つの問題があります...それをサポートするHTTP、FTP、SMTP、...クライアントを見つけることができませんでした。
したがって、SIPおよび Wikipedia ページで言及されている他のいくつかのプロトコル以外:SRVレコードは本当に役立つようになるでしょうか?
それとも私は何かを逃したことがありますか?
うまくいくものが他にありますか?
newプロトコルにのみ使用されるのがわかると思います。
SMTPが使用するMXレコードは、固定ポートで重みのないSRVレコードと同等です。言い換えれば、彼らはすでに同じ問題を適切に解決しています。
たとえば、HTTPは現在のメカニズムとの下位互換性を維持する必要があるため、HTTPにSRVを使用し始めた人は、とにかく代替メカニズムを提供する必要があり、同じことを行う2つの方法を維持する必要はありません。 (たとえば、一部のロードバランサーと一部のDNS SRVレコード...)そして、サイトがSRVレコードを公開しない場合(それが不要な作業を作成するだけであるため)、誰も公開していないSRVレコードをクライアントがサポートする動機はありません。
Active Directoryドメイン で非常に便利です。
SRVレコードは、多くのKerberos対応サービスとクライアントでも使用されています。これは、/ etc/krb5.conf(または同等のもの)が読み取れないか欠落している特定のマシンに特に当てはまります。 KDCを見つけるためにSRVレコードルックアップが実行されます。
AppleのBonjourテクノロジー(別名zeroconf)はこれを広範囲に使用します。実際に見ていない場合は、チェックしてください。これにより、プリンター、ルーター、bonjour対応のWebページなどを自動検出できます。
Mod_bonjourと呼ばれるBSDライセンスのApacheモジュールがあり、マルチキャストDNSを介してWebサイトを宣伝できます。 SRVレコードと通常のDNSを介してサイトを宣伝することもできますが、それらを検出できるのはSafariだけだと思います。
ZeroconfのWebページ それがどのように機能するかについてはかなり良い説明があります-テクノロジーに興味があるなら、この本もチェックすることをお勧めします。
これに関する一般的な大きな問題の1つは、DNSの人々が自分たちをサービス発見ビジネスに従事しているとは考えておらず、偏執的なセキュリティの人々がサービスを発見する能力をセキュリティリスクと見なしていることです。
実際、ほとんどのアプリケーションはまだそれをサポートしていません。
実行するのは、ターゲットユーザーのIDのドメインが、クライアントソフトウェアが接続する必要があるhostnameと異なることがよくあるドメインです。したがって、SIPやJabber(XMPP)でも使用される理由。
最初から常にMXレコードがあったため、SMTPはそれを必要としません。
別のポートを使用できることの利点は比較的小さいため、他のプロトコルではあまり使用されていません。
http+srv:
URIスキームを提案する インターネットドラフト がありますが、標準のhttp:
URIリクエストにSRVルックアップを追加する現在の提案はありません。
Outlook2007およびExchange2007はSRVレコードを利用します http://technet.Microsoft.com/en-us/library/bb332063.aspx
SRVレコードはDNSサービス検出(DNS-SD)の基本構造の1つであるため、ますます重要になると思います。
また、DNS-SD対応クライアントと組み合わせて、既存のテクノロジーで使用できない理由もありません。ネットワーク上のbonjour/zeroconfリソースを見つけることができるMac用iStumblerなどのネットワークブラウザ。
私の意見では、SRVレコードは、動的更新DNSがより利用可能になったときにのみ、より一般的になるでしょう。 MS-DNSでは、Active Directoryの要件により、大部分がデフォルトで動的更新がオンになっています。サービスロケーションプロトコル、サービスアドバタイジングプロトコル(IPXネットワーク)、Bonjour/Avahi、およびDHCPさえも含めて、何年にもわたって多くのリソースアドバタイジングディレクトリがありました。
これらのうち、DNSだけがインターネットにまたがるリソースディレクトリとして真の可能性を秘めています。パブリックDNSサーバーは、ある理由で静的なものになる傾向があります。 SRVレコードの採用は、SPFプロトコルでTXTレコードが採用されたのと同様に、定義されたニーズがあるときに行われます。SIP SRVの使用MS以外の幅広い採用への扉を開く最初のステップになる可能性があります。
SRVレコードは、全員が同じプロバイダーを使用することなく、通信サービスを実装するためのメカニズムを提供します。つまり、AレコードとMXレコードがWebと電子メールに対して行うことと、SRVレコードがすべてのサービスに対して行うことです。
このアイデアは、ブログの投稿「The Power of Free Addressing」で概説されています http://e-caller.com/?p=4
TwitterとFacebookの台頭は、SRV対応の代替手段がないためです。
Fedora/Red Hatプロジェクトfreeipaは、負荷分散とスケーラビリティの理由から、それらとpuppet labspuppetを使用します。ユースケースとそれらがどのように広範囲に使用されているかについて学ぶほど、それに夢中になります。それはDNSとインフラストラクチャに起こった最高のことです。 Spotifyがそれらをどのように使用するかを確認してください https://labs.spotify.com/2013/02/25/in-praise-of-boring-technology/
SRVレコードは、エンタープライズでアクティブ化するためにWindows Vista/2008サーバーをKMSサーバーに転送するために使用されます。
XMPPはそれらを使用しています。
ただし、既存のプロトコルはそれらをサポートするように変更されません。特に、要求を別のポートにリダイレクトすることはありません。それは予想外であり、間違いなくいくつかのセキュリティ関連の仮定を破ります。
DNSは最初から実装する必要がなく、zookeeperやetcdのようなものよりもはるかに軽量であるため、サービスロケーターを必要とするアプリケーションスタックに非常に役立ちます。また、非常に安全にすることができるという追加された利便性もあります。 Spotify以外の誰もがこのようにそれを使用することがほとんどない理由はわかりません、私はただ無知だと思います。私は多くの人々が彼ら自身の非常に劣ったカスタムサービスロケーションソフトウェアを転がしているのを見てきました。 DNSは高速で信頼性の高いキー値ストアであり、すでにゾーンごとにキーを整理しています。大きな問題は、あらゆる種類のAPIを備えたDNSサーバーが非常に少ないことです。そのため、DNSのクラウド実装では可能ですが、RRの作成/更新を自動化することはできません。
SRVレコードは、IPv4スペースを節約できるため、ホスティング業界にとって重要です。
私たちはそれらを使用して、お客様のIPv6への移行を透明な問題で支援します。