Effectuer une découverte de service

Article
08/09/2023

Les applications de haut niveau sur Azure Sphere peuvent effectuer une découverte de service à l’aide de la découverte de service DNS (DNS-SD). Les applications peuvent utiliser la découverte de service pour rechercher des services réseau et effectuer la résolution de noms d’hôte afin qu’elles puissent interagir avec le service via le pare-feu Azure Sphere. Le DNS de multidiffusion (mDNS) peut également être utilisé pour effectuer une découverte d’égal à égal sur un réseau local, ce qui est particulièrement utile lorsque les adresses IP et les noms d’hôte du point de terminaison de destination ne sont pas connus au moment de la conception.

Les applications utilisent des requêtes DNS-SD pour récupérer des enregistrements DNS à partir de serveurs DNS non locaux ou via un lien de multidiffusion. Si le nom interrogé se trouve sous le domaine de premier niveau local ( TLD), la requête est multidiffusion sur le réseau local via toutes les interfaces réseau activées ; sinon, la découverte du service de monodiffusion est effectuée. L’exemple De découverte de service montre comment effectuer une découverte de service sur Azure Sphere.

Note

Le pare-feu Azure Sphere empêche les applications de communiquer avec des services non autorisés. Toutefois, l’autorisation des connexions sortantes vers des TLD .locaux dans le manifeste de l’application peut augmenter le risque de sécurité pour un appareil en autorisant une application à se connecter à des services non autorisés publiés sur le réseau local. Les applications doivent autoriser uniquement les connexions sortantes vers des TLD .locaux dans des environnements sécurisés qui empêchent des parties non autorisées de publier des services. Pour fournir une protection supplémentaire dans ce scénario, Azure Sphere exige que les services découverts sur le réseau local résident également sur le sous-réseau local.

Inclure des fichiers d’en-tête

Les applications qui effectuent la découverte de service doivent inclure le fichier d’en-tête de résolution :

 #include <resolv.h>

Autoriser une connexion de service

Avant d’effectuer une requête DNS-SD, vous devez ajouter le service à la fonctionnalité AllowedConnections du manifeste d’application. Le pare-feu Azure Sphere permet ensuite à l’application de se connecter aux instances de service découvertes à l’aide de leurs noms d’hôte et adresses IP associés. Si un service TLD .local est spécifié, le pare-feu autorise uniquement les connexions aux ressources découvertes sur le sous-réseau local.

Les types de noms de service suivants sont pris en charge dans la fonctionnalité AllowedConnections :

Nom du service DNS local, tel que « _sample._tcp.local »
Nom de service DNS non local, tel que « _sampleinstance._tcp.dns-sd.org »
Nom de instance du service local, par exemple « _sampleinstance._tcp.hostname.local »
Nom de domaine, tel que « samplehost.contoso.com »
Adresse IP

Voici un extrait d’un manifeste d’application qui inclut un nom de service non local.

"AllowedConnections": [ "_http._tcp.dns-sd.org" ]

Effectuer une requête DNS-SD

Pour effectuer une requête DNS-SD, vous devez demander plusieurs types d’enregistrements DNS :

Enregistrements PTR qui énumèrent les instances d’un service DNS.
Enregistrements SRV et TXT qui contiennent les détails des instances de service, tels que le nom d’hôte et le port.
Enregistrements qui contiennent les adresses IP des noms d’hôte récupérés.

Avant d’envoyer la requête, vous devez la créer et l’initialiser, puis ajouter un message de requête qui demande l’enregistrement DNS. Vous pouvez créer et initialiser une requête DNS-SD en appelant la fonction POSIX res_init(). Vous pouvez créer un message pour la requête en appelant la fonction POSIX res_mkquery().

Envoyer une requête DNS monodiffusion

Lors de la découverte du service de monodiffusion, vous pouvez envoyer la requête DNS-SD et récupérer la réponse en appelant la fonction POSIX res_send().

Envoyer la requête via un lien de multidiffusion

Pour envoyer une requête DNS-SD via un lien de multidiffusion, l’application doit ouvrir un socket et envoyer la requête sur le socket à l’adresse IP de bouclage 127.0.0.1 (port de destination 53). Une fois la demande envoyée, plusieurs réponses peuvent être retournées. L’application doit attendre et écouter pendant plusieurs secondes pour collecter toutes les réponses. Cela est illustré dans l’exemple De découverte de service.

Important

Cette adresse IP de bouclage est une fonctionnalité bêta qui sera mise hors service, puis remplacée dans les versions ultérieures. Il s’agit d’un changement cassant pour les applications qui s’appuient sur l’adresse.

Connexions autorisées pour les hôtes avec plusieurs adresses IP

Le pare-feu Azure Sphere autorise uniquement les connexions à une adresse IP par nom d’hôte. Si un hôte a plusieurs adresses IP, le pare-feu Azure Sphere autorise uniquement les connexions à l’une des adresses. Une application peut utiliser curl pour envoyer des requêtes HTTPS à un hôte qui a plusieurs adresses IP ; curl tente de se connecter à chaque adresse IP jusqu’à ce que l’adresse autorisée soit trouvée. Toutefois, cela peut entraîner un délai pendant que l’application trouve l’adresse autorisée.