Pourquoi un enregistrement SRV n’aide qu’un client qui l’interroge

Ajouter un enregistrement SRV à votre zone n’apprend à aucun client VPN à le rechercher. Le client doit connaître l’étiquette, décider d’envoyer la requête et agir selon ce qui revient, et le DNS ne peut pas fournir les deux premiers éléments. La plupart des plans SRV ratés sont donc des problèmes de client déguisés en DNS. Lisez d’abord le comportement de découverte du client, puis ne publiez que l’étiquette qu’il interroge réellement.

Un enregistrement que personne n’interroge ne peut aider personne

SRV publie l’emplacement d’un service ; il ne l’annonce pas. Rien ne pousse un enregistrement vers un client, et aucun résolveur ne propose un nom qu’on n’a jamais demandé. La recherche commence quand l’application décide de la faire, donc l’étiquette doit venir de la documentation du produit ou de l’observation du logiciel sur le réseau. Là où le client n’a pas d’étape de découverte, un enregistrement change la zone et rien d’autre.

C’est pourquoi un produit sur un réseau peut se mettre à fonctionner tandis qu’un autre n’est pas affecté par le même changement. La variable est le logiciel, et le serveur DNS fait exactement ce qu’on lui a dit. Relisez la zone après la modification, car une étiquette mal saisie se cache facilement parmi des enregistrements qui se ressemblent tous.

Lisez les champs avant de les écrire

Un enregistrement porte quatre valeurs, et chacune répond à une question différente : la priorité ordonne les cibles qu’un client peut essayer, le poids répartit la charge entre cibles de même priorité, le port nomme le port de transport et la cible nomme l’hôte. La spécification autorise aussi une cible de . pour signifier que le service est délibérément indisponible, ce qui est une réponse utile et non une réponse cassée.

Aucun de ces champs ne porte d’identifiants, de politique de certificat ou de version d’application, et un client qui ignore le poids se connecte quand même, simplement sans l’équilibre prévu. La cible a besoin de ses propres enregistrements d’adresse, et elle devrait être un nom canonique plutôt qu’un alias. Publier un enregistrement qui pointe vers un hôte sans aucun récepteur produit une erreur de connexion qui se lit comme une panne DNS, et c’est le type de tromperie le plus coûteux. Publiez toute la chaîne ou rien de celle-ci.

Trouvez l’étiquette que le client envoie réellement

Établissez l’étiquette à partir de preuves plutôt que d’une supposition sur le nom du produit. Soit la documentation indique le nom du service, soit une capture montre la requête qui quitte le client au démarrage. Les deux voies aboutissent au même endroit : un nom et un type exacts à tester contre le résolveur.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

Comparez la réponse à l’enregistrement que vous avez publié, caractère par caractère, car les soulignés et le point final font partie du nom. Une réponse vide à une requête réellement envoyée désigne la zone, tandis qu’aucune requête du tout désigne le client, et ces constats vous envoient vers des équipes différentes. Une vraie réponse ressemble à la ligne ci-dessous, où la priorité 20 perd contre tout enregistrement de priorité inférieure et le client compose le port 8443 sur la cible indiquée.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

La cible doit aussi exister

Une cible qui se résout n’est pas la même chose qu’un service qui répond. Vérifiez les enregistrements d’adresse de la cible, puis vérifiez que quelque chose écoute sur le port et le protocole publiés. Un enregistrement TCP pointant vers un récepteur uniquement UDP est une incohérence qu’aucune édition de zone ne répare. Gardez le TTL court tant que la cible bouge, et allongez-le quand le nom cesse de bouger.

Les clients qui implémentent réellement la découverte varient dans la part de l’enregistrement qu’ils respectent. Certains n’utilisent que la priorité, d’autres traitent le poids comme un conseil, et quelques-uns ignorent le port et supposent une valeur par défaut. Ces différences ont leur place dans vos notes à côté de l’étiquette, car elles expliquent un comportement qui ressemble sinon à une panne du résolveur.

La découverte n’est pas une authentification

Une réponse SRV dit où se connecter, et elle ne dit rien sur qui croire une fois arrivé. Laissez la validation de certificat et les contrôles d’identité du serveur du client exactement comme ils étaient, car un enregistrement que quelqu’un d’autre peut falsifier ne devrait pas devenir une décision de confiance. Les réponses DNS sont mises en cache et modifiables par celui qui contrôle la zone, ce qui en fait un mauvais endroit pour coder une politique.

Pour un client sans prise en charge de la découverte, distribuez le profil ou l’URL de passerelle qu’il accepte, et notez quel produit utilise quelle méthode. Cette note empêche l’administrateur suivant d’ajouter un enregistrement et de s’attendre à ce qu’il fonctionne partout. La spécification SRV décrit la sélection entre cibles, et la lire comme un mécanisme d’autorisation est la façon dont un enregistrement utile devient une hypothèse de sécurité. Publiez à dessein, nommez l’étiquette dans votre documentation et traitez le client comme le composant qui décide si tout cela compte.