Enregistrement de service

Un enregistrement SRV contient les informations suivantes :

• Service: le nom symbolique (commençant généralement par un symbole de soulignement) du service concerné (par exemple _sip).
• Protocole : généralement, c'est soit "_tcp" pour TCP, soit "_udp" pour UDP.
• Nom de domaine: le domaine de validité de l'enregistrement (pleinement qualifié au format FQDN ou local à la zone DNS en cours de définition pour la même autorité d'origine).
• TTL : champ standard DNS indiquant la durée de validité (Time-To-Live, durée de vie) de la réponse (en secondes).
• Classe : champ standard DNS indiquant la classe d'adressage (c'est toujours IN pour Internet).
• Type : l'identifiant du type d'enregistrement DNS (toujours SRV ici pour un enregistrement de service)
• Priorité : la priorité du serveur cible (valeur entière non négative, plus elle est faible, plus ce serveur sera utilisé s'il est disponible). S'il y a plusieurs enregistrements à différentes priorités pour le même service et un même protocole, un seul enregistrement pour chacune des priorités sera retourné aux clients DNS (les clients sont censés alors tenter de se connecter en priorité au serveur retourné ayant la plus faible valeur de priorité parmi les enregistrements retournés, mais si cela échoue, ils peuvent utiliser le serveur suivant de priorité plus élevée dans la liste de serveurs qui lui sont retournés). Différentes priorités permettent de mettre en place des services de secours (éventuellement distincts dans leur contenu et plus limité dans les possibilités, par exemple un ou plusieurs serveurs alternatifs fonctionnant en lecture seule sans support de certaines modifications par le service).
• Poids : poids relatif pour les enregistrements de même priorité (valeur entière de 0 à 65535, permet au serveur DNS de retourner aléatoirement un des serveurs cibles ayant la même priorité, avec une distribution correspondant au poids indiqué, relativement au poids total des autres enregistrements de même priorité). Le poids indiqué n'a pas d'effet s'il n'y a qu'un serveur cible de la même priorité pour le même service et le même protocole (ce paramètre permet une distribution de charge assez sommaire entre plusieurs serveurs pour les services très fréquentés par de nombreux clients effectuant des requêtes DNS séparées, mais il n'aura pas d'effet si ces clients font leur requêtes DNS via un même serveur DNS proxy cache).
• Port : le numéro de port (TCP ou UDP selon le protocole ci-dessus) où le service est disponible.
• Cible : le nom du serveur qui fournit le service concerné (doit être résolu en adresse IPv4 ou IPv6 par d'autres requêtes DNS sur les enregistrements A ou AAAA du nom de service cible) avec le protocole et sur le port indiqué.

Par exemple, des enregistrements SRV peuvent ressembler à ceci :

_sip._tcp.example.com. 86400 IN SRV 0 33 5060 serveursip1.example.com.
_sip._tcp.example.com. 86400 IN SRV 0 33 5060 serveursip2.example.com.
_sip._tcp.example.com. 86400 IN SRV 0 33 5060 serveursip3.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 100 5060 serveursip-offline.example.com.

Ils pointent vers trois serveurs nommés serveursip{1,2,3}.example.com qui attendent des connexions SIP sur le port TCP numéro 5060. Ici, la priorité indiquée est de 0 (priorité standard par défaut), et le poids de ces serveurs est de 33 (le serveur DNS retournera équitablement aléatoirement un des 3 serveurs aux clients DNS, mais de façon équitable). La durée de validité indiquée (86400 secondes soit une journée entière) permet aux clients DNS de garder dans leur cache local cette information pendant une journée entière avant de devoir réinterroger le serveur DNS.

Le serveur retournera aussi aux clients un second serveur pour leurs requêtes, pointant sur serveursip-offline.example.com qui fournira un service SIP (éventuellement limité) si les clients ne parviennent pas à se connecter à l'un des trois premiers serveurs (ce serveur de secours à une priorité indiquée à 10 au lieu de 0, il n'est pas destiné à une utilisation permanente par les clients mais peut servir le temps d'une opération de maintenance sur l'un des 3 serveurs SIP de base, son poids indiqué à 100 n'a pas d'effet si c'est le seul serveur de secours).

Le champ priorité est similaire au champ de même nom des enregistrements MX. Les clients commencent par utiliser l'enregistrement SRV de plus basse priorité, et se rabattent sur les autres enregistrements uniquement en cas d'échec de la connexion. Ainsi, un service peut avoir un serveur désigné comme serveur de secours, qui sera seulement utilisé en cas de panne du serveur primaire: il suffit pour cela d'insérer un enregistrement SRV avec une priorité plus élevée que pour le serveur primaire.

Lorsqu'un service possède plusieurs enregistrements SRV de même priorité, les clients utilisent alors le champ poids pour décider quel serveur utiliser. Le poids ne prend son sens que lorsqu'il est mis en relation avec le poids des autres enregistrements de même priorité (toujours pour un service donné).

Dans l'exemple ci-dessous, on utilise à la fois les champs priorité et poids, afin de fournir simultanément une répartition de charge et un service de secours.

_sip._tcp.example.com. 86400 IN SRV 10 60 5060 gros-serveur.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 20 5060 petit-serveur1.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 20 5060 petit-serveur2.example.com.
_sip._tcp.example.com. 86400 IN SRV 20 100 5060 serveur-de-secours.example.com.

Les trois premiers enregistrements ont tous une priorité de 10. Les clients vont donc devoir utiliser le champ poids afin de déterminer quel serveur contacter. Pour ce champ, la somme des trois valeurs est 100, donc gros-serveur.example.com sera utilisé 60 % du temps, et chacun des deux autres (petit-serveur1 et petit-serveur2) sera utilisé 20 % du temps. Si, d'aventure, gros-serveur devenait indisponible, les deux "petits serveurs", seuls en piste, se partageraient alors la charge, ayant un poids identique.

Par ailleurs, si ces serveurs de priorité 10 deviennent tous trois indisponibles, l'enregistrement de priorité immédiatement supérieure sera choisi, en l'occurrence serveur-de-secours.example.com. Il peut s'agir d'une machine géographiquement éloignée des trois autres, donc a priori non touchée par la cause de l'indisponibilité de celles-ci.

La répartition de charge fournie par les enregistrements SRV est forcément limitée, étant donné que l'information est essentiellement statique. La charge réelle des serveurs n'est pas prise en compte.

Les enregistrements SRV sont souvent utilisés par les clients Microsoft Windows 2000 afin de trouver le contrôleur de domaine pour un service donné.

Par ailleurs, les enregistrements SRV sont communément utilisés en association avec les protocoles standards ci-dessous :

• XMPP (Jabber)
• SIP
• LDAP

Pour vérifier la présence d'un enregistrement SRV sur un domaine, les commandes nslookup et dig peuvent être utilisées.

Par exemple :

dig SRV _sip._tcp.example.com. +short

Exemple réel :

% dig SRV _sip._tcp.jabber.com. +short
10 33 5060 cjv-sbc-trunk-2.global.jabber.com.
10 33 5060 cjv-sbc-trunk-1.global.jabber.com.
10 34 5060 cjv-sbc-trunk-3.global.jabber.com.

ou encore :

nslookup -q=SRV _sip._tcp.example.com.

Exemple réel :

% nslookup -q=SRV _sip._tcp.jabber.com
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
_sip._tcp.jabber.com	service = 10 33 5060 cjv-sbc-trunk-1.global.jabber.com.
_sip._tcp.jabber.com	service = 10 33 5060 cjv-sbc-trunk-2.global.jabber.com.
_sip._tcp.jabber.com	service = 10 34 5060 cjv-sbc-trunk-3.global.jabber.com.

Authoritative answers can be found from: