Aller au contenu principal

6. Règles d'Utilisation (Usage Rules)

6.1 Procédure de Traitement Client (Client Processing Procedure)​

Un client conscient de SRV DEVRAIT (SHOULD) utiliser cette procédure pour localiser une liste de serveurs et se connecter au préféré :

6.2 Étapes de l'Algorithme (Algorithm Steps)​

Étape 1 : Effectuer une Requête SRV (Perform SRV Query)​

Effectuer une recherche pour :

QNAME=_service._protocol.target
QCLASS=IN
QTYPE=SRV

Étape 2 : Vérifier la Réponse (Check Response)​

Si la réponse est NOERROR, ANCOUNT>0 et il y a au moins un SRV RR qui spécifie le Service et le Protocole demandés dans la réponse :

Étape 3 : Vérifier l'Indisponibilité du Service (Check for Service Unavailability)​

S'il y a précisément un SRV RR, et que son Target est "." (le domaine racine), abandonner.

Étape 4 : Construire la Liste de Candidats (Build Candidate List)​

Sinon, pour tous ces RR, construire une liste de tuples (Priority, Weight, Target).

Étape 5 : Trier par Priorité (Sort by Priority)​

Trier la liste par priorité (numéro le plus bas en premier).

Étape 6 : Créer une Liste Ordonnée (Create Ordered List)​

Créer une nouvelle liste vide.

Pour chaque niveau de priorité distinct :

  • Tant qu'il reste des éléments à ce niveau de priorité
    • Sélectionner un élément comme spécifié ci-dessus, dans la description de Weight dans la section "Format de l'enregistrement SRV", et le déplacer à la fin de la nouvelle liste

Étape 7 : Interroger et Se Connecter (Query and Connect)​

Pour chaque élément de la nouvelle liste :

  1. Interroger le DNS pour les enregistrements d'adresse pour le Target ou utiliser tout enregistrement trouvé dans la section Additional Data de la réponse SRV précédente
  2. Pour chaque enregistrement d'adresse trouvé, essayer de se connecter au (protocol, address, service)

Étape 8 : Repli sur l'Enregistrement A (Fallback to A Record)​

Sinon (s'il n'y a pas d'enregistrements SRV) :

Effectuer une recherche pour :

QNAME=target
QCLASS=IN
QTYPE=A

Pour chaque enregistrement d'adresse trouvé, essayer de se connecter au (protocol, address, service).

6.3 Notes Importantes (Important Notes)​

6.3.1 Numéros de Port (Port Numbers)​

Interdiction

Les numéros de port NE DEVRAIENT PAS (SHOULD NOT) être utilisés à la place des noms symboliques de service ou de protocole (pour la même raison que les noms variants ne peuvent pas être autorisés : les applications devraient faire deux recherches ou plus).

6.3.2 Réponses Tronquées (Truncated Responses)​

Si une réponse tronquée revient d'une requête SRV, les règles décrites dans [RFC 2181] s'appliquent.

6.3.3 Exigences d'Analyse (Parsing Requirements)​

Obligatoire

Un client DOIT (MUST) analyser tous les RR dans la réponse.

6.3.4 Section Additional Data (Additional Data Section)​

Si la section Additional Data ne contient pas d'enregistrements d'adresse pour tous les SRV RR et que le client peut vouloir se connecter au(x) hôte(s) cible(s) impliqué(s), le client DOIT (MUST) rechercher le(s) enregistrement(s) d'adresse.

Scénario Courant

Cela se produit assez souvent lorsque l'enregistrement d'adresse a un TTL plus court que les SRV ou NS RR.

6.3.5 Protocoles Futurs (Future Protocols)​

Les protocoles futurs pourraient être conçus pour utiliser les recherches SRV RR comme moyen par lequel les clients localisent leurs serveurs.

Tags :
Dernière mise à jour le