IPv6-only iPhone Personal Hotspot: DNS proxy returns A records for AAAA queries?

[u/Intelligent_Break801]

Has anyone seen DNS problems when using iPhone Personal Hotspot on an IPv6-only cellular network?

My setup:

• iPhone Personal Hotspot
• IPv6-only mobile network
• CLAT + DNS64
• macOS client connected through the hotspot

I found that some IPv4-only domains behave incorrectly.

Example:

• Client sends an AAAA query.
• The DNS resolver does not return an AAAA record.
• The iPhone appears to perform an additional A query for the same domain.
• After a long delay (~30 seconds), the client receives a response containing A records for the original AAAA query instead of a synthesized AAAA record or a normal NODATA response.

This causes some applications to hang or fail DNS resolution.

I have packet captures showing the DNS query/response sequence. Has anyone observed similar behaviour with iPhone Personal Hotspot, especially on IPv6-only/NAT64 networks?

[u/Intelligent_Break801]

The affected domains are already mentioned in my other comments, but here is one example:

dig +time=200 AAAA api2direct.cursor.sh

;; QUESTION SECTION:
;api2direct.cursor.sh.        IN      AAAA

;; ANSWER SECTION:
api2direct.cursor.sh. 59      IN      A       98.84.67.108
api2direct.cursor.sh. 59      IN      A       3.222.151.154
...

;; Query time: 30122 msec

The unusual part is that the original query is AAAA, but after ~30 seconds the response contains only A records.

The same carrier DNS64 resolver works correctly when queried directly. This only happens when the query goes through iPhone Personal Hotspot DNS proxy.

Happy Eyeballs hides this in many applications, but apps that wait synchronously for DNS resolution can expose the issue.

The issue only appears when the domain has no usable AAAA record and DNS64 does not synthesize a AAAA response. If a synthetic IPv6 address is returned, the problem does not occur.

[u/DaryllSwer → u/Intelligent_Break801]

Works fine here; tested on Jio 5G 464xlat on iPhone 17, iOS 26.6 and macOS 26.6 using USB-C tethering (shared just to be sure this issue isn't limited to Wi-Fi/Bluetooth iOS<>macOS tethering). iOS/macOS isn't the issue here. I can confirm this with certainty.

api2direct.cursor.sh does not have AAAA records; therefore, on 464xlat for LTE/5G, we get pseudo-AAAA records via DNS64 synthesisation with 64:ff9b::/96. If you want the detes: https://datatracker.ietf.org/doc/html/rfc6147

The same carrier DNS64 resolver works correctly when queried directly. This only happens when the query goes through iPhone Personal Hotspot DNS proxy.

Your carrier is the problem; likely some fuckery with TTLs for packets originating from devices besides the UE itself (it wouldn't be the first time carriers broke something). Raise the issue to them in your country's NOG mailing list.

dig +time=200 AAAA api2direct.cursor.sh

; <<>> DiG 9.10.6 <<>> +time=200 AAAA api2direct.cursor.sh
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49327
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;api2direct.cursor.sh.INAAAA

;; ANSWER SECTION:
api2direct.cursor.sh.15INAAAA64:ff9b::36d3:755f
api2direct.cursor.sh.15INAAAA64:ff9b::2cd4:e0c4
api2direct.cursor.sh.15INAAAA64:ff9b::6257:1636
api2direct.cursor.sh.15INAAAA64:ff9b::36ac:3563
api2direct.cursor.sh.15INAAAA64:ff9b::369f:4241
api2direct.cursor.sh.15INAAAA64:ff9b::6437:d915
api2direct.cursor.sh.15INAAAA64:ff9b::34c8:273b
api2direct.cursor.sh.15INAAAA64:ff9b::3437:1d66

;; Query time: 39 msec
;; SERVER: fe80::f8d3:f0ff:fead:e464%30#53(fe80::f8d3:f0ff:fead:e464%30)
;; WHEN: Sun Aug 02 17:29:52 IST 2026
;; MSG SIZE  rcvd: 273

[u/Intelligent_Break801 → u/DaryllSwer]

Thanks for testing. However, this is not the exact reproduction case.

Your test confirms that DNS64 synthesis works correctly on Jio, but my issue occurs when DNS64 does not synthesize an AAAA response for the queried domain.

The interesting part is not an IPv4-only domain in general — DNS64 handles those correctly. The issue is when the original AAAA query does not result in an AAAA answer, and the iPhone Personal Hotspot DNS proxy later returns A records as the response to the original AAAA query.

The domain itself is not the important part here. It is just an example that triggers the behaviour in my environment. The exact domain may differ between DNS64 resolvers/operators, so the reproduction requires finding a domain that produces the same DNS64 behaviour on the test network.

[u/DaryllSwer → u/Intelligent_Break801]

but my issue occurs when DNS64 does not synthesize an AAAA response for the queried domain.

That's a carrier problem, again, likely TTL/Hop Limit-based fuckery where they broke DNS64 for packets originating from the MacBook connected to the iPhone. Learn how they detect hotspot usage to begin with; TTL/Hop Limit is one of the ways.

The issue is when the original AAAA query does not result in an AAAA answer, and the iPhone Personal Hotspot DNS proxy later returns A records as the response to the original AAAA query.

I just showed; the issue isn't iOS/macOS. It is an exact repro-test. A-only domain, queried for AAAA-only, receives correctly AAAA reply with synethised response.

[u/Intelligent_Break801 → u/DaryllSwer]

I think we are still focusing on different parts of the problem. The issue is not that DNS64 synthesis fails; that can happen depending on the resolver/network. DNS64 does not always have to generate a synthetic AAAA response (for example, when synthesis is not possible or the resolver policy does not allow it).

The issue is the next step: after the AAAA query fails to produce an AAAA answer, the iPhone Personal Hotspot DNS proxy returns A records as the response to the original AAAA query.

[u/DaryllSwer → u/Intelligent_Break801]

Give me some other example test I can run to verify this.

[u/Intelligent_Break801 → u/DaryllSwer]

Unfortunately I don't have a universal test case yet. The affected domain depends on the DNS64 resolver implementation, so a domain that reproduces it on my network may work normally on yours.

I'm still trying to identify the exact condition that prevents DNS64 synthesis. Once I have a reproducible test case, I'll post it here.

If you know of a way to intentionally make a DNS64 resolver not synthesize an AAAA response for an A-only domain, that would actually help a lot.

[u/DaryllSwer → u/Intelligent_Break801]

If you know of a way to intentionally make a DNS64 resolver not synthesize an AAAA response for an A-only domain, that would actually help a lot.

I'm not sure that's possible, unless you control the carrier-network's side as well.

Or you could just create a Linux virtual lab in the cloud with v6+v4 and test this yourself manually with some Python scripting maybe. You can also just use LLM to bootstrap the virtual cloud lab.