Two SRV messages - A/AAAA

[pixsperdavid]

It seems that when ServiceInfo addresses contains both IPv4 and IPv6 addresses, two SRV announcements are made, one with the A record and another with the AAAA record. Consequently I'm seeing a race condition in mDNS browsers whereby whichever packet gets received first makes the service appear to either only have IPv4 or only IPV6 addresses.

[keepsimple1]

It seems that when ServiceInfo addresses contains both IPv4 and IPv6 addresses, two SRV announcements are made, one with the A record and another with the AAAA record.

Yes we announce the service separately on IPv4 interface and IPv6 interface (if available) because they indeed are different interfaces, and the browser should be able to find them using either IPv4 or IPv6 (or both):

mdns-sd/src/service_daemon.rs

Lines 1792 to 1795 in 6f54350

	let announced_v4 =
	announce_service_on_intf(dns_registry, info, intf, &self.ipv4_sock.pktinfo);
	let announced_v6 =
	announce_service_on_intf(dns_registry, info, intf, &self.ipv6_sock.pktinfo);

On the browser side, it will receive both announcements one after another, and store & merge them in the cache. The PTR and SRV, TXT record are repeated, but address record is different because one on IPv4 interface, another is on IPv6 interface.

a race condition in mDNS browsers whereby whichever packet gets received first makes the service appear to either only have IPv4 or only IPV6 addresses.

The browser is likely notified with ServiceResolved event twice, first with one address record, and 2nd with two address records due to the update from the 2nd announcement received. The first address record could be IPv4 or IPv6 depends on which packet arrived first. So it's not really a race condition that causes an error.

TL;DR is that ServiceResolved event is not one-time deal. There could be more updates for the same service instance. Does that cause problems in your use case? (some systems, like recent Apple iOS I think, support result types like "added", "changed", but I don't know if we need them.)

[pixsperdavid]

Debugging the values I'm getting from the service resolved event, I see that it's being raised multiple times, with a steadily increasing number of addresses each time. However the last time it is raised, the number of addresses is back to just the IpV6 addresses. Could this be the root of the issue?

[pixsperdavid]

For additional context, I've tested with https://github.com/hrzlgnm/mdns-browser and I see the same result there.

[keepsimple1]

However the last time it is raised, the number of addresses is back to just the IpV6 addresses. Could this be the root of the issue?

Yes, this looks like a problem. Is it okay for you to share the relevant logs, i.e. the list of the ServiceResolved events? And confirming mdns-sd version?

For additional context, I've tested with https://github.com/hrzlgnm/mdns-browser and I see the same result there.

Could you describe the steps you used it for hitting the issue? I will try to reproduce the problem locally.

[hrzlgnm]

To add some more context from my side:

I’ve also observed this issue occasionally in larger networks, although I haven’t yet had the time to investigate it in detail. The problem sometimes appears simply by clicking the “Browse” button in hrzlgnm/mdns-browser without selecting a specific service type.

Clicking “Browse” initiates a search for all available service types, which are enumerated at startup using a separate browser for the meta service _services._dns-sd._udp.local. This meta browser runs continuously in the background. Whenever a new service type is discovered, another browser is started for that service type while the overalI browse process remains active.

l'll try to reproduce the issue with file logging enabled over the next few weeks and will share logs if I manage to capture the problem.

[keepsimple1]

The problem sometimes appears simply by clicking the “Browse” button in hrzlgnm/mdns-browser without selecting a specific service type.

Did you mean it sometimes does not show services available, or some service appearing but disappeared for no reason?

[hrzlgnm]

The problem sometimes appears simply by clicking the “Browse” button in hrzlgnm/mdns-browser without selecting a specific service type.

Did you mean it sometimes does not show services available, or some service appearing but disappeared for no reason?

What I mean is that sometimes services are only resolved with their AAAA records instead of having both an A and an AAAA record. In that case when I call ServiceDaemon::verify() for that instance, the missing A record is also resolved. Also for all other services referring to the same hostname.

[hrzlgnm]

I probably misunderstood the original issue, I'm currently only using the browsing/resolving functionallity of this library. I could not see my mentioned issue for a longer time. So I guess it got fixed. If I'll observe it in the future again, I'll try to get it reproduced and create a separate issue for that. Sorry for the confusion.