Perform service discovery

  • Article

High-level applications on Azure Sphere can perform service discovery by using DNS service discovery (DNS-SD). Applications can use service discovery to find network services and perform host name resolution so they can interact with the service through the Azure Sphere firewall. Multicast DNS (mDNS) can also be used to perform peer-to-peer discovery on a local network, which is especially useful when the IP addresses and host names of the destination endpoint aren't known at design time.

Applications use DNS-SD queries to retrieve DNS records from non-local DNS servers or over a multicast link. If the name being queried is under the .local top-level domain (TLD), the query is multicast on the local network through all enabled network interfaces; otherwise, unicast service discovery is performed. The Service discovery sample demonstrates how to perform service discovery on Azure Sphere.

Note

The Azure Sphere firewall prevents applications from communicating with unauthorized services. However, allowing outbound connections to .local TLDs in the application manifest may increase the security risk to a device by allowing an application to connect with unauthorized services that are advertised on the local network. Applications should only allow outbound connections to .local TLDs in secured environments that prevent unauthorized parties from advertising services. To provide additional protection in this scenario, Azure Sphere requires that services that are discovered on the local network also reside on the local subnet.

Include header files

Applications that perform service discovery must include the resolv header file:

 #include <resolv.h>

Allow a service connection

Before you perform a DNS-SD query, you must add the service to the AllowedConnections capability of the Application manifest. The Azure Sphere firewall will then allow the application to connect to the discovered service instances using their associated host names and IP addresses. If a .local TLD service is specified, the firewall will only allow connections to discovered resources on the local subnet.

The following types of service names are supported in the AllowedConnections capability:

  • Local DNS service name, such as "_sample._tcp.local"
  • Non-local DNS service name, such as "_sampleinstance._tcp.dns-sd.org"
  • Local service instance name, such as "_sampleinstance._tcp.hostname.local"
  • Domain name, such as "samplehost.contoso.com"
  • IP address

Here's an excerpt from an application manifest that includes a non-local service name.

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

Perform a DNS-SD query

To perform a DNS-SD query, you need to request several types of DNS records:

  • PTR records that enumerate instances of a DNS service.
  • SRV and TXT records that contain details of the service instances, such as host name and port.
  • A records that contain the IP addresses of the retrieved host names.

Before you send the query, you need to create and initialize it, and then add a query message that requests the DNS record. You can create and initialize a DNS-SD query by calling the POSIX function res_init(). You can create a message for the query by calling the POSIX function res_mkquery().

Send a unicast DNS query

When performing unicast service discovery, you can send the DNS-SD query and retrieve the response by calling the POSIX function res_send().

To send a DNS-SD query over a multicast link, the application must open a socket and send the request over the socket to the loopback IP address 127.0.0.1 (destination port 53). After the request is sent, multiple responses may be returned. The application should wait and listen for several seconds to collect all responses. This is demonstrated in the Service discovery sample.

Important

This loopback IP address is a Beta feature that will be retired and then replaced in future releases. This will be a breaking change for applications that rely on the address.

Allowed connections for hosts with multiple IP addresses

The Azure Sphere firewall only allows connections to one IP address per host name. If a host has multiple IP addresses, the Azure Sphere firewall only allows connections to one of the addresses. An application can use curl to make HTTPS requests to a host that has multiple IP addresses; curl will try to connect to each IP address until the allowed address is found. However, this may cause a delay while the application finds the allowed address.