Apple Device Support: Managed Mac Cannot Reach an Internal Server After a Network Change

Managed Mac Cannot Reach an Internal Server After a Network Change

A 40-person design studio runs a flat /24 office network (10.20.30.0/24) with a single DHCP server on the router. The studio deploys a new managed Wi-Fi network with two SSIDs: Studio (WPA3-Enterprise, RADIUS) and Guest (captive portal). Macs are enrolled in MDM and receive a Wi-Fi payload that auto-joins Studio. Users report that since the change, Safari cannot load the internal asset server at assets.studio.local, but public websites work fine. ping assets.studio.local resolves to 10.20.31.14, which is not in the office subnet. The asset server's IP is actually 10.20.30.14 and has not moved. Several Macs on Guest can reach the server by IP but not by name. One Mac on Studio can reach it by name but only after the user manually adds a DNS suffix.

1. Diagnose why name resolution returns 10.20.31.14 and why the `Guest` Macs behave differently. What is the most likely root cause, and what would you check first?

Read the worked answer

The symptom pattern points to a DNS/search-domain mismatch introduced by the new network, not a server move.

assets.studio.local resolving to 10.20.31.14 means the query is being answered by a DNS server that has a stale or different record for that name. On Studio, the RADIUS-authenticated network likely hands out a DNS server (or search domain) that differs from the old flat network. Because .local is a special-use domain, macOS may also be answering via multicast DNS (Bonjour) rather than unicast DNS, so a cached mDNS answer or an mDNS responder on another device advertising the name could win.
Guest Macs can reach by IP but not name because the captive-portal network typically hands out a different DNS server and does not pass the internal search domain, so assets alone does not resolve and the FQDN goes to a public resolver that returns NXDOMAIN or a hijacked answer.

Check first, in order:

scutil --dns to see which resolver is answering for studio.local and whether mDNS is in play.
dscacheutil -q host -a name assets.studio.local and dig assets.studio.local @<expected-internal-DNS> to compare cached vs authoritative answers.
The DHCP/DNS options pushed by the Studio SSID profile - confirm the internal DNS server and search domain are included.
Whether a rogue device is advertising the name via Bonjour.

Fix direction: correct the DNS record on the authoritative server, push the internal DNS/search domain in the Wi-Fi payload, and flush the cache (sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder) after correcting.

2. A user on `Studio` says the site works only after manually adding a DNS suffix in System Settings. Is that an acceptable permanent fix in an MDM-managed fleet? Justify your answer and describe the managed alternative.

Read the worked answer

No - it is not acceptable as a permanent fix. A manual suffix edit is a per-device, per-user change that:

Is not captured in the MDM configuration profile, so it will be lost on re-enrollment, OS reinstall, or profile update.
Creates configuration drift across 40 Macs, making future troubleshooting harder.
Masks the underlying problem (wrong or missing DNS/search-domain data from the network), which will recur on the next network change.

The managed alternative is to deliver the search domain and DNS servers through the MDM Wi-Fi/DNS payload so all enrolled Macs get a consistent resolver configuration. Steps:

Add the internal DNS servers and studio.local search domain to the Wi-Fi payload (or a separate DNS settings payload) in the MDM.
Scope it to the Studio network or to the device group that needs internal access.
Verify on a test Mac with scutil --dns that the resolver order is correct and that the internal domain is not being sent to a public resolver.
Only after confirming, roll out to the fleet and remove any manual suffixes.

This keeps the fix declarative, auditable, and repeatable.