[srp] implement AdvertisingProxy and define Dnssd platform APIs

[abtink]

This commit adds a generic SRP Advertising Proxy implementation to OpenThread core, which uses a set of newly defined otPlatDnssd platform APIs for DNS-SD (mDNS) support on infrastructure network on a Border Router.

Srp::Server provides ServiceUpdateHandler callback mechanism that allows platforms to implement their own advertising proxy function. While this is still supported, the new generic advertising proxy implementation makes it easier to port and support the proxy function on new platforms. The platform needs to provide the DNS-SD platform APIs, which are designed to be simple and easy to implement.

The AdvertisingProxy directly interacts with Srp::Server and its registered Host and Service entries, tracking whether an entry has been successfully advertised, is currently being advertised, or has been replaced by a new registration.

The AdvertisingProxy ensures that consecutive SRP updates for the same host or service are committed on the server in the order they are received, even if their advertisements are finished in a different order. This is important for SRP Replication support, as the server may receive a large number of SRP updates back-to-back for the same host.

The AdvertisingProxy will also register key records for SRP host and service instance names. This will keep the claim on the name of a removed entry while its key lease is not expired. It is also used when an SRP host registration has no off-mesh routable address.

This commit adds a detailed unit test test_srp_adv_proxy that validates the AdvertisingProxy under many scenarios. The test covers a range of cases, including delayed registration callbacks and timeouts, new registrations replacing outstanding advertisements, platform DNS-SD state changes and failures, host address changes adding/removing OMR addresses.

---

This PR currently contains the commit from #9208.

[size-report]

Size Report of OpenThread

Merging #9268 into main(905a22e).

name	branch	text	data	bss	total
ot-cli-ftd	main	464768	760	66284	531812
	#9268	464768	760	66284	531812
	+/-	0	0	0	0
ot-ncp-ftd	main	434860	760	61496	497116
	#9268	434860	760	61496	497116
	+/-	0	0	0	0
libopenthread-ftd.a	main	234090	0	40230	274320
	#9268	234090	0	40230	274320
	+/-	0	0	0	0
libopenthread-cli-ftd.a	main	56861	0	8075	64936
	#9268	56861	0	8075	64936
	+/-	0	0	0	0
libopenthread-ncp-ftd.a	main	31855	0	5916	37771
	#9268	31855	0	5916	37771
	+/-	0	0	0	0
ot-cli-mtd	main	363912	760	51180	415852
	#9268	363912	760	51180	415852
	+/-	0	0	0	0
ot-ncp-mtd	main	346572	760	46408	393740
	#9268	346572	760	46408	393740
	+/-	0	0	0	0
libopenthread-mtd.a	main	157460	0	25142	182602
	#9268	157460	0	25142	182602
	+/-	0	0	0	0
libopenthread-cli-mtd.a	main	39720	0	8059	47779
	#9268	39720	0	8059	47779
	+/-	0	0	0	0
libopenthread-ncp-mtd.a	main	24735	0	5916	30651
	#9268	24735	0	5916	30651
	+/-	0	0	0	0
ot-cli-ftd-br	main	533152	768	130964	664884
	#9268	533280	768	130964	665012
	+/-	+128	0	0	+128
libopenthread-ftd-br.a	main	297075	5	104886	401966
	#9268	297203	5	104886	402094
	+/-	+128	0	0	+128
libopenthread-cli-ftd-br.a	main	70494	0	8099	78593
	#9268	70494	0	8099	78593
	+/-	0	0	0	0
ot-rcp	main	62232	564	20604	83400
	#9268	62232	564	20604	83400
	+/-	0	0	0	0
libopenthread-rcp.a	main	9534	0	5052	14586
	#9268	9534	0	5052	14586
	+/-	0	0	0	0
libopenthread-radio.a	main	18815	0	214	19029
	#9268	18815	0	214	19029
	+/-	0	0	0	0

[codecov]

Codecov Report

Attention: 632 lines in your changes are missing coverage. Please review.

Comparison is base (905a22e) 79.75% compared to head (7bec257) 77.19%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9268      +/-   ##
==========================================
- Coverage   79.75%   77.19%   -2.57%     
==========================================
  Files         529      562      +33     
  Lines       73423    80392    +6969     
==========================================
+ Hits        58562    62062    +3500     
- Misses      14861    18330    +3469     

Files	Coverage Δ
src/core/border_router/infra_if.cpp	90.90% <100.00%> (+47.83%)	⬆️
src/core/common/heap_data.hpp	100.00% <ø> (ø)
src/core/instance/instance.cpp	97.90% <ø> (-0.10%)	⬇️
src/core/net/srp_server.hpp	83.33% <100.00%> (-8.34%)	⬇️
tests/unit/test_platform.cpp	41.08% <ø> (+4.04%)	⬆️
tests/unit/test_srp_adv_proxy.cpp	100.00% <100.00%> (ø)
src/core/instance/instance.hpp	39.86% <66.66%> (-4.43%)	⬇️
src/core/net/dns_types.hpp	98.83% <0.00%> (-0.60%)	⬇️
src/core/net/dnssd.hpp	83.33% <83.33%> (ø)
src/core/net/srp_advertising_proxy.hpp	22.22% <22.22%> (ø)
... and 4 more

... and 356 files with indirect coverage changes

[wgtdkp]

This commit adds a detailed unit test test_srp_adv_proxy that validates the AdvertisingProxy under many scenarios. The test covers a range of cases, including delayed registration callbacks and timeouts, new registrations replacing outstanding advertisements, platform DNS-SD state changes and failures.

Thanks @abtink ! It's really important but missing in OTBR!

[abtink]

The new commit makes large changes to the implementation:

• It adds new otPlatDnssd APIs to register and unregister key records.
• These APIs are used by AdvertisingProxy to keep the claim on the name of a removed host or service while its key lease is not expired.
• They are also used when an SRP host registration has no off-mesh routable address (when the host and its services are un-advertised).
• The unit test is updated to validate the key registration behavior.
• A new detailed test case is added that covers host changing its addresses (adding/removing off-mesh routable address).
• Another new test case is added that covers corner cases where an outstanding advertisement is removed before it is committed.
• Common code patterns used in AdvertisingProxy are now defined as template methods, which are then used for Host or Service types (simplifying the code and removing repeated patterns).

[abtink]

In the new push, the implementation was updated to change how registrations are handled when the SRP client only includes mesh-local/link-local addresses. In the previous model, such services were not advertised on the AIL. In the new model, services are still advertised on the AIL, but without any addresses. This means that the service (SRV/TXT record) can be seen and queried on the AIL, but there will be no AAAA records for the hostname. This change is related to discussions in SPEC-1211. For now, I kept the new changes as a separate commit in this PR (will later squash them into one). (the new diff changes can seen in commit aa5cf05).

[superwhd]

Looks great, thanks!

[wgtdkp]

Hi @abtink , what's your plan on this PR as well as openthread/ot-br-posix#2042? I suppose you still want to check in the two changes, but both are conflicted now.

[abtink]

Hi @abtink , what's your plan on this PR as well as openthread/ot-br-posix#2042? I suppose you still want to check in the two changes, but both are conflicted now.

I'd like to wait till we have the new PR on mDNS in OT core up and then update this to work with new APIs defined by it.
We keep the option of platform providing mDNS but want to make sure the API definitions are aligned.

[abtink]

Rebased on main. We can move with final review and merge of this.

[wgtdkp]

Thanks abtink 👍
This is really a great work!
Especially the comprehensive tests in tests/unit/test_srp_adv_proxy.cpp are what missing in ot-br-posix. I think we will deprecate the impl in ot-br-posix once this is merged.

[superwhd]

I just read RFC3445 Section 3 and found it's violating the following statement.

In the flags field, all bits except bit 7 are reserved and MUST be
   zero.  If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone
   key.  If Bit 7 is set to 0, the KEY is not a zone key.  SIG(0)/TKEY
   are examples of DNSSEC keys that are not zone keys.

Here kSignatoryFlagGeneral is 1 at the 16th bit.

I wonder if there's a following RFC that allows setting 1s at bits other than the 7th bit?

[abtink]

This is following the same flags and format as in key RR used by SRP (e.g. in SRP client or checked in SRP server). Here we are just re-constructing the key RR that SRP sever got from client.

Regarding registering key on mDNS in adv-proxy, its purpose is to keep the claim to them name the record data is not really important. There were discussions of even allowing empty record data for it.

[Vyrastas]

Copyedit nits for the API, everything else looks good

[Vyrastas]

are used only when --> is only available for use when

[abtink]

Thanks I changed it to "APIs are used".

Since these are platform APIs, we expect platform to provide them and we (OT stack) will use them and we want to document under which build config these APIs are used by the OT stack.