iOS DNS Shenanigans: A Tale of Unnecessary Complexity

I have a simple need: access a few new home lab-hosted internal services by hostname from family iPhones and computers instead of remembering IP addresses. What should be a trivial DNS configuration turned into a several-hour rabbit hole that taught me more about iOS’s peculiar DNS behavior than I ever wanted to know.

The Setup

I run internal services (AI endpoints, proxies, etc.) on my home network at 192.168.10.201. I own hansley.xyz and wanted to access them via subdomains like ai.hansley.xyz from all devices, including my iPhone.

The obvious solution: set up local DNS records. I have a Ubiquiti UDM Pro handling my network, so I figured I’d use its built-in DNS features.

Spoiler alert: that didn’t work.

Down the Pi-hole

The UDM Pro’s lightweight DNS couldn’t handle what I needed, so I set up Pi-hole as my primary DNS server. Pi-hole version 6+ uses its own DNS resolver instead of dnsmasq, configured via a TOML file rather than traditional config files.

I configured Pi-hole to be authoritative for hansley.xyz:

hosts = [
  "192.168.10.201 ai.hansley.xyz",
  "192.168.10.201 llm.hansley.xyz", 
  "192.168.10.201 proxy.hansley.xyz"
]
domain = "hansley.xyz"

This worked perfectly from my Mac. DNS queries for my subdomains returned the private IP instantly with no upstream leakage. Non-existent subdomains got immediate NXDOMAIN responses.

From my iPhone? Nope.

The iOS Problem

Testing nslookup ai.hansley.xyz from my iPhone gave me this contradictory nonsense:

Server:         192.168.10.205
Address:        192.168.10.205:53

Name:   ai.hansley.xyz
Address: 192.168.10.201

Non-authoritative answer:
*** Can't find ai.hansley.xyz: No answer

iOS was simultaneously resolving the domain correctly AND claiming it couldn’t find it. Safari confirmed the problem: “Safari can’t open the page because the server can’t be found.”

The Red Herring: gTLD Discrimination

My first hypothesis was that iOS discriminates against newer gTLDs like .xyz. I tested with other domains I owned – a .net and .com that weren’t API-friendly for DNS-01 certbot use but worked fine for testing. Same contradictory behavior across all TLDs.

This ruled out gTLD discrimination entirely. The problem was something deeper.

The Real Issue: Authoritative Server Validation

After more testing, I realized the issue wasn’t iOS rejecting private IP addresses in DNS responses. The problem was iOS being suspicious of private DNS servers claiming authority over public domains.

When Pi-hole (at private IP 192.168.10.205) claimed to be authoritative for hansley.xyz, iOS showed the contradictory “Can’t find” behavior even though it was getting and using the correct response.

But when the same private IP (192.168.10.201) came from legitimate public nameservers, iOS accepted it without complaint. The resolved IP address was identical – only the authoritative source differed.

The Simple Solution

After all this complexity, I tried the most straightforward approach: configuring ai.hansley.xyz to return 192.168.10.201 in my actual public DNS at my registrar.

This works perfectly:

From inside my network: resolves to private IP, everything works
From outside my network: resolves to private IP, but private IPs aren’t routable from the internet anyway
iOS stops complaining because it’s getting the response from “legitimate” public DNS

The internal service IPs are visible in public DNS, but for a 2-person household this is a non-issue.

The Twist Ending

Even with the working solution, iOS still shows the contradictory error message:

Name:   ai.hansley.xyz
Address: 192.168.10.201

Non-authoritative answer:
*** Can't find ai.hansley.xyz: No answer

But now Safari actually loads the page. iOS is complaining about something that works perfectly fine.

Lessons Learned

iOS has undocumented DNS validation that goes beyond simple resolution
Apple’s privacy features (DNS-over-HTTPS, Private Relay, tracking protection) can interfere with local DNS configuration in unpredictable ways
Sometimes the simplest solution works best – public DNS with private IPs bypassed all the local complexity
Error messages can be misleading – iOS says it “can’t find” domains that it’s successfully using

The Broader Issue

This experience highlights a frustrating trend in consumer technology: devices that are “smart” enough to second-guess their users but not smart enough to get out of the way when the user knows what they’re doing.

I have a legitimate use case, I own the domain, I control the network, and I know exactly what I want to accomplish. But iOS decided to be “helpful” by implementing undocumented validation that breaks perfectly valid configurations.

I get that part of that “helpfulness” is security. I get that iOS’s behavior protects against some malicious agent on a network where they can claim – via DHCP – to be the authoritative DSN for google.com, or wellsfargo.com, or the like. Security by default is good.

The workaround is simple enough, and it’d’ve been good to have an Apple-provided solution – maybe a ☑ This is a Trusted Network setting. Local network administration used to be straightforward. Now it requires working around security assumptions baked into devices about what constitutes “proper” DNS behavior.

At least my services are accessible now, even if I’m breaking RFC 1918‘s guidance about putting private class-B IPs in public DNS records. If there’s a way to solve this that I haven’t tried, I’m open to suggestions.

If you’re facing similar iOS DNS issues, try putting your private IP records in public DNS rather than fighting with local DNS configuration. Sometimes the path of least resistance is the right engineering choice.

Bill Hansley