Skip to content

Mystery Device on Pi-hole: macOS Adopted a Thunderbolt Dock's Name as Its Hostname

A brand-new MacBook Pro joined the network and showed up in Pi-hole as Anker.majorlan. No Anker device with Wi-Fi existed in the house. The obvious theories were both wrong, and the actual cause is a macOS quirk worth knowing: a Mac can silently adopt the name of a connected Thunderbolt accessory as its own computer name, and then report that name to DHCP — so your network tooling attributes the Mac's traffic to "Anker" (or "LG UltraFine", "CalDigit", "Dell", whatever hardware is plugged in).

Symptom

  • A client appears in Pi-hole (or your router's client list) named after a peripheral brand — a dock, hub, or monitor vendor — not any device you own with a network stack.
  • Timing correlates with a new or freshly reinstalled Mac joining the network, used with a Thunderbolt/USB-C dock or display.

Two wrong theories to rule out first

Theory 1 — "it's the dock's Ethernet adapter's MAC." Plausible: when a Mac gets wired network through a dock, the MAC on the wire belongs to the dock's Ethernet chip, and the vendor column resolves to the dock maker. But that changes the MAC vendor, not the hostname. Check which column actually says "Anker":

-- Pi-hole v6, on the Pi-hole host:
sudo pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db \
  "SELECT n.hwaddr, n.macVendor, na.ip, na.name
   FROM network n LEFT JOIN network_addresses na ON na.network_id=n.id
   ORDER BY n.lastQuery DESC LIMIT 20;"

In this case: macVendor = Apple, Inc., name = Anker.majorlan. The MAC was Apple's — the hostname was the problem. Theory dead.

Theory 2 — "it's a randomized MAC whose vendor lookup coincidentally matches." Locally-administered (randomized/private) MACs sometimes produce absurd coincidental vendor matches. The tell is the second hex digit of the first octet: 2, 6, A, or E means randomized. Here the MAC started c0: → globally administered, genuinely Apple. Theory dead.

Confirming which physical device it is

With both shortcuts dead, fingerprint the client by what it queries. A Mac is unmistakable:

  • Heavy *.aaplimg.com, *.apple-dns.net, updates.cdn-apple.com, metrics.icloud.com traffic (a brand-new Mac hammers these during setup).
  • Whatever personal services its owner uses (self-hosted domains, VPN endpoints) appear as soon as they log in.
  • A nice bonus tell for this specific quirk: the client repeatedly queries the reverse-DNS of its own IP (X.X.X.X.in-addr.arpa) — macOS's name-resolution machinery probing for what it should call itself.
sudo pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db \
  "SELECT d.domain, COUNT(*) c FROM query_storage q
   JOIN client_by_id c2 ON q.client=c2.id
   JOIN domain_by_id d ON q.domain=d.id
   WHERE c2.ip='192.168.1.68'
   GROUP BY d.domain ORDER BY c DESC LIMIT 15;"

Root cause

macOS derives and occasionally re-derives the computer name, and there is a long-reported behavior where a Mac renames itself after a connected Thunderbolt dock or display — you may even see the "Your computer's name was changed to…" notification, or nothing at all. Once adopted, the name flows everywhere: ComputerName → DHCP client identifier → your router/Pi-hole client list. The Mac isn't lying about its MAC or traffic; it genuinely believes it's named after the dock.

Fix

On the Mac, set all three name records explicitly:

sudo scutil --set ComputerName  MyMac
sudo scutil --set LocalHostName MyMac
sudo scutil --set HostName      MyMac

Then renew the DHCP lease (toggle Wi-Fi, or unplug/replug Ethernet) so the corrected hostname is re-reported.

If the old name lingers in Pi-hole's client list, purge the stale network-table entry so the client re-registers cleanly:

sudo pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db \
  "DELETE FROM network_addresses WHERE ip='192.168.1.68';
   DELETE FROM network WHERE hwaddr='c0:c7:db:xx:xx:xx';"
sudo systemctl restart pihole-FTL

Notes

  • The rename can recur while the same accessory is connected — if the name reverts, set it again with scutil; it generally sticks after one correction. Setting HostName explicitly (which is empty by default) makes the name much harder for the auto-renamer to displace.
  • Lock in attribution while you're here: if the Mac's MAC is globally administered (Private Wi-Fi Address off/fixed), add a router DHCP reservation and a local-DNS name — they'll hold. Against a randomized MAC, neither will.
  • The broader client-identification toolkit (mDNS sweeps, query-pattern fingerprinting, randomized-MAC detection) is covered in Pi-hole Client Attribution.