SRVレコードは有用になりますか？

DNSでは、SRVレコードは実際、特定のサービスがホストされている場所をリモートクライアントに伝えるかなり一般的な形式です。現時点では、インターネット経由でSIPクライアントを使用して電話をかけることができるようにするために使用しています（非常にうまく機能します）。

SRVレコードの利点の1つは、サービスに別のポートを指定でき、同じ（または同じシステムと異なるポート上の複数のインスタンス）に複数のシステムを使用できることです。だからIFFそれはあなたが任意の干渉せずに、単一のシステム上で複数のWebサーバを持つことができます動作します。

したがって、DNSにこれを含めることができます。

_http._tcp SRV 10 50 8080 myserver.basjes.nl
_http._tcp SRV 10 50 8081 myserver.basjes.nl

しかし、このすべての良さに対する1つの小さな障害があります...それをサポートするHTTP、FTP、SMTP、...クライアントを見つけることができませんでした。

Wikipediaページで言及されているSIPおよび他のいくつかのプロトコル以外：SRVレコードは本当に役立つようになりますか？

または私は何かを見逃しましたか？

うまく機能するものがありますか？

新しいプロトコルにのみ使用されるのがわかると思います。

SMTPが使用するMXレコードは、固定ポートで重みのないSRVレコードと同等です。言い換えれば、彼らはすでに同じ問題を適切に解決しています。

たとえば、HTTPは現在のメカニズムとの後方互換性を保持する必要があるため、SRV for HTTPの使用を開始した人は、とにかく代替メカニズムを提供する必要があり、同じことを行う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のドメインが、クライアントソフトウェアが接続する必要のあるホスト名と異なることが一般的な場合です。したがって、なぜSIPで、またJabber（XMPP）でも使用されるのか。

SMTPには最初からMXレコードが常にあったため、SMTPは必要ありません。

別のポートを使用できるという利点は比較的小さいため、他のプロトコルではあまり使用されていません。

URIスキームを提案するインターネットドラフトがありhttp+srv:ますが、標準のhttp:URIリクエストにSRVルックアップを追加する提案は現在ないことに注意してください。

Outlook 2007およびExchange 2007はSRVレコードを使用します http://technet.microsoft.com/en-us/library/bb332063.aspx

SRVレコードは、DNSサービスディスカバリー（DNS-SD）の基礎となる構造の1つであるため、ますます重要になると思います。

また、ネットワーク上のbonjour / zeroconfリソースを見つけることができるiStumbler for macなどのネットワークブラウザーなどのDNS-SD対応クライアントと組み合わせて、既存のテクノロジーで使用できない理由もありません。

私の意見では、SRVレコードは、動的更新DNSがさらに利用可能になったときにのみ一般的になります。MS-DNSでは、Active Directoryの要件により、大部分がデフォルトで動的更新がオンになっています。サービスロケーションプロトコル、サービスアドバタイジングプロトコル（IPXネットワーク）、Bonjour / Avahi、さらにはDHCPなど、多くのリソースアドバタイジングディレクトリが長年にわたって存在していました。

これらのうち、DNSのみがインターネットに広がるリソースディレクトリの真の可能性を持っています。パブリックDNSサーバーは、理由により静的なものになる傾向があります。SRVレコードの採用は、TXTレコードの採用がSPFプロトコルで行われたように、それらのニーズが定義されているときに行われます。SRVを使用したSIPは、MS以外の幅広い採用への扉を開く最初のステップになる可能性があります。

SRVレコードは、エンタープライズでのライセンス認証のためにWindows Vista / 2008サーバーをKMSサーバーに送信するために使用されます。

XMPPはそれらを使用しています。

ただし、既存のプロトコルは、それらをサポートするように変更されることはありません。特に、リクエストを別のポートにリダイレクトすることはありません。これは予想外のことであり、セキュリティ関連のいくつかの仮定を間違いなく破ります。

SRVレコードは、誰もが同じプロバイダーを使用する必要なく、通信サービスを実装するためのメカニズムを提供します。つまり、AおよびMXレコードがWebおよび電子メールに対して行うこと、SRVレコードはすべてのサービスに対して行うことです。

このアイデアは、ブログ記事「The Power of Free Addressing」http://e-caller.com/?p=4で概説されています

TwitterとFacebookの台頭は、SRV対応の代替手段の不足に起因しています。

Fedora / Red Hatプロジェクトfreeipaはそれらを使用し、同様に負荷分散とスケーラビリティの理由からpuppet labs puppetも使用します。ユースケースとそれらの使用方法について学習すればするほど、それが大好きになります。DNSやインフラストラクチャに起こった最高のものです。spotifyがそれらを使用する方法を確認してくださいhttps://labs.spotify.com/2013/02/25/in-praise-of-boring-technology/

DNSはゼロから実装する必要がなく、zookeeperやetcdのようなものよりもはるかに軽量なので、サービスロケーターを必要とするアプリケーションスタックに非常に役立ちます。また、非常に安全にできる便利さもあります。Spotify以外の人がこの方法でほとんど使用しない理由はわかりませんが、単に無知だと思います。多くの人が独自の非常に劣ったカスタムサービスロケーションソフトウェアを転がしているのを見てきました。DNSは高速で信頼性の高いキーバリューストアであり、すでにゾーンごとにキーを整理しています。大きな問題は、あらゆる種類のAPIを備えたDNSサーバーが非常に少ないことです。そのため、DNSのクラウド実装は可能ですが、RRの作成/更新を自動化することはできません。

SRVレコードは、IPv4スペースを節約できるため、ホスティング業界にとって重要です。

これらを使用して、透過的にお客様がIPv6に移行できるようにします。