Dans les coulisses d’Internet, certains mécanismes restent invisibles jusqu’au jour où un service ne répond plus. L’enregistrement DNS SRV fait partie de ces éléments discrets mais essentiels : il indique à une application où trouver un service précis, sur quel serveur et via quel port.
Un enregistrement DNS SRV, pour Service Record, est un type d’enregistrement du système de noms de domaine. Son rôle est de publier l’emplacement d’un service réseau associé à un domaine. Là où un enregistrement A relie un nom de domaine à une adresse IPv4, un SRV fournit des informations plus riches : le service, le protocole, le port et le serveur cible.
Concrètement, il permet à un logiciel de découvrir automatiquement le bon serveur à contacter. Par exemple, un client de messagerie, une application de téléphonie IP ou un outil d’authentification peut interroger le DNS pour savoir vers quel hôte se diriger. L’enregistrement DNS SRV évite ainsi de coder manuellement certains paramètres dans les applications ou les configurations locales.
L’intérêt principal d’un enregistrement SRV est de faciliter la découverte automatique de services. Au lieu de supposer qu’un service se trouve sur un serveur ou un port par défaut, l’application demande au DNS où il est réellement disponible. Cela offre davantage de souplesse, notamment lorsque plusieurs serveurs assurent le même service.
Ce mécanisme est utilisé dans différents environnements. On le rencontre dans la téléphonie sur IP avec SIP, dans la messagerie instantanée avec XMPP, dans certains annuaires LDAP, dans les infrastructures Microsoft Active Directory ou encore dans des configurations liées à Kerberos. Il sert aussi dans des contextes professionnels où la haute disponibilité et la répartition de charge sont importantes.
Le SRV ne remplace pas les autres enregistrements DNS : il les complète. Il ne distribue pas d’adresse IP à une machine, contrairement aux mécanismes décrits dans le cadre des baux d’adresse utilisés par DHCP. Il indique plutôt à quel nom d’hôte un client doit ensuite se connecter.
Un enregistrement SRV suit une structure précise. Sa forme générale ressemble à ceci : _service._protocole.domaine. La partie service commence par un underscore, tout comme le protocole. Cette convention permet de distinguer clairement les informations de service des noms d’hôtes classiques.
Un exemple typique pourrait être : _sip._tcp.exemple.com. IN SRV 10 60 5060 sip1.exemple.com. Dans cette ligne, le client apprend que le service SIP en TCP pour le domaine exemple.com se trouve sur sip1.exemple.com, via le port 5060, avec une priorité de 10 et un poids de 60.
La priorité sert à organiser les serveurs disponibles. Plus la valeur est basse, plus le serveur est prioritaire. Si deux serveurs sont déclarés avec des priorités différentes, le client tente d’abord celui qui possède la valeur la plus faible. Les serveurs de priorité plus élevée ne sont utilisés qu’en cas d’échec ou d’indisponibilité.
Le poids intervient lorsque plusieurs serveurs ont la même priorité. Il permet une forme simple de répartition de charge. Un serveur avec un poids plus élevé recevra proportionnellement plus de connexions qu’un autre serveur du même niveau de priorité. Cette logique reste dépendante du comportement des clients, mais elle est largement comprise par les logiciels compatibles.
Le port, enfin, précise où joindre le service sur le serveur cible. C’est l’une des forces de l’enregistrement SRV : il n’oblige pas à utiliser un port standard. Une organisation peut donc publier un service sur un port spécifique, à condition que les clients sachent interpréter correctement les enregistrements SRV.
Lorsqu’une application a besoin d’un service, elle interroge le DNS pour obtenir l’enregistrement SRV correspondant. La réponse lui indique le ou les serveurs disponibles. Ensuite, le client doit généralement résoudre le nom d’hôte cible à l’aide d’un enregistrement A ou AAAA, afin d’obtenir l’adresse IP finale.
Ce processus s’inscrit dans le fonctionnement global du DNS. La requête peut passer par un résolveur, des serveurs faisant autorité et plusieurs étapes intermédiaires avant d’obtenir la réponse. Pour mieux comprendre cette mécanique, le fonctionnement de la recherche DNS effectuée par un résolveur aide à replacer les enregistrements SRV dans l’ensemble de la chaîne.
Un point important : la cible d’un SRV doit être un nom d’hôte, pas une adresse IP directe. Ce nom sera résolu dans un second temps. Cette séparation rend la configuration plus flexible, car l’adresse IP du serveur peut changer sans modifier l’enregistrement SRV lui-même.
Dans les entreprises, les enregistrements SRV sont fréquemment associés à Active Directory. Les postes clients les utilisent pour localiser les contrôleurs de domaine, les services Kerberos ou LDAP. Sans ces informations, certaines opérations d’authentification ou de connexion au domaine peuvent devenir instables.
Dans la voix sur IP, les enregistrements SRV peuvent indiquer à un téléphone logiciel ou matériel quel serveur SIP contacter. Cela permet de gérer plusieurs serveurs, de prévoir un secours et d’éviter de configurer chaque client avec une adresse fixe. Pour les services de messagerie instantanée comme XMPP, le principe est similaire : le domaine publie les serveurs capables de gérer les communications.
On retrouve aussi les SRV dans certains scénarios d’autoconfiguration. Une application peut identifier automatiquement un point de connexion sans que l’utilisateur ait à connaître le nom exact du serveur. Cette approche améliore l’expérience utilisateur, mais elle suppose une configuration DNS rigoureuse.
La première règle consiste à vérifier la syntaxe. Les underscores devant le service et le protocole sont obligatoires dans la plupart des usages. Une erreur sur ce point peut rendre l’enregistrement invisible pour les clients. Il faut aussi s’assurer que le serveur cible dispose bien d’un enregistrement A ou AAAA valide.
Le choix du TTL, ou durée de vie en cache, mérite également attention. Un TTL court facilite les changements rapides, par exemple lors d’une migration. Un TTL plus long réduit le nombre de requêtes DNS, mais ralentit la propagation des modifications. En pratique, il est courant de réduire temporairement le TTL avant une intervention planifiée.
Il est également recommandé de tester la configuration avec des outils comme dig, nslookup ou des vérificateurs DNS spécialisés. Ces tests permettent de confirmer que la priorité, le poids, le port et la cible sont correctement publiés. Une simple erreur de point final dans un nom pleinement qualifié peut provoquer des comportements inattendus.
Un enregistrement DNS SRV ne garantit pas à lui seul qu’un service fonctionne. Il peut indiquer un serveur et un port corrects, mais si le service est arrêté, bloqué par un pare-feu ou mal configuré, la connexion échouera. Le DNS fournit une indication, pas une supervision complète de l’état réel du service.
Une autre limite tient à la compatibilité. Tous les logiciels ne consultent pas les enregistrements SRV, même lorsque cela serait techniquement possible. Certains clients attendent une configuration manuelle ou utilisent d’autres mécanismes. Avant de déployer un SRV, il faut donc vérifier que les applications concernées savent l’exploiter.
Les erreurs les plus courantes concernent la cible mal définie, l’utilisation d’une adresse IP à la place d’un nom d’hôte, un port incorrect ou une mauvaise combinaison entre service et protocole. Dans un environnement de production, ces détails peuvent entraîner des interruptions difficiles à diagnostiquer.
Les enregistrements A et AAAA servent à associer un nom à une adresse IP. L’enregistrement MX indique les serveurs responsables de la réception des emails pour un domaine. Le CNAME crée un alias vers un autre nom. Le SRV, lui, décrit un service réseau précis, en ajoutant les notions de protocole, port, priorité et poids.
Cette différence explique pourquoi le SRV est plus adapté à certains usages applicatifs. Il ne dit pas seulement “où se trouve ce nom”, mais “où se trouve ce service pour ce domaine”. C’est une nuance importante dans les architectures modernes, où un même domaine peut s’appuyer sur plusieurs serveurs spécialisés.
Un enregistrement DNS SRV est un outil de publication de services. Il permet à une application de localiser automatiquement un serveur, un protocole et un port, tout en offrant des options de priorité et de répartition. Bien configuré, il renforce la souplesse d’une infrastructure et simplifie la découverte de services.
Son efficacité dépend toutefois de plusieurs conditions : une syntaxe correcte, des cibles DNS valides, des clients compatibles et des services réellement accessibles. Pour les administrateurs système comme pour les responsables techniques, comprendre le fonctionnement des enregistrements SRV permet de mieux diagnostiquer les problèmes de connexion et de concevoir des architectures plus fiables.
