Disable Bonjour

What the Bonjour mDNS disabler does

This Automox Worklet™ disables Bonjour multicast DNS advertisements on macOS endpoints by writing the NoMulticastAdvertisements key into /Library/Preferences/com.apple.mDNSResponder.plist. Bonjour is Apple's zero-configuration networking protocol that announces local services (file sharing, screen sharing, AirDrop peers, printers) to every endpoint on the same broadcast domain over UDP port 5353.

Once the flag is set, mDNSResponder stops emitting outbound advertisements for the endpoint's services. The endpoint can still resolve .local hostnames and connect to Bonjour-advertised services on other hosts, so outbound discovery continues to work. File sharing, SMB, SSH, and Screen Sharing remain reachable when accessed by IP address or DNS hostname.

The Worklet runs the same defaults read check on every evaluation, so it is safe to schedule on a recurring policy. Endpoints already in the desired state are not modified, and endpoints that drift out of state (a profile reset, an OS reinstall, a manual change) are quietly remediated on the next run.

Why disable Bonjour mDNS on roaming endpoints

Bonjour was designed for trusted home and small-office networks, not the coffee-shop Wi-Fi a sales laptop joins three times a week. By default, a macOS endpoint advertises its hostname, model, user-set sharing services, AirPlay receivers, AirPrint queues, and remote management state to every other client on the same subnet. A passive attacker on the same SSID can fingerprint every Mac on the network in seconds using stock tools such as dns-sd -B, avahi-browse, or nbtscan – no exploit required. CIS Benchmark for macOS recommends restricting mDNS advertisements on portable systems, and CISA guidance on flat untrusted networks calls out multicast service discovery as a low-effort reconnaissance vector.

This Worklet sets NoMulticastAdvertisements on every Mac in scope by writing the value to the mDNSResponder preferences plist at /Library/Preferences/com.apple.mDNSResponder.plist, the same location the daemon reads on launch. Idempotent plist writes keep repeat runs cheap on endpoints already aligned with the standard, and any host that drifts back to the default broadcasting state after an OS upgrade or imaging cycle surfaces in the activity log on the next evaluation.

How Bonjour mDNS suppression works

1. Evaluation phase: The evaluation script runs defaults read /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements and compares the result to 1. If the key is missing, set to 0, or returns an error because the plist has no value yet, the endpoint is flagged for remediation and the script exits 1. If the key already reads 1, the endpoint is already hardened and the script exits 0 without touching state.

2. Remediation phase: The remediation script re-reads NoMulticastAdvertisements as a guard, then runs defaults write /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements -bool true. The change takes effect the next time launchd restarts the com.apple.mDNSResponder daemon, or on the next reboot. Run sudo killall -HUP mDNSResponder to reload the daemon immediately during a pilot.

Bonjour hardening requirements

• macOS endpoint (workstation or server) – the Automox agent ships in a root context that already has the privileges to write to /Library/Preferences

• No additional parameters – the Worklet is keyed to a single plist value and ships ready to run

• Reload of the mDNSResponder daemon (automatic on next launchd refresh or reboot, or manual via sudo killall -HUP mDNSResponder)

• Awareness that AirDrop discovery and AirPlay receiver advertisement both rely on Bonjour; endpoints that need either should be excluded from the policy or paired with a profile that scopes the flag

Expected macOS network state after remediation

After the remediation script completes, defaults read /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements returns 1, and a subsequent evaluation run exits 0 without making changes. From a second endpoint on the same subnet, dns-sd -B _services._dns-sd._udp local. no longer lists the hardened endpoint, and avahi-browse -art on a Linux host shows the same disappearance. Active connections initiated by IP address or hostname keep working, because mDNS suppression affects advertisement only, not name resolution or socket-level traffic.

AirDrop peer discovery is the one user-facing behavior that changes. End users who depend on AirDrop should either be scoped out of the policy or routed to an alternative transfer method (managed file share, Slack, signed S3 link). Screen Sharing, Remote Login, file sharing over SMB, and printing to a directly addressed print queue are not affected. Schedule this Worklet on a recurring policy to hold the hardened state through OS upgrades, profile resets, and user-driven changes to Sharing preferences.