Vérificateur global d'enregistrement SRV
Alors que les enregistrements A et AAAA standard se limitent à traduire un nom de domaine en adresse IP, l'enregistrement SRV (Service) est beaucoup plus complexe. Défini dans la RFC 2782, l'enregistrement SRV établit un moyen standardisé de définir le nom d'hôte exact, le protocole et le numéro de port précis pour des applications réseau spécifiques. Ils sont l'épine dorsale de la découverte de services d'entreprise, très utilisés pour Microsoft Active Directory, le routage SIP/VoIP, la messagerie instantanée XMPP et les architectures massives de serveurs multijoueurs (comme la résolution de _minecraft._tcp.example.com).
Syntaxe et liaison de port (Port Binding)
Un enregistrement SRV est instantanément reconnaissable à sa structure de formatage rigide. Le nom de l'enregistrement doit commencer par un trait de soulignement (underscore) désignant le service, suivi d'un trait de soulignement désignant le protocole de transport, ajouté au domaine de base (par exemple, _sip._tls.example.com). Le payload résultant fournit quatre points de données spécifiques au client qui se connecte : la Priorité, le Poids (Weight), le Port cible et le Nom d'hôte cible canonique. Cela permet aux administrateurs d'exécuter plusieurs services distincts sur une seule adresse IP en utilisant des ports non standard, sans obliger les utilisateurs finaux à mémoriser et à saisir des numéros de port dans leurs clients.
Failover natif et Load Balancing pondéré
La caractéristique la plus puissante de l'enregistrement SRV est sa logique de routage native à plusieurs niveaux. L'entier de Priorité agit exactement comme un enregistrement MX ; les clients qui se connectent tenteront toujours de négocier un handshake avec le serveur à la priorité la plus basse en premier. Cela établit une redondance de failover immédiate. Si plusieurs enregistrements partagent exactement la même Priorité, l'entier de Poids (Weight) est déclenché. Il agit comme un load balancer proportionnel. Si le Serveur A a un poids de 75 et le Serveur B a un poids de 25, l'application cliente routera 75 % des nouvelles connexions vers le Serveur A. Cela permet aux ingénieurs de router intelligemment le trafic à travers des clusters avec des capacités matérielles variables.
Pourquoi HTTP ignore les enregistrements SRV
Une question courante des développeurs juniors est de savoir pourquoi le trafic web (HTTP/HTTPS) n'utilise pas les enregistrements SRV pour obtenir un load balancing natif. La réponse est purement historique. Au moment où les enregistrements SRV ont été standardisés, les conventions architecturales du HTTP fonctionnant strictement sur le port 80 et du HTTPS sur le port 443 étaient déjà universellement codées en dur dans chaque navigateur web. Passer le web aux recherches SRV aurait ajouté une pénalité de résolution massive (nécessitant des round-trips supplémentaires) pour un avantage marginal. Au lieu de cela, HTTP s'appuie sur des load balancers de couche application et le routage IP Anycast.