iphone 13 dns issue sinds september 2022

Note that there is another possibility; Safari on iOS (since iOS 14) now follows the draft RFC that will ask DNS servers for a type 65 HTTPS record and will preferentially use that to an A or AAAA record.

If the Cisco does not rewrite type 65 requests, the record for the external host from Google will be used instead of the rewritten A or AAAA record that the firewall theoretically returns.

If you have access to a system that should be seeing the internal address, you can try doing a:

dig -t TYPE65 <camera hostname>

and check for a NOERROR rather than NXDOMAIN response.

If the Cisco doesn't recognize/rewrite type 65 requests and just passes them upstream, requests may just be forwarded upstream resulting in the behavior you see.

Look for differences in the way that the 7 and the 13 are set up in Wi-Fi

Try turning off Private Address in the wifi settings on the iPhone.

Does anyone have an iPhone 13 still on iOS15? iOS16 had more advanced security.

Anyone using VPN? App store VPNs can cause havoc. Corporate VPNs should cope but not always.

In the end you may have to rethink the setup if the problem is repeated along lines of iOS15 vs iOS16

Note the type 65 DNS lookup was found to break DNS filtering on many "safe browsing" products and open source utilities like dnsmasq had to be modified to deal with it, again meaning your Cisco might not support it or might require a firmware update to do so.

I know this gets a bit complex, but the bottom line is for many filtering/rewriting scenarios, because the request isn't an A or AAAA the request gets sent upstream and public data is returned rather than the rewritten private data desired.

I don't know which version of iOS your iPhone 7 is running, but this change was made in iOS 14 and macOS 11 Big Sur.

OK, then the next thing to check is whether the Cisco ever sees a DNS request come in from the iPhone for the camera's hostname and what it returns as the answer.

• If it doesn't see it, someone else is intercepting the response and is returning cached data instead.
• If it does see it, is it responding with the proper address for a host behind the firewall? If not, why doesn't the Cisco recognize it?

Your user also might want to try toggling Airplane Mode on their iPhone, as that will clear the iPhone's local DNS cache.

Is there anything else on the network that could be cacheing the DNS request?

Certainly the customer should be able to check the logs on their Cisco to see if a DNS request is ever actually received by the firewall or if another device on their network is returning a cached answer instead of forwarding the request.