DNS-SD forwarding issue with multiple Thread Networks / OTBR on same Ethernet LAN

[NickMcKendree]

Hi,

I am in an office environment and for testing we may have multiple OTBR / isolated Thread Networks on the same LAN for testing and development. Just to reiterate, these are small separate networks, not redundant OTBR on the same Thread Network.

We are using SRP to advertise a local server running on the OTBR. This works well in normal use.

However, I discovered an issue when setting up a second OTBR / Network yesterday where:

• OTBR 1 was online
• OTBR 2 was setup - isolated Thread Network.
• OTBR 1 and 2 are on the same Ethernet LAN, on separate floors.
• An end device is added to OTBR Update README.md #2. It joins the network and starts DNS-SD discovery for the service. However, the OTBR returns an IP address not of its self but the address of OTBR 1.
• Obviously the end device cannot talk to OTBR 1 network.
• The DNS response has a short TTL of 10.

The only way to resolve this is to disconnect OTBR 1 and reboot OTBR 2 (OTBR 2 cache's OTBR 1 address and will keep serving it).

The behavior implies that the DNS query goes out over ETH0 and other OTBR respond before the local OTBR uses it's own registration.

I tried iptables and ip6tables to block DNS messages but these don't survive a reboot, it looks like otbr-agent overwrites the rules.

I tried to build the otbr-agent with OPENTHREAD_CONFIG_DNS_UPSTREAM_QUERY_ENABLE forced to 0 but the build fails.
I tried to build the otbr-agent with OPENTHREAD_CONFIG_DNSSD_DISCOVERY_PROXY_ENABLE forced to 0 but SRP registration breaks.

Is there another way to stop this behavior?

I cannot control the LAN connection and a dedicated Router between the LAN network and the OTBR is not feasible.

OTBR is running on a Pi and is running whatever the latest otbr-agent is from Git.

[jwhui]

What you are observing is OTBR's Discovery Proxy and Advertising Proxy operating across the shared Ethernet link:

1. OTBR 1 advertises its SRP registrations to eth0 via mDNS.
2. OTBR 2's Discovery Proxy queries eth0 over mDNS and receives OTBR 1's records, capping the TTL to 10 seconds per RFC 8766 Section 5.5.1.

Depending on your testing goals, here are the two recommended ways to address this:

Option 1: Disable Discovery Proxy (Best for Isolated Test Labs)

If each OTBR network is meant to be completely isolated and should never discover services from the Ethernet LAN, disable the Discovery Proxy using CMake when building ot-br-posix:

# In your setup script or cmake build:
"-DOTBR_DNSSD_DISCOVERY_PROXY=OFF"

(You can also disable -DOTBR_SRP_ADVERTISING_PROXY=OFF if the OTBR does not need to advertise Thread services onto the Ethernet LAN).

Note: Forcing OPENTHREAD_CONFIG_DNSSD_DISCOVERY_PROXY_ENABLE=0 directly via compiler defines breaks internal wrapper dependencies in otbr-agent, whereas the CMake option -DOTBR_DNSSD_DISCOVERY_PROXY=OFF configures all dependencies cleanly.

Option 2: Use Unique Instance Names (Best for Shared LAN Coexistence)

If the OTBRs are intended to coexist on the same LAN:

• Under DNS-SD (RFC 6763), the <Instance> name (<Instance>.<ServiceType>.<Domain>) must be unique on the local link.
• If both OTBRs advertise the same instance name, an mDNS collision occurs on eth0. Giving each service a distinct instance name/hostname (e.g., incorporating the host MAC or unit ID) avoids this conflict.
• Note: If the end device browses for the service type via PTR queries, both instances will appear in browse results unless the Discovery Proxy is disabled as shown in Option 1.

[NickMcKendree]

Thanks for the feedback.

I've found:
-DOTBR_DNSSD_DISCOVERY_PROXY=OFF completely breaks service discovery from end devices. I think the SRP server has issues registering a service when otbr-agent is built this way.

-DOTBR_SRP_ADVERTISING_PROXY=OFF didn't seem to do anything. The DNS requests were still forwarded. I rebooted both OTBRs and end devices to clear any caching

Regardless, your point about our service names not meeting the RFC is correct and that was a overlooked detail. My next step is updating our scripts to make the naming unique.

[jwhui]

Making the service instance names and hostnames unique is definitely the cleanest approach.