Mon blog

Ce RFC spécifie un nouveau type d'enregistrement DNS, le SRV pour "service". Traditionnellement, les enregistrements contenus dans le DNS permettaient seulement de spécifier l'adresse IP correspondant à un nom comme www.bortzmeyer.org. Si on voulait avoir plusieurs machines mettant en œuvre un service, il fallait mettre plusieurs adresses dans le RRset, dans l'ensemble des enregistrements. Et, si on voulait en plus que certaines de ces adresses ne soient utilisés qu'en secours, si les premières ne répondent pas, ou si on voulait que certains adresses soient utilisés davantage que d'autres, parce qu'elles correspondent à des machines plus rapides, eh bien il n'y avait pas de solution. Plus exactement, il n'y en avait que pour le courrier, qui avait un type spécial, MX, ayant à peu près ces capacités. Mais les autres services, comme le Web, ne pouvaient pas en bénéficier.

Ce RFC introduit donc un nouvel enregistrement, SRV, qui est depuis longtemps disponible dans les serveurs de noms. Un enregistrement SRV permet d'obtenir, pour un service, non pas une adresse IP mais le nom d'un serveur physique, avec une priorité, qui permet de rendre obligatoire le passage par certaines machines d'abord, et un poids, qui permet de donner une plus grande probabilité d'usage pour certaines machines. La priorité est déterministe et absolue (si une machine de meilleure priorité est disponible, elle doit être utilisée), le poids est probabiliste (il vaut mieux essayer les serveurs de meilleur poids). L'enregistrement donne également le port à utiliser.

Le service se spécifie en le préfixant d'un trait souligné (_), caractère illégal dans les noms de machine, ce qui supprime le risque de collision. Par exemple, certains clients LDAP cherchent le serveur LDAP de leur domaine, non pas en essayant une convention comme ldap.MONDOMAINE.org mais en demandant le SRV de _ldap._tcp.MONDOMAINE.org. Une telle convention a également été proposée pour whois, afin de découvrir le serveur whois faisant autorité pour un domaine donné.

Un RRset, un ensemble d'enregistrements SRV pour le service Web de example.org pourrait donc être :

_http._tcp     SRV 0 1 80 old-slow-box.example.org.
               SRV 0 3 80 new-fast-box.example.org.
               SRV 1 0 80 personal-box.adsl.my-isp.net.

ici avec deux serveurs de même priorité (zéro), un rapide ayant un poids de 3 et un lent ayant un poids de 1, puis un serveur de secours (priorité 1). Tous écoutent sur le port 80.

Pour les développeurs, il existe déjà une bibliothèque qui met en œuvre le RFC 2782 : Ruli (pour Resolver User Layer Interface) qui simplifie considérablement la tâche du développeur. Si un si faible nombre d'applications utilise les enregistrements SRV, ce n'est donc pas faute de support logiciel.

Car, malheureusement, on constate que très peu d'applications acceptent d'utiliser les SRV. Je ne connais par exemple aucun navigateur Web qui le fasse, même pas Firefox, pour lequel la discussion a commencé il y a des années (idem pour Chrome). Pour des raisons qui m'échappent, une très belle idée, qui résoudrait de nombreux problèmes de gestion d'un parc de serveurs, reste ainsi, six ans après sa normalisation, quasiment inconnue.

À part XMPP, l'utilisation la plus courante aujourd'hui doit être dans le DNS Service Discovery du RFC 6763.