Post

The macOS DNS Battle: Why Your Settings Are Being Ignored

The macOS DNS Battle: Why Your Settings Are Being Ignored

In a standard Linux or Windows environment, changing DNS is usually a matter of editing one file or one setting. On a modern MacBook (especially a managed one), there is a multi-layered hierarchy that decides where your traffic goes.

1. The Hierarchy of Power

When you type google.com, macOS doesn’t just look at your Wi-Fi settings. It checks several layers in a specific order:

Layer 1: iCloud Private Relay & “Limit IP Tracking”

This is the most common reason manual DNS is ignored. Apple’s Private Relay intercepts DNS queries at the system level and tunnels them through Apple-branded relays (often hosted on AWS or Cloudflare).

  • The Conflict: If this is on, your manual 8.8.8.8 or 127.0.0.1 settings are completely bypassed.

Layer 2: Scoped Resolvers (VPN & MDM)

Corporate Macs use “Managed Profiles.” If you are on a VPN or have a company profile installed, the OS creates a Scoped Resolver.

  • How it works: The system says: “If the user is on the ‘Corporate Wi-Fi’ interface, ignore global settings and use these specific AWS servers.”
  • Command to see this: scutil --dns. Look for resolver #1. If it shows a specific if_index and an AWS IP, your Wi-Fi settings are being overridden.

Layer 3: System-Wide Manual Settings

This is what you change in System Settings > Network. It is the “default” but only applies if Layers 1 and 2 don’t claim the traffic.


2. Using dnsmasq for Local Development

dnsmasq is a lightweight DNS forwarder. It’s popular because it allows you to create custom local domains (like mysite.test) without editing your /etc/hosts file every time.

Common “Port 53” Conflict

DNS runs on Port 53. Only one app can “own” a port. As you discovered, tools like cloudflared (Cloudflare WARP) often grab Port 53 first. When you try to start dnsmasq, it crashes with a Bootstrap failed: Input/output error.

The fix sequence:

  1. Find the squatter: sudo lsof -i :53
  2. Kill the squatter: sudo brew services stop cloudflared (or the relevant app).
  3. Start your service: sudo brew services start dnsmasq

3. Security & Privacy: The Corporate Perspective

Why does your company force you onto AWS DNS? It’s rarely about spying and usually about DNS Filtering.

  • Phishing Protection: If you click a link to totally-not-a-scam.com, the corporate AWS DNS can return a “Blocked” page (NXDOMAIN) before the connection even starts.
  • Split-Horizon DNS: Companies use internal DNS to resolve addresses like jira.internal to private IP addresses. If you switch to 8.8.8.8, you lose access to these internal tools because Google doesn’t know where your company’s private servers are.
  • DNS Tunneling: Sophisticated malware can “tunnel” stolen data inside DNS queries. By forcing you to use a monitored AWS resolver, the company can detect these patterns.

4. Useful Commands for Tech Troubleshooting

If you are debugging DNS on a Mac, these are the only commands that tell the truth:

CommandPurpose
scutil --dnsShows the actual hierarchy of resolvers macOS is using.
networksetup -getdnsservers "Wi-Fi"Shows what is written in your settings.
dscacheutil -q host -a name [domain]Queries the macOS system resolver (the most accurate test).
sudo killall -HUP mDNSResponderThe “Golden Hammer”: Flushes the DNS cache.

Final Takeaway

If you change your DNS and dnsleaktest.com still shows AWS, your Mac is likely under an MDM (Mobile Device Management) policy or iCloud Private Relay is active. In a corporate environment, Layer 2 (Scoped Resolvers) almost always wins.

Would you like me to help you write a script that toggles between your “Work” and “Development” DNS settings automatically?

This post is licensed under CC BY 4.0 by the author.