Unable to install iPhone apps using Orbi RBE771

FURRYe38
Guru - Experienced User
Apr 20, 2025
Let us know if changing the DNS recourse helps. Try using Cloudfare or Quad9.

What is the Mfr and model# of the Internet Service Providers modem/ONT the NG router is connected too? Call up the ISP and ask them for this information.

Any of these enabled on the Orbi system?

Armor, IPv6, Smart Parental Controls or Circle, Traffic Meter.

Be sure to disable any MAC Address randomizers on phones and pads while at home:
https://community.netgear.com/t5/Orbi-App/NETGEAR-Mobile-Applications-and-Apple-Devices-FAQ/td-p/2220016/jump-to/first-unread-message
- donawalt
  Mentor - Experienced User
  Apr 20, 2025
  I re-read the thread, and I don't see this - how exactly does the download fail - hang forever? error message? something else? And you didn't say, do all other internet actions work fine on WiFi except the apple store - browser works fine, mail, music, streaming, etc.?
  - donawalt
    Mentor - Experienced User
    Apr 20, 2025
    OK I have been digging into this - so fun! I have a theory that I think may be the cause. I have a LONG explanation and a very short recommendation on how to fix it - which you can skip to if the details are too much to handle!
    
    If I understand all my reading...
    
    Apple distributes apps via a heavily load‑balanced content delivery network ("CDN"; for Apple, mostly Akamai), often preferring IPv6 endpoints and large HTTPS/QUIC transfers. Many—but not all—Akamai edges that serve .itunes.apple.com offer both A (IPv4) and AAAA (IPv6) dns query records. If your DNS query lands on one of those hosts, the resolver returns both addresses.
    
    Some edge hostnames rotate to an IPv4‑only POP, so the resolver quite correctly returns an empty (NOERROR ∣ NODATA) AAAA answer and a normal A answer. That’s perfectly valid DNS; it just means “no IPv6 here right now.” CDN operators do this constantly as they shift traffic around the globe. I suspect your ISP does this.
    
    Now, I see a number of threads over the years regarding bugs with the Netgear router's dnsmasq forwarder/cache (what receives and forwards dns queries from LAN clients) - not necessarily the 771, but could be there? I have also read that the RBE771 ships with a built-in DNS proxy that advertises IPv6 first, while I presume the R6300v2 router does not given its age - it may not even use IPv6 at all?
    
    So my theory is this: a RBE771 bug lives in its dnsmasq forwarder - its 'dnsproxy'. When a domain has no IPv6 address (including no address 'at the moment' as I explained above), an upstream resolver correctly returns NOERROR / NODATA – that is, “the name exists, but the answer section is empty.” This is sometimes called an "empty AAAA query record". That response is standards‑compliant (RFC 2308) and is what you’ll see from any well‑behaved resolver, whether it’s your ISP, Google DNS, or Cloudflare. Nothing is “bad” or “broken” about it.
    
    My alleged bug in the 771 router is that when it receives that paired response—A record plus an “empty” AAAA—it mis‑caches or mangles the two when it fuses them into its local cache. There have been hints of this in older firmware release notes.
    
    So this mangled result is sent to the iPhone, which sees a malformed AAAA (or a garbled TTL) and, per RFC 6724, tries the IPv6 route first (iPhones always do). That route either doesn’t exist or points to nowhere, so the TCP handshake for the multi‑gigabyte app payload just hangs.
    
    So to me, the workaround fix is one of two things - bypass the router's dnsproxy (which is mangling the AAAA query record), or get it to stop using IPv6 for dns queries (also eliminating AAAA records and their mangling).
    
    Once this is understood, it makes sense - you see the bug on the Apple Store (and maybe it would show some other large CDN sites); it can still resolve apple.com and load normal websites (small objects over IPv4 without the rotating/load balancing of the large CDN sites) but stall on the multi‑gigabyte app packages downloaded from large CDN hosts. The moment you switch to cellular, both the router's dnsproxy and its IPv6 path to the ISP's DNS resolver are removed from the transaction. It works.
    
    So please try this, in this order:
    
    1. Point the router's DNS at 1.1.1.1 or 8.8.8.8 - the 771 router's dnsproxy will still rewrite the packet. If the bug is purely in the proxy's handling of empty AAAA replies, this should fix the hang. Why? Changing only the upstream DNS on the router fixes things because Google/Cloudflare almost never send the “empty AAAA + valid A” combination that causes the bug on the 771's dnsproxy rewrite, from what I have read. But it still relies on the proxy behaving, so it's not a guarantee this fixes it.
    
    2. If it still hangs - disable IPv6 on the router and reboot it. Now the proxy can only return A records, so the iPhone never tries the using IPv6 for queries as they are no longer supported on the network.
    
    You can also test by changing DNS on the iPhone to 1.1.1.1 or 8.8.8.8, and bypass the router entirely. This will accomplish the same thing as step 1 and 2 before you mess with the router. If it works, you can then make the proper changes on the router, or continue to use to local DNS 'fix' on each mobile device that needs it.
    
    Please try this, it's simple to test - and let us know if it fixes the problem!

Forum Discussion

Unable to install iPhone apps using Orbi RBE771