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
| Champ | Rôle |
|---|---|
_service | Nom du service : _sip, _http, _ldap, _xmpp… |
_proto | Protocole transport : _tcp ou _udp |
priorité | Valeur basse = tentée en premier (comme MX) |
poids | Répartition entre entrées de même priorité (proportionnel) |
port | Port TCP/UDP d’écoute du service |
cible | Nom 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.10Comment 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 SRVUn 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.12Un 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
0signifie “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 SRVEn 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