Apple Devices and the New .self TLD: Self-Hosting Issues Fixed

A growing number of Apple users are running into trouble after trying to reach services hosted on the newly proposed .self top-level domain, a TLD specifically designed to support self-hosted services on home networks. Threads in the Apple Support Community describe Safari refusing to load .self addresses, macOS rejecting local certificates, and iPhones silently rerouting requests to public DNS resolvers. This is a widespread reported issue, particularly for anyone running a home server, a NAS, or a Raspberry Pi behind a local resolver.

If you’ve configured a .self domain to point to a device on your LAN and your Mac or iPhone refuses to connect, this guide walks through what’s actually going wrong and how to get things working on Apple platforms.

What Causes This Issue

The .self TLD was introduced to give self-hosters a clean namespace that doesn’t collide with existing internet domains. The problem is that Apple’s networking stack — across macOS, iOS, iPadOS, and tvOS — applies several layers of protection that interfere with non-standard or locally resolved TLDs.

Several root causes are at play:

• iCloud Private Relay intercepts DNS queries from Safari and routes them through Apple’s relay servers, which won’t know about your local .self records.
• Encrypted DNS (DoH/DoT) profiles installed on the device override your router’s DNS, bypassing any local resolver handling the .self zone.
• mDNS and Bonjour only resolve .local, not .self, so Apple’s automatic local discovery doesn’t help here.
• HSTS and certificate validation reject self-signed certificates for any non-recognised TLD unless explicitly trusted.
• Safari’s address bar often treats unknown TLDs as search queries and forwards them to the default search engine instead of resolving them.
• Users in the Apple Support Community also note that Network Extension based VPNs and content filters can drop queries for unrecognised TLDs entirely.

Because .self isn’t yet part of the official IANA root zone, public resolvers return NXDOMAIN, and Apple’s strict security model treats anything unverifiable as suspicious.

Step-by-Step Fixes

1. Disable iCloud Private Relay for your network. On macOS, open System Settings, click your Apple ID, choose iCloud, then Private Relay, and turn it off — or set it to off for your current Wi-Fi network only. On iPhone or iPad, go to Settings, tap your name, then iCloud, then Private Relay. Restart Safari afterwards.
2. Point DNS to your local resolver explicitly. On macOS, go to System Settings, Network, select your active connection, click Details, then DNS, and add the IP address of the resolver that knows about your .self zone (typically your router or a Pi-hole/Unbound instance). On iOS, go to Settings, Wi-Fi, tap the (i) next to your network, choose Configure DNS, switch to Manual, and add the resolver.
3. Remove conflicting encrypted DNS profiles. Settings, General, VPN & Device Management on iOS, or System Settings, General, Device Management on macOS. Delete any DoH/DoT configuration profile that overrides system DNS.
4. Type the full URL including the protocol. Safari often hands bare hostnames to search. Enter https://server.self or http://server.self directly so Safari treats it as a navigation attempt.
5. Install your local Certificate Authority as trusted. Export your CA’s root certificate, AirDrop or email it to the device, install the profile via Settings, then go to Settings, General, About, Certificate Trust Settings on iOS and enable full trust for that root. On macOS, drag the cert into Keychain Access, double-click it, and set it to Always Trust.
6. Flush DNS caches. On macOS, open Terminal and run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. On iOS, toggle Airplane Mode on and off, or reboot the device.
7. Test resolution outside Safari. In Terminal, run dig server.self @your-resolver-ip to confirm the resolver is actually returning the right answer. If dig works but Safari doesn’t, the issue is browser-level, not DNS.

Additional Solutions

If the basic fixes don’t get you there, several deeper adjustments help.

Hosts file override: On macOS, edit /etc/hosts and add a static line mapping your .self hostname to its LAN IP. This bypasses DNS entirely and is the fastest way to confirm whether DNS is the bottleneck. iOS doesn’t expose a hosts file, but you can achieve the same effect with a local DNS profile via the Apple Configurator tool or a configuration profile.

Use a configuration profile for DNS: Create a .mobileconfig file that sets a custom DNS resolver scoped to specific domains, including .self. This is more reliable than manual DNS settings because it survives network switches and applies across Wi-Fi and cellular.

Switch off the "Show IP address" warning in Safari: Safari 17 and later flag connections to private IPs in some configurations. Safari, Settings, Advanced, and ensure no experimental flags are blocking local network access.

Grant Local Network permission: iOS prompts apps for local network access. If your app or Safari was denied, go to Settings, Privacy & Security, Local Network, and re-enable it for the relevant apps.

Try a different browser to isolate the issue: Although Safari is the default, testing in another browser quickly confirms whether the problem is system-wide or Safari-specific. If only Safari fails, the issue is almost always related to Private Relay, HSTS, or search-engine redirection.

Check your router’s DNS rebinding protection: Many routers, including Apple’s older AirPort base stations and most modern mesh systems, block responses that point public domains to private IPs. Add .self to the rebind whitelist in your router’s advanced DNS settings.

When to Contact Apple Support

Most .self issues are network or configuration problems you can resolve yourself. However, contact Apple Support if:

• Your device refuses to honour manual DNS settings even after a full network reset (Settings, General, Transfer or Reset, Reset Network Settings).
• Certificate trust settings are greyed out and can’t be modified — this can indicate a corrupted configuration profile or MDM enrolment.
• Safari crashes consistently when loading any non-standard TLD, which may point to a deeper WebKit bug worth reporting.
• iCloud Private Relay refuses to disable or re-enables itself after restart.

When you call or chat, mention the exact macOS or iOS version, whether the device is MDM-managed, and the steps you’ve already tried. That dramatically shortens the troubleshooting loop.

FAQ

Is .self an official top-level domain? Not yet in the IANA root zone. It’s a proposed TLD aimed at self-hosters, which is exactly why Apple devices need manual configuration to resolve it.

Why does Safari send my .self address to Google or DuckDuckGo? Safari treats unknown single-word or unrecognised-TLD entries as search queries. Type the full https:// URL to force navigation.

Will disabling iCloud Private Relay affect my privacy elsewhere? Private Relay only protects Safari traffic and unencrypted DNS. Disabling it on a trusted home network is reasonable; you can leave it on for cellular and public Wi-Fi.

Can I use .self on iOS without jailbreaking? Yes. Manual DNS settings, configuration profiles, and trusted certificates all work on stock iOS — no jailbreak needed.

Does the .self TLD work over cellular data? Only if you push a configuration profile that defines a DNS resolver reachable over cellular, typically via a VPN tunnel to your home network.

What’s the safest way to issue certificates for .self hostnames? Run a private internal CA, install its root on every device, and issue short-lived certificates from it. Public CAs won’t issue for .self because it isn’t a delegated TLD.