[mdns] add native mDNS support in OT for host, service, key reg

[abtink]

This commit introduces native mDNS support within the OpenThread stack, implementing RFC 6762 compliant registration of hosts, services, and keys. It supports the following functionalities:

• Sending probes to claim names.
• Sending announcements on initial registration and changes.
• Sending "goodbye" announcements when unregistered or upon record removal.
• Negative responses (NSEC).
• Support for service sub-types and their addition/removal.
• Support for _services._dns-sd._udp queries (all service types).
• Responding to queries (including "QU" questions requesting unicast response).
• Delay mechanism when responding to multi-question query messages, for unique or shared records.
• Providing extra records in the Additional Data section if not already in the Answer section (e.g., on a PTR query, include SRV and host AAAA addresses).
• Implementing Known-Answer Suppression.
• Supporting multi-packet queries with known answers in follow-up messages.
• Rate-limiting record multicasts (once per second).
• Rate-limiting probe responses (once per 250ms).
• Detecting conflicts after probes.
• Limiting the size of emitted responses or probes, breaking into multiple messages if necessary.
• Detecting self originating messages (sent by mDNS module).

This commit introduces public otMdns OpenThread APIs and related CLI commands for the mDNS module. For platform abstraction, otPlatMdns APIs are defined in mdns_socket.h (e.g., to send or receive mDNS messages). Under the simulation platform, a simplified implementation of the otPlatMdns APIs is provided using posix socket (intended for testing).

This commit also adds a detailed test_mdns unit test, validating various functionalities and covering potential edge cases.

---

This PR is the first phase of adding native mDNS support in OT core adding support for registering entries. The next phase (in follow-up PR) will add support for service browsers and service/address resolvers.

Some functionalities are left for future enhancements/PRs:

• Legacy unicast query (source port not matching mDNS port)
• Direct unicast queries to mDNS port

[size-report[bot]]

Size Report of OpenThread

Merging #9797 into main(6de5cd8256d62b14bcc18b7f081d71411f8b942f).

name	branch	text	data	bss	total
ot-cli-ftd	main	467224	856	66364	534444
	#9797	467224	856	66364	534444
	+/-	0	0	0	0
ot-ncp-ftd	main	436140	760	61576	498476
	#9797	436140	760	61576	498476
	+/-	0	0	0	0
libopenthread-ftd.a	main	236166	95	40310	276571
	#9797	236258	95	40310	276663
	+/-	+92	0	0	+92
libopenthread-cli-ftd.a	main	57549	0	8075	65624
	#9797	57549	0	8075	65624
	+/-	0	0	0	0
libopenthread-ncp-ftd.a	main	31857	0	5916	37773
	#9797	31857	0	5916	37773
	+/-	0	0	0	0
ot-cli-mtd	main	364712	760	51220	416692
	#9797	364712	760	51220	416692
	+/-	0	0	0	0
ot-ncp-mtd	main	347244	760	46448	394452
	#9797	347244	760	46448	394452
	+/-	0	0	0	0
libopenthread-mtd.a	main	158229	0	25182	183411
	#9797	158321	0	25182	183503
	+/-	+92	0	0	+92
libopenthread-cli-mtd.a	main	39787	0	8059	47846
	#9797	39787	0	8059	47846
	+/-	0	0	0	0
libopenthread-ncp-mtd.a	main	24737	0	5916	30653
	#9797	24737	0	5916	30653
	+/-	0	0	0	0
ot-cli-ftd-br	main	536080	864	131076	668020
	#9797	549856	864	131196	681916
	+/-	+13776	0	+120	+13896
libopenthread-ftd-br.a	main	299619	100	104998	404717
	#9797	323013	100	105118	428231
	+/-	+23394	0	+120	+23514
libopenthread-cli-ftd-br.a	main	71212	0	8099	79311
	#9797	71212	0	8099	79311
	+/-	0	0	0	0
ot-rcp	main	62248	564	20604	83416
	#9797	62248	564	20604	83416
	+/-	0	0	0	0
libopenthread-rcp.a	main	9542	0	5052	14594
	#9797	9542	0	5052	14594
	+/-	0	0	0	0
libopenthread-radio.a	main	18870	0	214	19084
	#9797	18870	0	214	19084
	+/-	0	0	0	0

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 2.01681% with 583 lines in your changes are missing coverage. Please review.

Project coverage is 77.80%. Comparing base (b9dcdbc) to head (82ea698). Report is 1 commits behind head on main.

:exclamation: Current head 82ea698 differs from pull request most recent head 10e9fea. Consider uploading reports for the commit 10e9fea to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9797      +/-   ##
==========================================
- Coverage   81.87%   77.80%   -4.07%     
==========================================
  Files         565      568       +3     
  Lines       81087    82168    +1081     
==========================================
- Hits        66391    63934    -2457     
- Misses      14696    18234    +3538     

Files	Coverage Δ
examples/platforms/simulation/system.c	58.02% <100.00%> (-16.68%)	:arrow_down:
src/cli/cli.hpp	100.00% <ø> (ø)
src/cli/cli_mdns.hpp	100.00% <100.00%> (ø)
src/core/instance/instance.cpp	97.29% <ø> (-0.72%)	:arrow_down:
src/core/net/mdns.cpp	0.40% <ø> (ø)
tests/unit/test_mdns.cpp	100.00% <ø> (ø)
tests/unit/test_platform.cpp	41.08% <ø> (+4.04%)	:arrow_up:
src/cli/cli.cpp	76.60% <0.00%> (+4.38%)	:arrow_up:
src/core/instance/instance.hpp	95.86% <0.00%> (-1.66%)	:arrow_down:
src/core/net/dns_types.hpp	96.04% <0.00%> (+4.53%)	:arrow_up:
... and 5 more

... and 322 files with indirect coverage changes

[wgtdkp]

@abtink The OpenThread mDNS will ever be enabled on a Border Router, right? It's common that there is already platform mDNS server which is leveraged by multiple software components on a Border Router devices, so it will be hard for Thread vendors to transition to OpenThread mDNS. Is it expected that BRs will have two mDNS servers running simutaneously? Is this technically doable?

[abtink]

@abtink The OpenThread mDNS will ever be enabled on a Border Router, right?

Yes. Thread BR is the primary use-case.

It's common that there is already platform mDNS server which is leveraged by multiple software components on a Border Router devices, so it will be hard for Thread vendors to transition to OpenThread mDNS. Is it expected that BRs will have two mDNS servers running simutaneously? Is this technically doable?

Yes. It is possible to have more than one mDNS responder and/or querier implementation coexist on the same device. RFC 6762 - section 15 covers this.

---

Background on this PR:

OpenThread currently delegates mDNS functionality (including related adv-proxy and discovery-proxy functions) to the platform layer. We will continue to support this model.

Our goal is to provide native support for these functions within the OpenThread core stack, offering an alternative option for platforms and products.

Regarding mDNS function:

The current model delegates mDNS functionality to the platform layer. For the posix platform (in ot-br-posix), we define the otbr::Mdns::Publisher class as an abstraction layer. We also offer example integrations with mDNSResponder and Avahi, but platforms can choose other mDNS libraries.

Advantages of native support:

• Platform-agnostic: Native mDNS support within OpenThread would be usable across different platforms and operating systems.
• Improved reliability: A well-tested, Thread-specific mDNS implementation within OpenThread core could reduce issues related to BR service discovery that stem from platform-specific mDNS libraries.
• Faster feature development and adoption: Adding new mDNS features or behaviors (e.g., TSR record for conflict detection) would be streamlined with native support.

[alexeRadu]

Besides the unittests what other testing has been used to validate the mdns implementation?

[abtink]

Besides the unittests what other testing has been used to validate the mdns implementation?

@alexeRadu , the unit test validates operation under normal conditions and various edge cases.

Additionally, this PR provides an otPlatMdns platform API implementation under the simulation platform (using POSIX socket). This is enabled by OPENTHREAD_SIMULATION_MDNS_SCOKET_IMPLEMENT_POSIX, and allows OpenThread stack executables (built with the simulation platform) to run directly on standard machines (laptop/desktop), acting as an mDNS entity on the network. We've used this feature for manual testing and validation of OpenThread's mDNS implementation against others (primarily mDNSResponder on macOS via dns-sd commands). Wireshark was also used to capture and analyze the emitted mDNS messages.

Our long-term goal is add similar automated tests (as part of OpenThread CI), either leveraging OPENTHREAD_SIMULATION_MDNS_SCOKET_IMPLEMENT_POSIX or exploring new mechanisms.

Further contributions to the implementation's testing are always welcome. :)

[abtink]

New pushed commit (will be squashed later):

(to squash later) enhance simulation/mdns_socket.c
- Create IPv6 socket in addition to IPv4
- Send and receive mDNS messages on both IPv6 and IPv4
- Simplify logging and handling errors
- Implement `otPlatMdnsSendUnicast()`

[abtink]

The changes from the PR below are now included in the commit in this PR:

• https://github.com/openthread/openthread/pull/9935

[marius-preda]

HI @abtink, when do you think this PR will be merged? The mDNS implementation seems quite complete. We have tested it and it works ok in our setup. I see you are adding some other PRs connected to this, do you have more in the pipeline?

[abtink]

HI @abtink, when do you think this PR will be merged? The mDNS implementation seems quite complete. We have tested it and it works ok in our setup. I see you are adding some other PRs connected to this, do you have more in the pipeline?

Good to hear it's been validated in your setup. It would be helpful to mark the PR approved (and reviewed). Thanks.

There are some other PR building on to of this (some are squashed into this):

• https://github.com/openthread/openthread/pull/9935
• https://github.com/openthread/openthread/pull/9944
• https://github.com/openthread/openthread/pull/9954

Some other related ones in pipeline:

• Updating disc proxy to use the new native mDNS
• Adding APIs to iterate over active browsers, resolvers (and/or cache) - intended for testing/debugging.
• Later on we may add support for "Legacy unicast query (source port not matching mDNS port)" and "Direct unicast queries to mDNS port" (though these are lower priority).

[radua-nxp]

I've also checked on my side with several usecases and it seems that the patch is complete enough to be merged.

[Vyrastas]

@jrhodie can you review the documentation portion of this please.