Apple services in Türkiye: DNS steering sends updates & Apple Music streams to a Kyiv edge (14–24 KB/s) — affected domains, routing evidence, and fixes

apple-tr-dns-routing-gist.md

Apple Services in Türkiye: DNS Steering Sends Updates, App Downloads & Music Streams to a Kyiv Edge (14–24 KB/s)

Measured 2026-07-29, Istanbul (Türksat Kablonet, 200 Mbps line). Apple has no update-CDN capacity in Türkiye, so the edge you get is chosen from your DNS resolver's egress geography. Cloudflare (1.1.1.1 / WARP / forwarders) strips EDNS Client Subnet, and Apple's geo-database mis-maps Cloudflare's egress to Ukraine — deterministically. Result: the seven bulk-transfer Apple domains below resolve to a Kyiv edge with ~13% packet loss, collapsing TCP to dial-up speed. This is loss-driven TCP collapse, not throttling — a Greek edge delivered ~186 Mbps on the same line minutes later.

Domain routing via Cloudflare-family DNS (WARP users included) — fully validated 2026-07-29

❌ Routed to Ukraine — 185.158.208.16 (Kyiv) — re-routing REQUIRED

Every one of these terminates on a *.g.aaplimg.com record (Apple's CDN) — the alias domain and its aaplimg record owner are listed, since both must be covered by any bypass:

Alias domain (what apps query)	Record owner (aaplimg terminal)	What it serves	Impact at 14–24 KB/s
swcdn.apple.com	swcdn.g.aaplimg.com	macOS update payloads	1 GB update ≈ 14 hours
mesu.apple.com	mesu.g.aaplimg.com	iOS update catalog	iPhones/iPads can't fetch update metadata
appldnld.apple.com	appldnld.g.aaplimg.com	IPSW / large restores	Multi-GB restores effectively impossible
osxapps.itunes.apple.com	osxapps.itunes.g.aaplimg.com	Mac App Store app downloads	Apps won't download/update
iosapps.itunes.apple.com	iosapps.itunes.g.aaplimg.com	iOS app (IPA) downloads	App Store downloads crawl (Apple Configurator/MDM too)
updates.cdn-apple.com	updates.g.aaplimg.com	App updates (cdn-apple)	Same starvation
aod.itunes.apple.com	aod.itunes.g.aaplimg.com	Apple Music full-track streams	1.3–6.4 s stall per connection → songs freeze mid-playback

Edge identity confirmed by Apple's own rDNS: dig -x 185.158.208.16 → giganet-uaiev1a-fe-003.ec.edge.apple. (GigaNet UA, uaiev1a = Ukraine/IEV Kyiv, .ec.edge.apple.).

⚠️ The mis-steered edge rotates: aod.itunes.g.aaplimg.com was observed at 185.196.12.16 (Bucharest, RO — also stall-prone: TTFB 0.44–2.36 s) and back at the Kyiv IP within the same day. Never hard-code these IPs anywhere — fix steering.

✅ NOT routed to Ukraine — validated in the same sweep

Domain	Terminal CDN	Lands on (via same Cloudflare DNS)
swdist.apple.com, fpinit.itunes.apple.com, configuration.apple.com, xp.apple.com	*.g/v.aaplimg.com	Apple 17.253.15.x — Frankfurt 🇩🇪 (aaplimg-terminal but correctly steered — the mis-mapping is per-cluster)
buy.itunes.apple.com	buy-eu.itunes.v.aaplimg.com	Apple 17.8.136.x — Frankfurt 🇩🇪
gdmf.apple.com	gdmf.v.aaplimg.com	Apple 17.x — US (rotated San Diego→Phoenix same day; tiny update-check JSON, fine)
swscan.apple.com, init.itunes.apple.com, itunes.apple.com, music.apple.com	Akamai e5977/e673	Istanbul 🇹🇷 (184.25.x) — rotates, sometimes Frankfurt
api.music.apple.com	Akamai e673.dscx	Istanbul 🇹🇷 (184.26.128.28)
play.itunes.apple.com (DRM lease)	Akamai a1806.dscw154	Vienna 🇦🇹 (rotates; was Milan earlier same day)
aod-ssl / audio-ssl / video-ssl.itunes.apple.com (previews)	Akamai e8374	Vienna 🇦🇹 (2.0–2.9 MB/s measured — fine)
itsliveradio.apple.com, a1.phobos.apple.com	Akamai	Vienna 🇦🇹
amp-api.music.apple.com, apps.apple.com, bag.itunes.apple.com, *.mzstatic.com	Fastly h3.apis.apple.map.fastly.net	Vienna POP 🇦🇹 (x-served-by: cache-vie…-VIE) — suboptimal vs Sofia, but functional

Pattern: the Kyiv mis-steering hits exactly the bulk-transfer payload hosts (OS updates, app downloads, music streams). API/web/DRM/artwork stay in the EU.

Why re-routing is needed (root cause)

1. No Apple update-CDN in Türkiye → edge choice is 100% resolver-egress geography (a resolver lottery).
2. Cloudflare strips EDNS Client Subnet (documented); Apple's geo-DB maps Cloudflare's Istanbul egress (104.23.x) to Ukraine. Querying 1.1.1.1 directly and through a LAN forwarder returned the identical Kyiv IP — every Turkish Cloudflare-DNS user is affected the same way. Quad9 9.9.9.9 and NextDNS are also affected (they egress via an Istanbul datacenter, EdgeUno 185.40.106.x — physically in Istanbul, still mis-mapped to Kyiv).
3. The Kyiv path itself is broken for bulk transfer: 15 hops / ~85 ms with ~13% packet loss (war-degraded transit). TCP throughput ceiling ≈ MSS/(RTT·√loss) ≈ 47 KB/s — measured 14–24 KB/s, vs 23.3 MB/s (~186 Mbps) via the Greek edge and 11.7–22.8 MB/s via Apple's own EU edges, same line, same file, same minute.

The fix

Consumers: use a resolver with a truthful local egress or ECS support —

• AdGuard DNS 94.140.14.14 / 94.140.15.15 (Istanbul PoP; unfiltered: 94.140.14.140/.141) — steers all seven domains to Apple's own EU edge (~0.15 s TTFB, 19–23 MB/s).
• Google 8.8.8.8 / 8.8.4.4 (sends ECS) — steers them to the Greek edge (~186 Mbps).
• Avoid in Türkiye: Cloudflare (all variants incl. Family 1.1.1.2/.3 and DoH forwarders), Quad9 9.9.9.9 (use ECS variant 9.9.9.11 instead), NextDNS default.

Corporate (Cloudflare WARP/Gateway):

1. DNS policy / Local Domain Fallback: resolve apple.com, aaplimg.com, mzstatic.com, cdn-apple.com, icloud.com via Google/AdGuard — this kills the Kyiv IP at the source (verified: WARP's Cloudflare DNS resolved aod.itunes.apple.com → Kyiv; song froze mid-playback at 14–24 KB/s through the tunnel; WARP-off + Google DNS instantly recovered).
2. IP-based split-tunnel exclusion: 17.0.0.0/8 (Apple's ASN block) — domain-based exclusion alone proved leaky in production (CNAME-terminal *.aaplimg.com/Akamai IPs slipped into the tunnel).
3. Domain exclusions: apple.com, mzstatic.com, cdn-apple.com, icloud.com, icloud-content.com — and aaplimg.com is REQUIRED, not optional: the Kyiv/mis-steered DNS answers are owned by *.g.aaplimg.com names (the apple.com hosts are just CNAME aliases), so a bypass that only matches apple.com leaks exactly the payload traffic that matters. Production-confirmed: adding aaplimg.com to the Cloudflare bypass/DNS policy was the final fix at a company running WARP.
4. Do not hard-IP swcdn.apple.com/185.158.208.16 anywhere — edge assignments rotate (Kyiv↔Bucharest observed within a day); fix steering, not IPs. Exclude Apple traffic from Gateway TLS inspection (AVPlayer cert-pins).

Self-check (2 seconds):

dig +short swcdn.apple.com        # 185.158.208.16 = broken (Kyiv) · 5.172.192.208 = OK (GR) · 17.x = best (Apple EU)
dig +short aod.itunes.apple.com   # same rule — this is the Apple Music streaming host
dig +short osxapps.itunes.apple.com   # App Store downloads — same rule

Evidence appendix (abridged)

• Resolver egress seen by CDNs (dig +short whoami.akamai.net @<resolver>): Cloudflare forwarder → 104.23.182.137 (Cloudflare Istanbul, no ECS) → Kyiv · AdGuard 94.140.14.14 → 207.211.215.145 (Datacamp Istanbul) → Apple EU · Google → Milan egress but sends ECS → Greece ✅ · Quad9/NextDNS → 185.40.106.x (EdgeUno Istanbul, no ECS) → Kyiv.
• Throughput (real 222 MB Apple update payload, curl --resolve): Kyiv 185.158.208.16 → 23.7 / 13.9 KB/s · Greece 5.172.192.208 → 23.3 MB/s · Apple EU 17.253.x → 11.7–22.8 MB/s.
• Music stream edge (aod.itunes.apple.com, TTFB to edge): Kyiv → 1.29–6.39 s every run · Greece → 0.129–0.133 s · Apple EU → 0.150–0.155 s · Bucharest (rotated) → 0.44–2.36 s.
• Fastly POP confirmation: x-served-by: cache-vie6334-VIE via Cloudflare vs cache-sof1510028-SOF (Sofia, nearest) via AdGuard.
• Traceroutes: Kyiv 15 hops/~85 ms via Arelion→Ukrainian segments · Greece ~51 ms · Apple EU ~56 ms via Superonline→Apple private backbone (17.1.3.x).
• WARP production case: domain bypass *.apple.com+*.icloud.com applied; audio stream still ran through the tunnel to 185.158.208.16 (source IP 100.96.18.3 = CGNAT/WARP), froze when the bypassed side-connections finished; retries kept hitting Kyiv. Final fix: DNS policy covering aaplimg.com + 17.0.0.0/8 IP exclusion.

Full methodology + reproducible commands available on request. Vantage point: Istanbul / Türksat Kablonet — re-verify from your own line with the self-check above.