OpenThread DNS Service Discovery only every returns one result (through otDnsClientBrowse()), how how to get all results on the network?

[kkufalk1]

On the device we're developing (small battery powered nRF52840 sensor tag, Thread Sleepy End Device usinc NCS v2.7.0), when trying to discover DNS services using the otDnsClientBrowse(), it only ever returns one result even if multiple are on the network. On my test network, the tag can both services on the network but appears to only return the first one it finds. In the attached screenshot, you can see the CLI example code from the v3.2.2 SDK seeing both services on the network, but only returning one at a time.

I setup a sniffer, and the border router only returns one entry per request. (Unsure how to attach a packet capture here, refer to the thread on Nordic's devzone if you want to see it: https://devzone.nordicsemi.com/f/nordic-q-a/127157/openthread-dns-service-discovery-only-every-returns-one-result-how-to-get-all-results-on-the-network/562085)

This can be worked around by calling otDnsClientBrowse() multiple times, this however isn't deterministic or efficient. Is there a way to do a browse that returns all of the available services on the network? Here's the browse done on my dev machine using Avahi for reference.

[abtink]

@kkufalk1, thanks for the detailed question.

The behavior you are seeing is actually the expected behavior. The key point to understand here is the difference between how otDnsClientBrowse() operates on a Thread node (using a unicast DNS query) versus how multicast DNS (mDNS) tools like Avahi operate.

When you use otDnsClientBrowse(), the device sends a standard unicast DNS query to a DNS server/resolver (which is typically a Thread Border Router on the mesh acting as a Discovery Proxy). It is important to note that this API does not perform a continuous Multicast DNS (mDNS) query.

Because standard unicast DNS is a request/response protocol (unlike mDNS, which is a continuous multicast subscription model), the Border Router's Discovery Proxy issues the mDNS query on the infrastructure link on the node's behalf. As soon as the proxy discovers the first result, the Border Router packages that into a unicast DNS response and sends it back to the Thread device to resolve the query. It does not hold the connection open to wait for all possible slow-responders on the network.

In contrast, Avahi uses multicast DNS directly.

References for this behavior:

This is covered in the Thread Specification. Section 14.3.4 ("Requirements for Servers hosting a Service Registry") states:

If a Service Registry with its Discovery Proxy enabled receives a standard (plain) DNS query from a Thread Device on its Thread Network, in a domain for which the local DNS Authoritative Server and/or the Discovery Proxy is authoritative, then the Service Registry SHOULD respond immediately if 1 or more matching answer records are locally available (e.g. cached, or in the local DNS database). This follows the rules for responding to standard DNS queries as defined in Section 5.6 of [RFC 8766] for the Discovery Proxy.

Here is the relevant excerpt from RFC 8766 (Discovery Proxy for Multicast DNS-Based Service Discovery) Section 5.6:

As soon as any Multicast DNS response packet is received that contains one or more positive answers to that question (with or without the Cache Flush bit [RFC6762] set) or a negative answer (signified via a Multicast DNS NSEC record [RFC6762]), the Discovery Proxy generates a Unicast DNS response message containing the corresponding (filtered and translated) answers and sends it to the remote client.

Another place to look is the Thread Specification, Section 14.3.5.3 ("Discovering Services"):

A Thread Device may choose which discovery mechanism to use based on specific application needs. There is a tension between using UDP for discovery and using DNS Push Notifications for discovery: one is very lightweight, while the other requires additional work.

DNS transactions are simple queries that receive a single response. DNS Push Notifications are a subscription service: the device performing service discovery connects to the DNS Push Notification server and subscribes to answers to one or more DNS questions.

In some cases, an attempt to discover services is not concerned with which service it finds—any instance of a particular requested service type will suffice. In other cases, the service discovery operation may be intended to capture a complete list of all instances of a particular service type. In particular cases, a discovery process will monitor the set of instances of a particular service type over time.

Please note that the DNS Push mechanism is not supported/implemented in OpenThread for either device side or on Border Routers (although an implementation of DSO (DNS Stateful Operations) does exist - intended for another use-case). Contributions from interested parties are always welcome!

[kkufalk1]

Likewise, thank you for the detailed response! I'll talk with my team and see what direction we want to go