Les enregistrements SRV deviendront-ils jamais utiles?

Dans DNS, un enregistrement SRV est vraiment une forme assez générique de dire à un client distant où un service spécifique est hébergé. En ce moment, je l'utilise pour permettre aux gens de m'appeler en utilisant un client SIP sur Internet (fonctionne très bien).

L'un des avantages de l'enregistrement SRV est que vous pouvez spécifier un port différent pour le service et que vous pouvez avoir plusieurs systèmes pour le même (ou le même système et plusieurs instances sur un port différent). Donc, IFF ça marche, vous pouvez avoir plusieurs serveurs Web sur un seul système sans aucune interférence.

Vous pouvez donc avoir ceci dans votre DNS:

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

Il y a cependant un petit hic à toute cette bonté ... Je n'ai pas pu trouver de clients HTTP, FTP, SMTP, ... qui le prennent en charge.

Donc, à part SIP et les quelques autres protocoles mentionnés dans la page Wikipedia : L'enregistrement SRV deviendra-t-il vraiment utile?

Ou ai-je raté quelque chose?

Y a-t-il quelque chose de mieux là-bas qui fonctionne?

Je pense que vous ne le verrez que pour de nouveaux protocoles.

Les enregistrements MX que SMTP utilise sont équivalents aux enregistrements SRV avec un port fixe et sans poids. En d'autres termes, ils ont déjà correctement résolu le même problème.

Étant donné que, par exemple, HTTP doit préserver la compatibilité descendante avec les mécanismes actuels, quiconque a commencé à utiliser SRV pour HTTP devrait quand même fournir un mécanisme alternatif, et personne ne veut conserver deux façons de faire la même chose. (par exemple, certains équilibreurs de charge et certains enregistrements DNS SRV ...) Et si les sites ne publient pas d'enregistrements SRV (car cela crée simplement un travail inutile), les clients ne sont pas motivés à prendre en charge les enregistrements SRV que personne ne publie.

Ils sont assez utiles dans un domaine Active Directory .

Les enregistrements SRV sont également utilisés par de nombreux services et clients compatibles Kerberos. Cela est particulièrement vrai sur une machine particulière où /etc/krb5.conf (ou son équivalent) n'est pas lisible ou manquant; une recherche d'enregistrement SRV sera effectuée pour trouver le KDC.

La technologie Bonjour d'Apple (alias zeroconf) en fait un usage intensif. Si vous ne l'avez pas vu en action - vérifiez-le. Il vous permet de découvrir automatiquement les imprimantes, les routeurs, les pages Web activées par bonjour, etc.

Il existe un module Apache sous licence BSD appelé mod_bonjour qui vous permet de publier des sites Web via DNS multicast. Vous pouvez également annoncer des sites via des enregistrements SRV et DNS standard, mais je pense que seul Safari sera en mesure de les détecter.

La page Web de Zeroconf a une assez bonne explication sur la façon dont cela fonctionne - je recommanderais également de consulter le livre si vous êtes intéressé par la technologie.

L'un des gros problèmes avec cela en général est que les personnes DNS ne se considèrent pas comme des entreprises de découverte de services, et les personnes de sécurité paranoïdes considèrent la possibilité de découvrir des services comme un risque pour la sécurité.

En effet, la plupart des applications ne le prennent pas encore en charge.

Ceux qui le font sont ceux où il est courant que le domaine dans l'identité de l'utilisateur cible soit différent du nom d' hôte auquel le logiciel client doit se connecter. D'où la raison pour laquelle il est utilisé dans SIP, et aussi dans Jabber (XMPP).

SMTP n'en a pas besoin car il y avait toujours des enregistrements MX dès le départ.

L'avantage de pouvoir utiliser un port différent est relativement mineur, donc d'autres protocoles n'ont pas commencé à l'utiliser beaucoup.

Il existe un brouillon Internet qui propose un http+srv:schéma d'URI, mais notez qu'il n'y a aucune proposition actuelle pour ajouter des recherches SRV aux demandes d' http:URI standard .

Outlook 2007 et Exchange 2007 utilisent des enregistrements SRV http://technet.microsoft.com/en-us/library/bb332063.aspx

Je crois que les enregistrements SRV sont l'une des structures sous-jacentes dans la découverte de service DNS (DNS-SD) et seront donc de plus en plus importants.

Il n'y a également aucune raison pour laquelle ils ne peuvent pas être utilisés avec les technologies existantes, en conjonction avec des clients compatibles DNS-SD, par exemple des navigateurs réseau, tels que iStumbler pour mac qui peuvent trouver des ressources bonjour / zeroconf sur le réseau.

À mon avis, les enregistrements SRV ne deviendront plus courants que lorsque le DNS de mise à jour dynamique sera plus disponible. MS-DNS a la mise à jour dynamique activée par défaut en très grande partie en raison des exigences d'Active Directory. Il y a eu de nombreux répertoires publicitaires sur les ressources au fil des ans, y compris le protocole d'emplacement de service, le protocole de publicité de service (réseaux IPX), Bonjour / Avahi et même DHCP dans une certaine mesure.

Parmi ceux-ci, seul DNS a un vrai potentiel pour un répertoire de ressources couvrant Internet. Les serveurs DNS publics ont tendance à être statiques pour une raison. L'adoption des enregistrements SRV viendra quand il y aura un besoin défini pour eux, tout comme l'adoption des enregistrements TXT est née pour le protocole SPF. SIP utilisant des SRV pourrait être la première étape pour ouvrir la porte à une adoption plus large et non-MS.

Les enregistrements SRV sont utilisés pour diriger les serveurs Windows Vista / 2008 vers votre serveur KMS pour l'activation dans l'entreprise.

XMPP les utilise.

Mais les protocoles existants ne changeront pas pour les prendre en charge, en particulier la redirection d'une demande vers un port différent. Ce serait inattendu et briserait sans aucun doute certaines hypothèses liées à la sécurité.

Les enregistrements SRV offrent un mécanisme pour mettre en œuvre des services de communication sans que tout le monde utilise le même fournisseur. En d'autres termes, ce que les enregistrements A et MX font pour le Web et le courrier électronique, les enregistrements SRV font pour n'importe quel service.

Cette idée est décrite dans un article de blog "Le pouvoir de l'adressage gratuit" http://e-caller.com/?p=4

L'essor de Twitter et de Facebook est dû au manque d'alternatives activées par SRV.

Le projet Fedora / Red Hat freeipa les utilise, ainsi que les marionnettes des laboratoires de marionnettes pour des raisons d'équilibrage de charge et d'évolutivité. plus j'en apprends sur ses cas d'utilisation et comment ils sont largement utilisés, plus j'en suis amoureux. c'est la meilleure chose qui soit arrivée au DNS et aux infrastructures. Découvrez comment Spotify les utilise https://labs.spotify.com/2013/02/25/in-praise-of-boring-technology/

Ils sont très utiles pour les piles d'applications qui nécessitent un localisateur de service, car le DNS n'a pas besoin d'être implémenté à partir de zéro et est beaucoup plus léger que quelque chose comme zookeeper ou etcd. Il y a aussi la commodité supplémentaire qui peut être sécurisée. Je ne sais pas pourquoi presque personne à part Spotify l'utilise de cette manière, je soupçonne juste l'ignorance. J'ai vu beaucoup de gens lancer leur propre logiciel de localisation de service personnalisé largement inférieur. DNS est un magasin de valeurs clés rapide et fiable et organise déjà ses clés par zone. Le gros problème est que très peu de serveurs DNS ont une sorte d'API, donc l'automatisation de la création / mise à jour de RR n'est pas possible, bien que les implémentations cloud de DNS le fassent.

Les enregistrements SRV sont CRUCIAL pour l'industrie de l'hébergement, car ils vous permettent d'économiser de l'espace IPv4.

Nous les utilisons pour faciliter la transition de nos clients vers IPv6 de manière transparente.