Enregistrement SRV — Service

L’enregistrement SRV indique la localisation d’un service réseau spécifique : quel hôte, quel port, avec quelle priorité et quel poids. Contrairement au MX (dédié aux emails), SRV est générique — il peut décrire n’importe quel service.

Voir Enregistrements DNS pour la liste complète des types.


Structure d’un SRV

_service._proto.domaine.  TTL  IN  SRV  priorité  poids  port  cible
ChampRôle
_serviceNom du service : _sip, _http, _ldap, _xmpp
_protoProtocole transport : _tcp ou _udp
prioritéValeur basse = tentée en premier (comme MX)
poidsRépartition entre entrées de même priorité (proportionnel)
portPort TCP/UDP d’écoute du service
cibleNom de l’hôte (doit avoir un A/AAAA)

Scénario 1 : VoIP / téléphonie SIP

Ton entreprise utilise des téléphones IP. Deux serveurs VoIP en actif/actif avec un backup :

_sip._tcp.monentreprise.fr.   3600  IN  SRV  10  70  5060  voip1.monentreprise.fr.
_sip._tcp.monentreprise.fr.   3600  IN  SRV  10  30  5060  voip2.monentreprise.fr.
_sip._tcp.monentreprise.fr.   3600  IN  SRV  20   0  5060  voip-backup.monentreprise.fr.
 
; A records correspondants
voip1.monentreprise.fr.        IN  A  10.0.1.10
voip2.monentreprise.fr.        IN  A  10.0.1.11
voip-backup.monentreprise.fr.  IN  A  10.0.2.10

Comment un téléphone IP résout ça au démarrage :

dig _sip._tcp.monentreprise.fr SRV →

  priorité 10, poids 70 : voip1:5060  ┐
  priorité 10, poids 30 : voip2:5060  ┘ tentés en premier
                                         voip1 reçoit 70/(70+30) = 70% des appels
                                         voip2 reçoit 30/(70+30) = 30% des appels

  priorité 20, poids  0 : voip-backup:5060
                                         uniquement si priorité 10 est entièrement KO

Le téléphone n’a pas besoin de connaître les IPs ni les ports à l’avance — tout vient du DNS.


Scénario 2 : découverte de services dans Kubernetes

CoreDNS (le DNS interne de Kubernetes) génère automatiquement des SRV pour chaque Service :

; Format automatique : _port-name._proto.service.namespace.svc.cluster.local
_https._tcp.mon-api.default.svc.cluster.local.  IN  SRV  0  100  443  mon-api.default.svc.cluster.local.
_http._tcp.mon-api.default.svc.cluster.local.   IN  SRV  0  100   80  mon-api.default.svc.cluster.local.
# Depuis un pod, découvrir les ports exposés par un service
dig _https._tcp.mon-api.default.svc.cluster.local SRV

Un pod peut ainsi découvrir dynamiquement sur quel port écoute un service, sans avoir la valeur codée en dur.


Scénario 3 : cluster etcd (Kubernetes)

etcd utilise SRV pour que les membres du cluster se découvrent mutuellement :

_etcd-server._tcp.cluster.local.  IN  SRV  0  0  2380  etcd-0.cluster.local.
_etcd-server._tcp.cluster.local.  IN  SRV  0  0  2380  etcd-1.cluster.local.
_etcd-server._tcp.cluster.local.  IN  SRV  0  0  2380  etcd-2.cluster.local.
 
etcd-0.cluster.local.  IN  A  10.0.0.10
etcd-1.cluster.local.  IN  A  10.0.0.11
etcd-2.cluster.local.  IN  A  10.0.0.12

Un nouveau membre etcd peut rejoindre le cluster en cherchant _etcd-server._tcp.cluster.local — sans configuration statique des IPs.


Calcul du poids (load balancing)

Le poids répartit la charge entre entrées de même priorité :

Priorité 10, poids 60 : serveur A
Priorité 10, poids 30 : serveur B
Priorité 10, poids 10 : serveur C

→ Serveur A reçoit : 60/(60+30+10) = 60% du trafic
→ Serveur B reçoit : 30/100        = 30% du trafic
→ Serveur C reçoit : 10/100        = 10% du trafic

Poids 0 signifie “utiliser uniquement si aucun autre de la même priorité n’est disponible” (cas du backup).


Commandes de diagnostic

# Interroger un SRV
dig _sip._tcp.monentreprise.fr SRV
 
# Résultat attendu :
# _sip._tcp.monentreprise.fr. 3600 IN SRV 10 70 5060 voip1.monentreprise.fr.
# _sip._tcp.monentreprise.fr. 3600 IN SRV 10 30 5060 voip2.monentreprise.fr.
 
# Dans Kubernetes
kubectl exec -it mon-pod -- dig _https._tcp.mon-api.default.svc.cluster.local SRV

En relation avec

  • Enregistrements DNS — hub des types d’enregistrements
  • DNS - A et AAAA — la cible SRV doit avoir un enregistrement A
  • DNS - MX — le MX est un SRV spécialisé pour les emails
  • etcd — utilise SRV pour la découverte de cluster
  • cilium — le réseau Kubernetes résout les SRV via CoreDNS
  • DNS — fonctionnement de la résolution DNS