IOS 16 local dns not working

Both iOS native apps (Calendar and Files) and third party apps (Nextcloud) suffer from the same problem. This is a serious problem for a local development environment. Even Bonjour names won't resolve (ie: machineName.local).

Earlier I wrote:

Are you trying an app for iOS?

There’s a typo in there. I meant to say “Are you building an app for iOS?”

If this problem affects built-in apps then there’s not much I can do to help you out here. My focus is on supporting the APIs in our various platfrom SDKs, and if you can reproduce the problem in Safari then there are no APIs involved.

If you’re unhappy with how the system has changed here, I recommend that you file a bug about that.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I’ve been reporting this bug through the Feedback app since June when the beta first came out. It’s insane to think that it’s still there even in 16.2

I’ve been reporting this bug through the Feedback app since June

What was your bug number?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@eskimo I filed a bug over 2 years ago for ios14 and again when it appeared in 16. This is the bug number: FB8741956

It remains open. I have to say, this is a HUGE disappointment that Apple gives such a difficult time in getting help on such essential features as access to properly set up local dns resolutions. I have the new M2 iPad Pro with 16.1 installed and this problem is still there. One must ask why local dns used to work before 16, and still works without issue on Linux, Windows, Android, you name it? This is clearly an ios/iPadOS 16 issue. I ask here because after more than 2 years on feedbackassistant, my original bug was never addressed.

And, I’m sorry, but this affects developers who are developing for your platform when we’re trying to test things on a local network. So, if you could kindly refer me to who I can speak to , or which Apple site to get real help from, I’d appreciate it greatly.

I read through your bug report and it seems that you can reproduce this problem without any of your software installed. That is, you reconfigure the DNS using Settings and then reproduce the problem with built-in apps like Files.

Given that, I recommend that you escalate this with Apple Support.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The same thing happened to me, after upgrade to iOS 16 local dns stopped working. @Apple do you have plans to fix this problem? why do you keep making people suffer?

Hi there,

You might have better luck asking this question over in Apple Support Communities run by Apple Support.

I also had the same problem, this affected many internal services in my LAN. I have upgraded to IOS version 17, but the error is still not fixed.

Again, if you’re looking for help with the built-in behaviour of Apple systems, rather than with the APIs in our various SDKS, you need to escalate that via an Apple Support channel. As Sunny_Apple mentioned, a good place to start is Apple Support Community.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

it also not working on ios 17.1.2, hopeless

FYI: What I've seen by sniffing is that instead of a standard A record request (Type 1) they (Apple) have implemented a draft standard Type 65 query instead. This started sometime in the iOS 14 chain.

This smells a lot like what I've read above though I haven't read anyone actually root cause it. This is my experience, YMMV, usual disclaimers apply.

Most local DNS servers don't [yet] recognize this - after all, it is a draft standard - but Apple went ahead and implemented it anyway.

You can read the draft here:

https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-07.txt

What seems to happen - at least from the sniffing I've done - local DNS servers don't know what to do with the type 65 so they forward it to the rest of the internet assuming you are internet connected. iOS sometimes also issues a type 1 A request. The response from the rest of the internet must come back with at least something otherwise the name resolution - both of them - request fails.

In our case, we had to modify our local DNS server code to send a not found response back to the iOS devices. Then and only then will iOS listen to the A record that is also returned and process things like they used to before implementing this draft standard.

If the Type 65 request is not answered and the Type 1 is answered, the name resolution fails over to the next DNS server in the list.

I found a page at https://github.com/MikeBishop/dns-alt-svc/blob/main/svcb-implementations.md that talks about public services that are using this along with some local DNS servers that support the Type65 query draft standard.

Short version:

"iOS & macOS iOS 14 (September 2020) and macOS 11 (November 2020) support HTTPS/SVCB records. Type 65 (HTTPS) is requested for all URLSession or Network.framework connections that use an http or https scheme, or use ports 80 or 443."

You can check if this is what is biting you by sniffing the DNS requests between iOS and your local router; if you see the Type65 queries and fails or they go to a place that you don't want them to go to, then this is probably why your local DNS isn't working right..

So, Is Apple Developers/Support will fix this issue ? I remember having the same bug in the past and stop updating iOS on all devices, until they provide a new version. Now I guess this bug still exist from at least the latest 3 updates.