OpenVPN Connect 3.7.3 on iOS 27.0 fails to resolve DNS names

i42

As stated, OpenVPN Connect 3.7.3 on iOS 27.0. Server side is a aging Linux version: 2.4.12 on Rocky Linux 8.10.

From the server, we send:

push "dhcp-option DNS 192.168.37.51" push "dhcp-option DNS 192.168.37.50" push "dhcp-option DOMAIN example.local" push "dhcp-option DOMAIN-SEARCH example.local" push "route 192.168.37.0 255.255.255.0"

Everything works fine, from the iOS device I can ping, say, 192.168.37.51, and, if I access by IP, see the web server running on that same host. But if I try to go to host.example.local, which has a DNS entry, and resolves to an IP, I get an error.

An LLM believes it has to do with our ill-adviced choice of .local TLD in 2012, as this is used for mDNS/Bonjour in the Apple world.

It should be noted that before iOS 27, everything worked fine and as expected.

JosephS

Intersting.

I'll update to iOS 27 later tonight and see if there are issues with DNS.

I'll keep you posted.

With Regards,
JosephS

JosephS

After upgrading to iOS 27.0.1 I haven't noticed any differences in DNS behaviour when connected to VPN.

Internal host names are being resolved just fine.

Not sure about the multicast DNS take of the .local domain, why would it all of a sudden be an issue with iOS 27 on Apples end?

With Regards,
JosephS

Mohammad Montazeri

.local is a real compatibility consideration, but it does not establish that iOS 27 introduced this failure. Apple documents the potential conflict with unicast DNS here:
https://support.apple.com/en-us/101903

Joseph's successful test is useful — is his internal DNS suffix also .local?

For i42, first distinguish reaching the host from reaching its DNS service: ping and HTTP success do not establish that DNS queries succeed. While connected, use a DNS diagnostic that lets you explicitly query each pushed resolver for the same full hostname, then compare that with normal app resolution on the device.

If direct queries work but normal resolution fails, investigate the device's resolver selection, .local/mDNS handling and cached results. If direct queries fail, inspect DNS reachability and server responses first. Those results can guide the next check; they would not by themselves prove an OS bug.

Sharing just the outcome for "resolver 1" and "resolver 2" is enough to start; no logs, profiles or internal addresses are needed.

Disclosure: AI-assisted reply; I work on a VPN service.