[mdns] probing not performed for Host (AAAA) records when using mDNSResponder library

[EskoDijk]

Describe the bug A clear and concise description of what the bug is.

This issue may not need an immediate fix: some discussion about feasibility, and pros/cons is also ok. Still I wanted to make people aware of this.

When the Advertising Proxy registers a new host (with AAAA records) via the mDNSResponder library, probing for the (new) host name is not performed on the AIL. Normally, mDNS does perform probing for the host name, to ensure it's not already in use somewhere on the AIL. And that's required by the mDNS RFC as well.

The issue here is that we use mDNSResponder in a special way: as a proxy to other device's host records. If mDNSResponder is used in a normal way (only advertising records/services for a device itself) then the mDNSResponder library will automatically add and probe host records (A/AAAA) for the present host.

But in our case, that can't be used, so the code (see below) explicitly adds the proxied host records.

(mdns_mdnssd.cpp)

        dnsError = DNSServiceRegisterRecord(GetPublisher().mHostsRef, &recordRef, kDNSServiceFlagsShared,
                                            kDNSServiceInterfaceIndexAny, MakeFullHostName(mName).c_str(),
                                            kDNSServiceType_AAAA, kDNSServiceClass_IN, sizeof(address.m8), address.m8,
                                            /* ttl */ 0, HandleRegisterResult, this);

The key point is the kDNSServiceFlagsShared flag here: this is needed because we want to add multiple AAAA records. And these records must not conflict with one another - multiple are allowed. However, this flag also suppresses probing on the AIL for the host name. This means a conflict on AIL is not detected.
This causes a certification test (2.14) to fail, because that was designed to check conflict detection.

A related problem to this is the timing order of mDNS messages on the AIL:

• It's observed that the Host (AAAA) records are already sent before the probing starts for adding the service.
• This could mean that e.g. if the mDNS service registration fails on AIL, the Host (AAAA) records were already registered bluntly without probing, which maybe should not have been done then.

To Reproduce Information to reproduce the behavior, including:

1. Git commit id - any recent
2. IEEE 802.15.4 hardware platform - e.g. OTBR reference release
3. Build steps
4. Network topology - cert test SRP-2.14

Expected behavior A clear and concise description of what you expected to happen.

In general: OTBR performs probing for an SRP-registered host name; and denies the SRP registration with YXDOMAIN error if the name already exists on the AIL.

But, for Matter devices: for Matter devices, it can be actually beneficial to not probe. They already pick a unique hostname by design. If probing were enabled, we would see more "false positives" due to probing, in case the Matter client was also previously registered at another OTBR and now changed to register to a new OTBR on the same AIL. So in case we fix this, we should also discuss the effect on Matter devices.

Possible solutions:

• Wait until an updated mDNSResponder appears with more complete support for SRP & Advertising Proxy situations like this one. E.g. request Apple to add functions for this.
• Try to first register the Host's KEY record on the AIL, which is unique. If that succeeds, then register the AAAA records with the flag kDNSServiceFlagsShared after that. If it fails, don't register the AAAA records at all.

Console/log output If applicable, add console/log output to help explain your problem.
PCAP is available if needed.

Additional context Add any other context about the problem here.
Cert test SRP-2.14.
Details of the mDNSResponder API were discussed with Apple.

[abtink]

Thanks @EskoDijk for the detailed description and analysis.

This seems to be applicable to the architecture where the platform layer implements the Advertising Proxy functionality. This is a model that we should strategically aim to move away from.

Our goal should be use the native OpenThread Advertising Proxy, which supports two flexible mDNS backends:

• The OT native mDNS implementation.
• A platform-provided mDNS library (like mDNSResponder) integrated via the otPlatDnssd platform APIs.

---

Try to first register the Host's KEY record on the AIL, which is unique. If that succeeds, then register the AAAA records with the flag kDNSServiceFlagsShared after that. If it fails, don't register the AAAA records at all.

This is the behavior that is already implemented and supported in the native OpenThread Advertising Proxy. The key records for the host and service instances are always registered.

The ot-br-posix methods to register KEY record use the kDNSServiceFlagsUnique flag in mDNSResponder API, which should ensure probing is performed before:

ot-br-posix/src/mdns/mdns_mdnssd.cpp

Lines 713 to 720 in 671eac3

	dnsError = GetPublisher().CreateSharedHostsRef();
	VerifyOrExit(dnsError == kDNSServiceErr_NoError);
	dnsError = DNSServiceRegisterRecord(GetPublisher().mHostsRef, &mRecordRef, kDNSServiceFlagsUnique,
	kDNSServiceInterfaceIndexAny, MakeFullKeyName(mName).c_str(),
	kDNSServiceType_KEY, kDNSServiceClass_IN, mKeyData.size(), mKeyData.data(),
	/* ttl */ 0, HandleRegisterResult, this);
	VerifyOrExit(dnsError == kDNSServiceErr_NoError);

---

Generally, I suggest prioritizing the use of OpenThread's native mDNS implementation. This gives us full control over the behavior and avoids the integration risks and potential behavioral discrepancies that can arise from the use of third-party libraries.

[EskoDijk]

@abtink Thanks, helpful to know for looking at the codebase! So best to focus on the model we want to move towards. So it seems the reference OTBR should then update its build flags to use the OT Core Advertising Proxy. Current flags are set here:

https://github.com/openthread/ot-reference-release/blob/d2a362e94f2cd29ed196cb1e2383a15999f9eb18/script/otbr-setup.bash#L82-L98

Which should then contain -DOTBR_SRP_ADV_PROXY=ON instead, I think?

I'm assuming for now that implementers (for whatever reason!) still would like to use the mDNSResponder platform service in the OTBR. Maybe that's not the right model, but for sure it has an enormous amount of complex code to ensure correct operation and is well-tested over the years.

When tracing the code from the OT core SRP advertising proxy for publishing a host I arrive at this code: otbrError PublisherMDnsSd::PublishHostImpl(const std::string &aName, const AddressList &aAddresses, ResultCallback &&aCallback).
This will then call otbrError PublisherMDnsSd::DnssdHostRegistration::Register(void). Which then makes the call to mDNSResponder with the flag kDNSServiceFlagsShared which caused the problem. So AAAA records are still not probed, then.

And the registration of the KEY record: I do see in the proxy code that the KEY record is registered first, and probed:

https://github.com/openthread/openthread/blob/1662ca8001f11218a32d9e5095249f2dbfc63c93/src/core/net/srp_advertising_proxy.cpp#L500

Now the problem here is, that this probing is started "in the background", so could take a while to complete successfully or unsuccessfully. We don't know yet at this point. Meanwhile the host registration is already started immediately in the code a few lines later:

https://github.com/openthread/openthread/blob/1662ca8001f11218a32d9e5095249f2dbfc63c93/src/core/net/srp_advertising_proxy.cpp#L509

Because this is not probed, the Host AAAA records are sent much quicker than the KEY/service records which are being probed. So before anything gets probed, the Host AAAA records are already wrongly "claimed" on the AIL. While it should wait doing this, until the host name probe has been successful. Note that the probe message ideally should be a query for "ANY" records of the name to be claimed. If any record at all exists on that name (even if it's not a KEY or AAAA record), then a new name needs to be picked in mDNS.

(Btw a related consideration is Matter devices: if host probing is skipped, then this may be actually good for Matter devices that already pick a unique name by design. Fixing probing may introduce new problems e.g. conflict with own prior registrations.)

Generally, I suggest prioritizing the use of OpenThread's native mDNS implementation. This gives us full control over the behavior and avoids the integration risks and potential behavioral discrepancies that can arise from the use of third-party libraries.

This is a good point - maybe that could be the focus point for OT support. Then the ot-reference-release also has to use this. To be discussed with the implementers.

[abtink]

@EskoDijk , Yes. I think this is a problem with the ot-br-posix implementation of RegisterHost (when using mDNSResponder), and I think it needs to be fixed regardless of the architecture used.

From an OT core perspective, otPlatDnssdRegisterHost() is used to register host addresses, and it is expected that it would do the mDNS probing.

Ideally, the mDNSResponder API should provide a way to distinguish between a record name that is allowed to be answered by different hosts (e.g., a PTR record) and a record name that is owned by a single device/host while allowing it to register multiple records.

Fixing probing may introduce new problems e.g. conflict with own prior registrations.)

I agree. This can be a concern.

Generally, the underlying mDNS implementation should be able to handle cases where multiple record types are registered under the same name. For example, we are adding SRV and TXT records for the same name when registering a service, which we expect to be handled correctly by the mDNS implementation performing the same probe for both registrations.

I know that OT's native mDNS implementation will handle this properly.

---

From the OT core Advertising Proxy perspective, all registration requests (from the same SRP update) are started in parallel. If anything fails, it then cleans up after itself by removing any previous requests.

[EskoDijk]

@abtink

Generally, the underlying mDNS implementation should be able to handle cases where multiple record types are registered under the same name. For example, we are adding SRV and TXT records for the same name when registering a service, which we expect to be handled correctly by the mDNS implementation performing the same probe for both registrations.

Correct, mDNSResponder also does this. The problem for A/AAAA is that we have multiple records on the same name, of the same type. mDNSResponder does handle this internally for a "classic" own host name publication on mDNS, including probing. But when calling the "register" API on arbitrary other records, that doesn't work - there are only 2 choices:

• Register with "unique" flag - probing is done, but you can't register multiple AAAA records for the same name.
• Register with "shared" flag - you can register multiple AAAA records for a name, but no probing is done.

This is at least the case when the classic mDNS APIs of mDNSResponder are used. It seems to also have code for more recent situations like SRP and AdvProxy, but I haven't looked at whether there are APIs for those that would fit better to our use case.

From the OT core Advertising Proxy perspective, all registration requests (from the same SRP update) are started in parallel. If anything fails, it then cleans up after itself by removing any previous requests.

In principle it could still register its host name even if the service fails to register? It doesn't hurt to have the host registered. And maybe the application would try to register another service (with another name), and then the host part doesn't need to be done again.

So the problem with all in parallel is that with mDNSResponder at least, it doesn't probe when registering the AAAA records with "shared" flag. So while the rest of records are still in probing state, the damage is already done - a name conflict.