Résumé

  • Le projet individuel de Changshan Su propose une annonce DNS-SD locale pour trouver des passerelles d’IA et décrire leurs chemins et capacités.
  • Il nomme le service découvert « point de terminaison candidat » : la confiance doit précéder toute requête et tout envoi d’identifiants.

Un ordinateur peut trouver une imprimante sans lui laisser imprimer sur le compte d’autrui. Avec un client d’IA, le raccourci coûte plus cher : la machine découverte peut recevoir la clé qui paie chaque requête. Qui la lui remet ?

Le 26 octobre 2026, Changshan Su a soumis la version 00 de « DNS-Based Service Discovery for AI Gateways » sous la forme d’un Internet-Draft individuel. Le Datatracker le classe comme proposition individuelle, sans flux RFC ni statut RFC visé. Le nom de service _ai-gateway._tcp est proposé ; le document indique qu’il n’a pas encore d’attribution IANA.

Le mécanisme de base est connu. DNS-Based Service Discovery utilise un enregistrement PTR pour énumérer une instance, SRV pour indiquer son hôte et son port TCP, TXT pour des données propres au service, puis A ou AAAA pour l’adresse de l’hôte. Su ajoute un vocabulaire compact pour le chemin de montage, la sécurité du transport, l’exigence d’authentification et les protocoles annoncés. Le client peut ainsi lire ce que le service prétend offrir sans inscrire une adresse fixe dans sa configuration.

La place est comptée : le projet vise moins de 200 octets dans le TXT par défaut et plafonne l’ensemble à 400. Une annonce peut porter un nom, un port, un chemin et quelques affirmations. Quatre cents octets n’en font pas une autorité ; en ajouter ne donnerait pas davantage de mandat à la machine qui les publie.

Le document choisit un terme révélateur : « point de terminaison candidat ». Le client a analysé un enregistrement ; il n’a pas encore fait confiance à la machine ni autorisé l’envoi d’identifiants. La séquence proposée est simple : parcourir les services, résoudre l’adresse, valider les données, se connecter, confirmer la confiance, puis envoyer une requête. La consultation d’un catalogue de modèles est facultative. Les clés restent hors du TXT.

Cette séquence compte parce qu’un réseau local permet à des machines d’annoncer leur présence ; il ne tient pas audience pour décider lesquelles peuvent dépenser le secret d’autrui. Le projet dit qu’un participant au même segment peut forger une annonce mDNS, déclarer auth=0 ou diriger SRV vers un hôte qu’il contrôle. L’identifiant annoncé n’est pas un justificatif d’identité. Le client doit s’appuyer sur la confirmation de l’utilisateur, une règle de confiance préconfigurée ou la vérification de l’identité TLS du serveur.

Une clé API réutilisable ne doit pas circuler en HTTP ou WebSocket en clair sans accord explicite pour cet environnement local. Une nouvelle annonce en clair ne doit pas rétrograder une passerelle déjà approuvée en HTTPS ou WSS.

RFC 6763 donne à DNS-SD un métier précis : découvrir des instances nommées d’un service. RFC 6762 décrit mDNS sur le lien local et rappelle que la résolution des conflits de noms suppose des participants coopératifs. Aucun de ces mécanismes ne donne à la machine découverte le droit de dépenser les identifiants du client. Une sonnette peut annoncer « passerelle ici ». Elle ne choisit pas qui entre ; le détenteur de la clé garde cette décision.

La séparation utile est donc nette. La découverte localise. L’identité TLS aide à établir quel serveur répond. La règle du client décide si ce serveur peut recevoir un secret. Fusionner les trois dans une lumière verte « trouvé » transformerait une entrée d’annuaire en autorisation. Le projet rend la décision supplémentaire visible, là où l’utilisateur ou l’administrateur peut la fixer.

Le Datatracker montre un projet individuel -00. Il ne fournit ni résultat d’interopérabilité, ni comparaison d’implémentations, ni chiffre de déploiement ; un rapport de test primaire changerait le jugement sur l’adoption. Pour l’instant, l’interface entre les trois décisions est le vrai sujet. Si le client demande une approbation, il doit montrer l’hôte, le port, le chemin, l’état TLS et la déclaration d’authentification concernés. « Passerelle trouvée » est un résultat de recherche. « Cette machine peut utiliser ma clé » est une décision d’autorisation.

Sources