Network interface changes are not observed on macOS, leaving services silently unadvertised

[josephspurrier]

Summary

On macOS (and other non-Linux platforms) linkSubscribe is a no-op, so network
interface changes are never observed and services are never re-announced. Because
the responder has no other re-announcement path, a service can silently stop being
advertised while the process stays alive and healthy, with nothing logged.

This is the macOS counterpart to #9 and #3, both of which were closed as fixed in
v1.2.12. Those fixes are Linux-only, as noted in their closing comments:

I have to mention that observing changes to network interfaces use the netlink
API, which is only available on Linux. This means that this feature only works
on Linux.

I could not find an open issue tracking the non-Linux side, so filing one.

Why it does not recover on its own

Three things combine, and it is the combination rather than any one of them that
makes the failure permanent:

1. No link observation. netlink_others.go is the entire non-Linux
   implementation:

   //go:build !linux
   
   func (r *responder) linkSubscribe(context.Context) {
       log.Info.Println("dnssd: unable to wait for link updates")
   }

   The Linux build calls r.announce(services(r.managed)) on every link update.
   The non-Linux build logs one line and returns.

2. No periodic re-announcement. After the two announcements sent at
   registration, respond() is purely reactive: it answers queries and nothing
   else. There is no ticker anywhere in responder.go or mdns.go that
   re-announces on a schedule.

3. Multicast group membership is joined once. NewResponder() calls
   newMDNSConn(), which does ListenUDP plus JoinGroup per interface at
   construction, and that is the only place JoinGroup runs. When an interface
   goes down the kernel drops its group membership, and nothing rejoins it.

So on macOS there is no mechanism, timed or event-driven, that can restore the
advertisement after a network change. The only recovery is restarting the process.

Point 3 also means a re-announce alone would not be a sufficient fix on this
platform: announcing through a socket whose membership has lapsed sends packets
nowhere. Any fix probably needs to rebuild the connection, not just re-announce
through the existing one.

Observed behaviour

Running brutella/hap as a long-lived HomeKit bridge on macOS, I have twice seen
the accessory vanish from the network while the process was still running
normally: the HAP TCP port still listening, all device connections healthy, and
dns-sd -B _hap._tcp local showing nothing on any real interface. Zero errors in
the application log or in dnssd's own output. A process restart fixed it both
times. I now run an external watchdog that browses for the advertisement every
five minutes and restarts the service when it is missing, which is not a great
place to be.

I want to be straightforward about the limits of this report: system logs had
already rolled over by the time I investigated, so I cannot say which network
event triggered either occurrence. The mechanism above is from reading the code,
and it is sufficient to explain the symptom, but I have not captured a trigger in
the act.

The host is dual-homed on one subnet (wired plus Wi-Fi), and also runs VPN tunnel
interfaces and bridged VM interfaces, so interface churn is frequent. That may be
why this shows up here more often than most setups.

Expected

Interface and address changes are observed on macOS as they are on Linux, and
affected services are re-announced.

Suggested approach

macOS and the BSDs expose a PF_ROUTE socket that delivers RTM_IFINFO,
RTM_NEWADDR and RTM_DELADDR messages on interface and address changes. It is
readable with plain golang.org/x/net/route and syscall, so this can be done
in pure Go with no cgo, as a netlink_darwin.go or netlink_bsd.go sibling to
the existing files, keeping the current stub as the fallback for other platforms.

Given point 3 above, it may also be worth having the update path rebuild the
mdnsConn (re-running JoinGroup) rather than only calling announce, on all
platforms. The Linux path may have the same lapsed-membership gap after an
interface bounce, though I have not tested that.

Happy to put together a PR for the PF_ROUTE watcher if that direction seems
right to you.

Environment

• dnssd v1.2.14
• hap v0.0.35
• go1.26.1 darwin/arm64
• macOS 26.2 (25C56), Apple silicon

[josephspurrier]

Follow-up: I tested the simplest interface perturbation on macOS and the
responder survived it, which contradicts one of the mechanisms I claimed
above. Correcting that here rather than leaving it standing.

Test

macOS 26.2, dnssd v1.2.14 via hap v0.0.35, service registered on en0:

sudo ifconfig en0 down && sleep 5 && sudo ifconfig en0 up

Confirmed from the system log that the interface really did bounce:

23:54:36  kernel    bpf0 closed and detached from en0
23:54:38  configd   [IPMonitor] network changed: v4(en0:192.168.0.43, en1)
23:54:38  mDNSResponder [State] *** Network Configuration Change ***

Result: still advertising

Two minutes later, querying the wire directly to bypass the local
mDNSResponder cache:

$ dig +time=3 @224.0.0.251 -p 5353 Homebridgerton._hap._tcp.local SRV

;; flags: qr aa rd;  QUERY: 1, ANSWER: 3, ADDITIONAL: 4
;; ANSWER SECTION:
Homebridgerton._hap._tcp.local.  120 IN SRV  0 0 51828 688F4B21C25C.local.
Homebridgerton._hap._tcp.local.  450 IN TXT  "c#=3" "ci=2" "ff=0" ...
_hap._tcp.local.                 450 IN PTR  Homebridgerton._hap._tcp.local.
;; ADDITIONAL SECTION:
688F4B21C25C.local.              120 IN A    192.168.0.43
;; SERVER: 192.168.0.43#5353(224.0.0.251)

Authoritative answer, correct records, same PID throughout, no restart. The
socket kept its multicast group membership across the bounce.

Correction

I claimed above:

When an interface goes down the kernel drops its group membership, and
nothing rejoins it.

That does not hold for this case and I should not have stated it as flatly as I
did. Where the interface keeps its index and address across a down/up cycle,
membership evidently survives on macOS. I used that claim to argue that
re-announcing alone would be insufficient and that the mdnsConn must be
rebuilt. That argument is weaker than I presented it, and the JoinGroup-once
observation may well be harmless for this class of event.

What still stands

The two source-level facts are unchanged:

• linkSubscribe is a no-op on non-Linux, so interface and address changes are
  never observed.
• There is no periodic re-announcement. After registration, respond() only
  answers incoming queries.

And the original symptom is unchanged: I have twice seen the advertisement
disappear on macOS while the process stayed alive and healthy, recovering only
on a restart.

Better suspects for the trigger

A wired down/up preserving ifindex and IP is the gentlest perturbation
available, so a negative result there says little about harsher events. Given
that #51 involved an interface being removed, the likelier triggers are:

• interfaces appearing or disappearing (VPN tunnels, VM bridges)
• Wi-Fi reassociation, especially with an address change
• sleep/wake

I will keep testing and report back if I can catch one in the act. Apologies
for the noise on the mechanism.

[josephspurrier]

Caught one. A confirmed failure with evidence this time, and it partly
reinstates the mechanism I walked back in my previous comment.

What happened

18 Aug, 10:40. My watchdog now browses four times and then issues a direct
multicast query before it will restart anything, capturing state first. All four
browses found the service on loopback only:

Timestamp     A/R  Flags  if  Domain   Service Type   Instance Name
10:39:57.934  Add      3   1  local.   _hap._tcp.     Homebridgerton
10:39:57.934  Add      3   7  local.   _hap._tcp.     HomePodSensor 568430
10:39:57.934  Add      2  16  local.   _hap._tcp.     HomePodSensor 568430

Interface 1 is loopback, 7 is wired ethernet, 16 is Wi-Fi. An unrelated HomeKit
accessory on the same LAN stayed visible on both real interfaces throughout, so
mDNS and the network were working and only the dnssd-advertised service had
gone. Identical output on all four browses across 20 seconds.

The direct query at the same moment:

$ dig +time=2 +tries=1 @224.0.0.251 -p 5353 Homebridgerton._hap._tcp.local SRV
;; connection timed out; no servers could be reached

The process was otherwise healthy: 1d20h uptime, all five of its own device
connections up, HAP port still listening, and 0.0% CPU. That last figure
rules out a spinning read loop (#32) as the explanation here.

Trigger

Nineteen minutes earlier, a transient interface appeared:

10:21:38  mDNSResponder  *** Network Configuration Change ***
            SC key: State:/Network/Interface/utun9/IPv6
            flags: 0x20 {P2P/IFEF_DIRECTLINK/IFEF_AWDL/car-play}
10:21:38  configd [IPMonitor]  network changed: v4(en0:192.168.0.43, en1)

utun9 was gone again by evening. macOS brings these up on its own for
AirPlay, Handoff and CarPlay, so this is unfortunately not reproducible to
order.

This revises my previous comment

I reported that ifconfig en0 down/up and a Wi-Fi off/on cycle both left the
responder working, and concluded from that the group membership idea was
doubtful. Those results stand, but I generalised too far from them. Keeping
loopback while losing every real interface is close to what a lapsed membership
would look like, and it is hard to account for with a missing re-announce alone:
a service that had merely gone unannounced should still answer a direct query,
and this one did not answer at all.

The distinction that seems to matter is changes to the interface set, not
changes to interface state. A down/up cycle preserves the index and the
address, and survives. A new interface appearing does not, and does not. That
also fits #9 and #51, which both involved interfaces appearing or being removed
rather than bouncing.

Where that leaves it

Still true, and still the root of it, is that linkSubscribe is a no-op outside
Linux, so none of this is ever noticed. On Linux the same event would reach
announce().

What I am now unsure of is whether re-announcing alone would be enough on
macOS, or whether the mdnsConn has to be rebuilt so that JoinGroup runs
again. If the socket really has lost its membership on the real interfaces, then
announcing through that same socket would not help.

Happy to instrument further if there is something specific you would like
captured next time. The watchdog now saves full state on every occurrence, so I
can collect these over time even though I cannot trigger one on demand.