My Mac Advertises Five Services, All Five Carry My Name

On 21 October I counted the listening sockets on this machine:
42 of 55 were unreachable from the network.
A comforting ratio. But that measurement answers exactly one question: what
happens if someone tries to connect? This week I realised the real event is
over before that. Nobody has to try anything — the machine has already told the
network who it is.

And what it tells isn't a port number. It's my name.

Every measurement here was taken on the morning of 8 November 2026, on a single
machine: macOS 26.6.2 (build 25G83), Apple M4 Pro, hw.model = Mac16,7, no
MDM enrolment (profiles status → "MDM enrollment: No", and no configuration
profile installed for the user either). The network I'm on is WPA2 Personal and
the machine's address is 192.168.1.20. Every command is read-only; I didn't
change a single setting for this piece. Near the end I list what I couldn't
measure, because on this topic that list isn't short.

One scan, seventeen rows

On macOS the way to ask what services are on the network is dns-sd. I asked
which service types are being advertised:

$ dns-sd -B _services._dns-sd._udp local.
Timestamp     A/R Flags if Domain      Service Type    Instance Name
 8:40:28.302  Add    3   1 .           _tcp.local.     _rfb
 8:40:28.302  Add    3   1 .           _tcp.local.     _airplay
 8:40:28.302  Add    3   1 .           _tcp.local.     _raop
 8:40:28.302  Add    3   1 .           _udp.local.     _net-assistant
 8:40:28.302  Add    3   1 .           _tcp.local.     _companion-link
 ...

Seventeen Add rows, twelve distinct service types. The curious thing about
this command is that the part you're
looking for sits at the end of the line: the "Service Type" column says
_tcp.local., while the service's actual name lands under "Instance Name". You
read it backwards the first time.

The if field is the interface index. Five types appear twice — once on index 1,
once on index 14; the remaining seven appear only on 14. That is where the
seventeen rows come from: five types twice, seven types once. Index 14 is this
machine's Wi-Fi
interface; the other devices at home come in through it, and they're not the
subject of this piece. I have no intention of publishing an inventory of my own
household.

The five types I care about are _rfb, _airplay, _raop, _net-assistant
and _companion-link. I did not infer that these belong to this machine from
the interface index alone — I browsed each one separately. Every time, the single
instance that came back carried this machine's ComputerName, with its SRV
target pointing at its LocalHostName:

$ for t in _rfb._tcp _airplay._tcp _net-assistant._udp \
           _companion-link._tcp _raop._tcp; do dns-sd -B $t local.; done

_rfb._tcp.             mustafa MacBook Pro
_airplay._tcp.         mustafa MacBook Pro
_net-assistant._udp.   mustafa MacBook Pro
_companion-link._tcp.  mustafa MacBook Pro
_raop._tcp.            C642A97923A7@mustafa MacBook Pro

All five carry my computer's name. Four of them plainly, and _raop with an
identifier bolted on the front. The name itself comes from two separate settings,
both readable from the machine's own records:

$ scutil --get ComputerName
mustafa MacBook Pro
$ scutil --get LocalHostName
mustafa-MacBook-Pro

What the five services are

The type names don't explain themselves, so I resolved each one. dns-sd -L
tells you which host and port the service lives on:

$ dns-sd -L "mustafa MacBook Pro" _rfb._tcp local.
... can be reached at mustafa-MacBook-Pro.local.:5900 (interface 14)

$ dns-sd -L "mustafa MacBook Pro" _net-assistant._udp local.
... can be reached at mustafa-MacBook-Pro.local.:3283 (interface 14)

I looked the port numbers up in Apple's own list.
Apple's document on TCP and UDP ports used by its software
(published 28 July 2026) lists 5900 under the service name rfb, used by
"Apple Remote Desktop, Screen Sharing". 3283 is net-assistant: Apple Remote
Desktop. 7000 is AirPlay, and 5353 is mDNS itself — "Bonjour, AirPlay, Home
Sharing, Printer Discovery".

So two of the five advertisements are remote access. And they aren't merely
advertised; they're genuinely open:

$ launchctl print-disabled system | grep -E "screensharing|smbd|ftpd"
    "com.apple.screensharing" => enabled
    "com.apple.ftpd" => disabled
    "com.apple.smbd" => disabled

$ lsof -nP -iTCP -sTCP:LISTEN | grep -E "ARDAgent|ControlCe|rapportd"
ARDAgent  709 mustafaerbay  9u IPv6 ... TCP *:3283  (LISTEN)
ControlCe 716 mustafaerbay  9u IPv4 ... TCP *:7000  (LISTEN)
ControlCe 716 mustafaerbay 10u IPv6 ... TCP *:7000  (LISTEN)
rapportd  665 mustafaerbay  5u IPv4 ... TCP *:51786 (LISTEN)

File sharing and FTP are off. Screen sharing is on, and the remote management
agent is running and listening on *:3283, meaning every interface. The AirPlay
receiver does the same: the ControlCenter process holds *:7000 on both IPv4 and
IPv6 — a detail that matters again shortly. _companion-link is the Continuity
side, rapportd.

Let me be honest with myself here: I would love to write "I never turned these
on", but I have no record showing that I didn't. The measurement says only this:
they are on, and because they are on, they go out onto the network with my name
attached.

This isn't a leak, it's what the spec asks for

My first reaction was "a setting must have slipped past me". It didn't. Reading
the service discovery spec, I learned that the readability of that name is not
an accident but an explicit requirement.

RFC 6763, which defines DNS-SD,
splits a service name into three parts: <Instance>.<Service>.<Domain>
(section 4.1, "Service Instance Name"). For the Instance part, section 4.1.1 is
unambiguous — the name should be "a user-friendly name consisting of arbitrary
Net-Unicode text" and "should be a user-visible, user-friendly name rather than
an invisible machine-generated opaque identifier". A machine-generated opaque
identifier is explicitly not wanted; a name a human can read and recognise is.
The appendix it points you to for the reasoning is called "What You See Is What
You Get".

The logic holds, too. When you open the AirDrop panel you pick devices by their
names; seeing a8a5a8… there would be useless. The spec thought about the
user. It just didn't think about the stranger at the next table.

A few lines further down, the same section pushes the other way: the default name
should be short and descriptive, and "SHOULD NOT include the device's Media
Access Control (MAC) address, serial number, or any similar incomprehensible
hexadecimal string in an attempt to make the name globally unique". My _raop
record is named C642A97923A7@mustafa MacBook Pro. Both recommendations apply to
all five services at once: five out of five satisfy the first, and four out of
five satisfy the second.

The extra information attached to a service lives in the same document, section
6: every DNS-SD service must carry a TXT record alongside its SRV record
("Every DNS-SD service MUST have a TXT record"), and per section 6.3 its purpose
is "to convey a small amount of useful additional information about a service".
Small and useful. Let's look.

What's inside the TXT record

Here is the AirPlay service's TXT record — shortened, with identifiers masked:

act=2 acl=0 deviceid=C6:42:A9:… features=0x4A7FCFD5,0x38174FDE
flags=0x204 gid=408CCEE0-… model=Mac16,7 at=4 protovers=1.1

model=Mac16,7. That is character-for-character what sysctl -n hw.model
returns on this machine. So the network learns not only my name but which Mac
model I use — a string that narrows down the purchase year without anyone having
to look up an OS version.

The deviceid field is formatted like a MAC address, and my first thought was
"there's the stable hardware identifier". Wrong thought. I looked at its first
octet:

0xC6 = 1100 0110
              └─ Local bit (0x02) = 1

RFC 7042 section 2.1 defines that
bit: "The Local bit is zero for globally unique EUI-48 identifiers" — so if the
bit is 1, the address is not a globally assigned hardware identifier but a
locally administered value.

I have to stop here, because my first draft went further than it should have.
Apple's
Wi-Fi privacy document
says Apple "generates randomized MAC addresses for the peer-to-peer Wi-Fi
connections that are used for AirDrop and AirPlay" — and that sentence is about
the address of the peer-to-peer interface itself, not about the deviceid field
inside an mDNS TXT record. It was easy to read the document as backing my claim;
I read it somewhere it wasn't looking. All the measurement really says is that
this value didn't come from the factory. Whether it is random, whether it changes
at every boot, or whether it is pinned to this machine — one observation cannot
tell you, and I won't pretend otherwise.

The companion-link TXT record carries fields like rpBA, rpAD, rpHN and
rpVr. I couldn't find what they mean in Apple's documentation, and I'm not
going to invent a meaning for something I couldn't find, so I stop there too.

What's left is still an asymmetry, and it is the whole point of this piece:
the numbers are opaque, the words are not. Nobody looking from outside can
work out what deviceid or rpAD says; for "mustafa MacBook Pro" and
Mac16,7 they don't have to. The privacy effort went into the hexadecimal
fields, and the plain text was left as it is.

Without anyone asking

One more thing I wondered: does this announcement go out when someone asks, or
on its own?

RFC 6762, which defines mDNS,
answers in section 8.3. The responder "MUST send an unsolicited Multicast DNS
response" — unsolicited. And further: "MUST send at least two unsolicited
responses, one second apart". At least twice, a second apart. These go to UDP
port 5353 per section 2, and to the multicast address 224.0.0.251 per section 3
— that is, to everyone on the link.

The same section also sets the scope of that response, and this is where my
first arithmetic fell apart: the response carries all of the machine's newly
registered records in its Answer Section ("all of its newly registered resource
records"), split across several packets if they don't fit. The announcement is
per event, not per service. All five of my services travel in the same packet.

When those steps run is written down too. Section 8 says the responder starts
over when it "starts up, wakes up from sleep", or when the link changes. Waking
from sleep is a trigger.

And here an older measurement of mine comes into play. At the end of September I
counted this laptop's wake records:
76 full wakes in seven days,
and I was at the keyboard for 13 of them. Combine that with the spec and a lower
bound appears: 76 wakes × at least 2 responses = at least 152 unsolicited
responses that week. The ceiling is written down as well — the same section
allows up to eight ("MAY send up to eight"), provided the interval at least
doubles each time, which puts the far end at 608.

That is the count for one address family. Per section 20, a dual-stack machine
takes part in two separate ".local." zones and should register its names over
both IPv4 and IPv6 — and we saw above that the AirPlay receiver listens on both
stacks. Two zones double the lower bound again.

All of that I derived; I did not measure it — capturing packets needs root,
and this session has no sudo password. The figure also belongs to that week;
this week's wake count will differ.

The reassuring half of the spec deserves a line too, because there is one:
section 8.3 says a responder "MUST NOT send regular periodic announcements as a
matter of course". The machine isn't chattering away; it speaks only when
something changes. Noise was never the problem — saying the same two words every
time is.

The ordering in that diagram is my claim: the firewall sits furthest right,
because it only rules on an actual connection attempt. The announcement is to
its left, and independent of it.

What hiding the MAC address actually solves

The defence that comes to mind here is Apple's private Wi-Fi address.
Per the documentation, macOS Sequoia 15
and later offer three options: Off, Fixed, Rotating. Off is spelled out — "When
set to Off, your device uses its hardware MAC address". Fixed is a private
address that stays constant per network; Rotating changes every two weeks. The
default depends on the network's security: joining a new WPA2-or-stronger network
the device chooses Fixed, and on a weak or open network it chooses Rotating.

I ran the same bit test on this machine's Wi-Fi address:

$ ifconfig en0 | grep ether
    ether 84:2f:57:…

0x84 = 1000 0100
              └─ Local bit (0x02) = 0

The Local bit is 0. By RFC 7042's definition that makes it a globally unique
identifier: the manufacturer-assigned address. From there it follows that the
private address is off on this network — but I have to say that this is an
inference, not a measurement. Apple nowhere documents that its private
address sets the Local bit; I reasoned from the standard's logic. The setting
itself lives in
/Library/Preferences/com.apple.wifi.known-networks.plist, which is
-rw------- root wheel; I couldn't open it.

And in fairness, evidence against that inference is sitting two paragraphs above,
written by me: Apple's documented default on a WPA2 network is Fixed. So the
document says it should be on while the measurement says off. At least two
explanations survive, and I can rule out neither — either Apple's private
addresses don't set the Local bit, or ifconfig prints the hardware address
regardless of which address the machine associates with. I couldn't read which
on this machine. I won't tell you flatly that it's off; all I know is that the
two sources don't meet.

But the inference isn't needed for the part that matters: what would change if
Rotating were on? The address would turn over every two weeks. The
"mustafa MacBook Pro" and Mac16,7 inside the announcement would stay exactly
the same. Hiding your identity at the link layer and handing it back as plain
text one layer up is like drawing the curtains and then shouting your name out
of the window.

I also counted how many networks this machine remembers:

$ networksetup -listpreferredwirelessnetworks en0 | tail -n +2 | wc -l
      18

Eighteen networks. Alongside home and work, the list includes a shopping centre's
guest network. Walking into a remembered network connects automatically, and per
RFC 6762 section 8 the announcement goes out automatically too. So this identity
travels to as many as eighteen different places, saying the same two words at
each one.

The section the spec doesn't have

This is where I was most surprised. Section 21 of RFC 6762 is titled "Security
Considerations". I opened it: it is entirely about trust and impersonation. It
warns that a responder may be "some local host that is merely masquerading as
that name", notes that a client cannot be sure about hostile hosts on the link,
and offers IPsec signatures and DNSSEC as remedies.

So the spec takes seriously the risk of you being deceived. It never treats
what you say about yourself as a disclosure problem. The threat model points one
way: from the network toward you.

Expecting more from a 2013 document may be unfair. What's interesting is that
the gap has been closed in audit standards. NIST's macOS security compliance
project has a rule called os_bonjour_disable —
the rule file is on GitHub,
titled "Disable Bonjour Multicast", with its rationale in one sentence: Bonjour
multicast advertising must be disabled so the system doesn't broadcast its
presence and services on network interfaces. The rule sets the
NoMulticastAdvertisements key to true in the com.apple.mDNSResponder
domain; its tags include all three 800-53r5 levels, 800-171, CIS v8 and CMMC
level 2, and it is defined for macOS 27.0, 26.0 and 15.0. One detail I shouldn't
skip: on the CIS side this is item 4.1 at level 2 — outside the level 1
baseline most organisations are actually audited against — and on the DISA STIG
side its severity is "medium".

On this machine that domain doesn't exist at all:

$ defaults read /Library/Preferences/com.apple.mDNSResponder
Domain /Library/Preferences/com.apple.mDNSResponder does not exist

No domain means no key, which means the advertisements are on. An audit that
checks this control would fail this machine — though, being a level 2 item, not
every audit checks it. I'm failing it right now too.

What to do — and what not to

Applying that rule blindly at home doesn't feel right to me. Turning
advertisements off entirely also kills AirDrop, printer discovery, AirPlay and
Continuity — three of the five announcements counted here (the two AirPlay
records and _companion-link) are those features. The standard was written for
managed fleets, not for my kitchen table.

The order that makes sense to me is this:

1. Treat the two remote-access services separately. Screen sharing and remote management are the two most expensive of the five advertisements. They're the ones to switch off the moment I don't need them — far less painful than giving up AirDrop.
2. Read the name once — both of them. Whatever scutil --get ComputerName returns, everyone on the network sees it. Checking whether your first name, surname or employer is in there is worth one look. There's a trap here: the name lives in two separate settings, and mDNS uses LocalHostName in the SRV record. Set both, or one of them stays behind:

   sudo scutil --set ComputerName  "work-laptop"
   sudo scutil --set LocalHostName "work-laptop"

1. Accept the model line. model=Mac16,7 can't be switched off; it's part of the service advertisement. There's no negotiating here, only awareness.
2. Remove untrusted networks from the list. Keeping a guest network on the list means the connection, and the announcement, repeat automatically on every visit. How many of those eighteen are genuinely needed?

   networksetup -removepreferredwirelessnetwork en0 "<ssid>"

1. Don't treat the private address as the whole answer. It does its job, but at a different layer. Hiding the address doesn't hide the name.

One more thing: these three facts look harmless one at a time and change when you
set them side by side. The name lets a stranger address you by it. Mac16,7 says
which hardware you're on. The third is that the same identity repeats on every
remembered network — a trail showing that this machine went there. All three came
out of the commands above, written down separately; not drawing the line between
them would have been a cop-out.

What I couldn't measure

The honesty section. I couldn't capture packets to confirm the announcements
actually go out; listening to 5353 traffic needs root. I couldn't read the
security types of remembered networks, or each network's private-address setting,
for the same reason. I also didn't test whether 5900 and 3283 are reachable
from the network — connecting to my own address from my own machine isn't a real
network path, so the result of
the socket count of 21 October
still stands here — and that piece says itself that the 42 was derived rather
than measured: being advertised is not the same as being reachable.

But reachability isn't this piece's claim. The announcement goes out even when
the access question is never asked.

What stays with me

We always frame the privacy conversation around connections: which port is open,
what the firewall says, who can connect. On this machine the answer to that
question is reasonable. Yet identity leaves ahead of any connection and
independently of it — and it does so because the spec asks for it, not because
something broke.

Discovery protocols were designed to introduce us to each other, and they do
their job very well. There's no reason for them to stop introducing us; the real
question is that we never read what they say while doing it. Until I read section
4.1.1 of a nearly fourteen-year-old specification, it hadn't occurred to me that the
name I gave my computer had become the payload of a network protocol.

The next time you join a network, your machine will speak on your behalf. At
least walk in knowing what it says.

Official Sources

• RFC 6763 — DNS-Based Service Discovery
• RFC 6762 — Multicast DNS
• RFC 7042 — IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters
• Apple — TCP and UDP ports used by Apple software products
• Apple — Use private Wi-Fi addresses on Apple devices
• NIST macOS Security Compliance Project — os_bonjour_disable