Résumé

  • DNS SRV a permis au responsable d’un domaine de publier, pour un service et un transport précis, plusieurs hôtes, leurs ports, l’ordre de secours et une préférence statistique entre cibles de même rang.
  • Priority et Weight ne disent pas la même chose : le client épuise le rang au plus petit nombre avant de passer au suivant ; le tirage pondé n’ordonne que les cibles d’un même rang.
  • L’enregistrement n’authentifie ni le serveur ni l’application. Le client doit encore résoudre une cible canonique, ouvrir le transport sur le port annoncé et vérifier ce qui répond.

Quand le port était encore dans la mémoire du client

Le DNS historique savait associer un nom d’hôte à une adresse. Pour trouver un service, le logiciel ajoutait souvent une convention : un port connu, une entrée locale dans /etc/services ou le nom exact d’une machine communiqué par l’administrateur. Le nom public, l’hôte, le port et le plan de secours se confondaient alors dans une seule habitude.

RFC 2052 a proposé en octobre 1996 un enregistrement expérimental distinct. Le client ne demanderait plus seulement l’adresse d’un hôte, mais les emplacements d’un service sous un domaine. Il recevrait des cibles accompagnées d’une priorité, d’un poids et d’un port.

RFC 2782 a remplacé ce texte en février 2000 comme norme proposée. L’objectif était concret : déplacer un service avec moins de perturbation, proposer plusieurs serveurs et distinguer les machines principales des secours. Le registre actuel de l’IANA attribue le type DNS 33 à SRV, sous la description « Server Selection ».

Une question en trois parties

Pour chercher LDAP sur TCP dans example.com, un client compatible interroge _ldap._tcp.example.com. Le service, le transport et le domaine administratif restent lisibles séparément. Les traits de soulignement ont été ajoutés par RFC 2782 pour éviter que ces métadonnées ne se confondent avec des noms DNS ordinaires.

Cette convention a ensuite reçu une discipline de registre. RFC 6335 a unifié les procédures des noms de service et des numéros de port. Un nom enregistré peut servir à SRV sans qu’un port soit forcément attribué. L’enregistrement coordonne une chaîne ; il ne constitue pas une approbation de l’application ou du trafic.

RFC 8552 a créé en 2019 le registre des noms DNS globaux commençant par un soulignement. RFC 8553 a adapté les spécifications utilisant SRV à ce modèle sans casser la pratique existante. Une astuce anticollision est ainsi devenue une surface d’allocation vérifiable.

La priorité n’est pas un poids

Le RDATA SRV contient quatre champs : Priority, Weight, Port et Target.

La priorité organise le basculement. Le client doit essayer une cible joignable du plus petit rang numérique. Les rangs supérieurs ne partagent pas simplement moins de trafic ; ils attendent que le rang préféré ne puisse plus servir.

Le poids n’agit qu’entre enregistrements de même priorité. Le client additionne les poids, effectue un tirage uniforme, choisit dans une somme cumulée, retire l’élément puis recommence. Le DNS publie une proportion relative ; chaque client produit son ordre. Un poids nul n’est même pas une interdiction absolue lorsqu’il coexiste avec des poids positifs : l’algorithme lui laisse une très faible chance.

L’exemple de RFC 2782 place deux serveurs au rang zéro avec les poids un et trois. Sur un grand nombre de premiers choix indépendants, le second devrait tendre vers trois quarts. Deux hôtes au rang un ne sont consultés que si le premier groupe échoue. Aucune requête individuelle ne promet un rapport exact.

Le poids n’est pas une télémétrie de charge. Une file, un processeur ou une latence change plus vite qu’un cache DNS. Raccourcir sans cesse les TTL pour suivre cette charge augmenterait le trafic DNS et diminuerait la fiabilité. Le champ exprime une différence relativement stable de capacité ou de connectivité.

Le port déplace une autre connaissance vers le domaine. Il peut correspondre au numéro enregistré, mais ce n’est pas obligatoire. Un service peut changer de port sans attendre la modification d’un fichier sur chaque machine cliente.

La cible termine la chaîne de découverte : elle doit posséder des adresses et ne doit pas être un alias. Le client utilise les A/AAAA de la section Additional ou les demande séparément. SRV n’autorise pas à cacher une nouvelle redirection CNAME ou DNAME dans la cible.

Dire non est différent de ne rien dire

Une cible unique . signifie que le service est décidément indisponible sous ce domaine. Le domaine existe peut-être et d’autres services aussi ; seule cette combinaison service-transport reçoit un refus explicite.

L’absence d’un SRV utilisable avait une autre conséquence dans la procédure originale : rechercher l’adresse du domaine et appliquer la vieille convention. Les auteurs jugeaient futile d’attendre la mise à jour simultanée de tous les clients. Les administrateurs devaient donc conserver un chemin compatible, tout en évitant de mettre un serveur strictement de secours dans la liste ordinaire si les anciens clients l’auraient pris pour un principal.

Cette coexistence transférait un choix à l’opérateur. Garder le chemin ancien préservait l’accès, mais contournait parfois les priorités et ports nouveaux. Le supprimer rendait la politique cohérente, au prix d’abandonner les logiciels ignorants de SRV.

Une publication DNS ne vaut pas preuve du service

Le client doit lire tout le RRset, construire un ordre, résoudre les adresses puis tenter chaque combinaison transport-adresse-port. Une réponse DNS authentique indique ce que l’autorité du domaine a publié. Elle ne prouve ni la santé du processus, ni l’identité applicative, ni le consentement de l’hôte cible, ni une propriété commune entre les organisations.

La surface de risque s’élargit donc avec l’expressivité. Un falsificateur DNS peut fournir un faux port en plus d’un faux nom ou d’une fausse adresse. Un domaine peut désigner un hôte tiers et lui envoyer du trafic non sollicité. Les ports fins compliquent le filtrage et rapprochent les responsabilités des équipes DNS et réseau.

RFC 2782 limite aussi qui peut mettre SRV en jeu. La spécification de l’application doit prévoir son usage, définir le nom symbolique et traiter la sécurité. Un administrateur DNS ne peut pas inventer un libellé et obliger tous les protocoles à lui obéir.

Sources et limites

Le dossier repose exclusivement sur RFC 2052, RFC 2782, RFC 6335, RFC 8552, RFC 8553 et le registre DNS de l’IANA. Ils prouvent le contrat et son évolution, pas l’adoption actuelle, un gain de latence, la conformité des logiciels ou la disponibilité d’un service vivant.

L’apport historique de SRV tient à cette modestie : un service peut quitter une machine et un port sans que le domaine perde son nom stable. Mais ce nom ne devient jamais la preuve que le prochain hôte mérite la connexion.