Ich habe das Problem mal etwas weiter analysiert, und es gibt hier zwei Aspekte.
DNS
Das offensichtlich kaputte DNS Geobalancing führt dazu, dass man von einigen deutschen Resolvern (hier wurden ja schon DNSForge, dismail und DigitalCourage genannt) u.a. für iosapps[.]itunes[.]g[.]aaplimg[.]com die IP-Adresse 193.57.46.176, die in AS60159 (EUROLINE UKRAINE LLC) geroutet wird, zurückbekommt. Das könnte unter anderem damit zusammenhängen, dass die genannten Resolver zur Schutz der Privatsphäre ECS (EDNS Client Subnet) unterdrücken und somit die Lokalisierung fehlschlägt.
Nutzt man andere, gängige Resolver (Google, Cloudflare, AdGuard DNS), dann bekommt man i.d.R. IP-Adressen von Apple oder einem der großen CDNs (Akamai, Fastly, …) zurück.
In einem Test habe ich auf meinem lokalen Gateway die beiden DNS-Einträge iosapps[.]itunes[.]g[.]aaplimg[.]com und iosapps[.]itunes[.]apple[.]com (eigentlich ein CNAME auf iosapps[.]itunes[.]g[.]aaplimg[.]com) auf eine der entsorechendes IPs im Fastly-CDN (146.75.75.8) umgeschrieben. Infolgedessen funktionierten zumindest die Downloads aus dem AppStore ohne Probleme in gewohnter Geschwindigkeit.
Damit alle Apple-Services funktionieren, müsste man aber vermutlich noch etliche andere Einträge umschreiben. Darüberhinaus funktioniert dies auch nur, wenn man nicht das DNS-Profil verwendet, sondern z.B. die DNSForge-Resolver im lokalen Gateway als Forwarder einträgt, und die Apple-Devices dann das lokale Gateway per DHCP als DNS-Server zugewiesen bekommen. Das bedeutet allerdings, dass dies mobil nicht funktioniert (insofern man sich nicht noch irgendeine Behelfslösung mit einem VPN o.ä. baut).
Routing
Wenn man sich den Download von der IP-Adresse 193.57.46.176 im tcpdump anschaut, sieht man zum einen, dass es sehr viele Dplicated ACKs, TCP Out-of-Order Pakete sowie TCP Retransmissions gibt, die auf Packet Loss hindeuten. In meinem Test bekam ich für die Datenverbindung ingress ca. 30 Pakete/s mit je 1448 Bytes Payload, womit wir bei etwas 42KB/s landen, was wirklich jämmerlich ist.
Der Test erfolgte von einem Telekom-Anschluss, und das Verhalten war an anderen Telekom-Anschlüssen (DSL, LTE) reproduzierbar.
Schaut man sich das Routing zur Zieladresse an, sieht man, dass die Pakete von der Telekom (AS3320) über den (manchmal etwas zweifelhaften) Anbieter Cogent (AS174) zum Ziel-AS (AS60159) geroutet werden.
fw1# traceroute -IA 193.57.46.176
traceroute to 193.57.46.176 (193.57.46.176), 30 hops max, 40 byte packets
[...]
4 80.157.201.198 (80.157.201.198) [AS3320] 3.952 ms 3.730 ms 3.990 ms
5 be3186.ccr41.fra03.atlas.cogentco.com (130.117.0.1) [AS174] 3.662 ms 3.135 ms 3.579 ms
6 be2797.ccr41.ham01.atlas.cogentco.com (154.54.58.226) [AS174] 12.277 ms 12.481 ms 12.734 ms
7 be2483.ccr21.waw01.atlas.cogentco.com (130.117.51.61) [AS174] 25.028 ms 25.693 ms 26.146 ms
8 be2486.rcr21.b016833-0.waw01.atlas.cogentco.com (154.54.37.42) [AS174] 26.542 ms 25.901 ms 26.478 ms
9 149.6.70.58 (149.6.70.58) [AS174] 27.396 ms 25.566 ms 26.160 ms
10 * * *
11 * 194.146.188.225 (194.146.188.225) [AS60159] 39.039 ms 39.166 ms
12 * 193.57.46.134 (193.57.46.134) [AS60159] 38.982 ms *
13 193.57.46.176 (193.57.46.176) [AS60159] 41.371 ms 40.893 ms 40.875 ms
fw1#
Im mtr sieht man dann, dass der Packet Loss primär nicht unbedingt im Ziel-AS stattfindet, sondern im Cogent-AS bzw. zwischen Cogent und dem ukrainischen Provider.
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
[...]
6. be3186.ccr41.fra03.atlas.cogentco.com 0.6% 3085 4.1 5.3 3.3 82.4 8.4
80.157.201.198
7. be2797.ccr41.ham01.atlas.cogentco.com 0.1% 3085 13.0 12.8 3.3 120.3 8.2
be3186.ccr41.fra03.atlas.cogentco.com
8. be2483.ccr21.waw01.atlas.cogentco.com 0.0% 3085 25.4 24.9 12.6 79.5 5.6
be2797.ccr41.ham01.atlas.cogentco.com
9. be2486.rcr21.b016833-0.waw01.atlas.cogentco.com 0.0% 3085 26.0 26.1 24.9 85.5 5.9
be2483.ccr21.waw01.atlas.cogentco.com
10. 149.6.70.58 14.0% 3085 27.2 26.3 25.3 71.4 2.6
be2486.rcr21.b016833-0.waw01.atlas.cogentco.com
11. 149.6.70.58 92.2% 3085 26.8 26.9 25.9 53.3 2.6
12. 194.146.188.225 22.0% 3085 40.3 39.4 39.1 60.2 1.2
13. 193.57.46.134 15.1% 3085 41.3 39.6 39.1 57.4 1.2
194.146.188.225
14. 193.57.46.176 13.4% 3085 40.8 40.0 38.5 57.2 2.0
193.57.46.134
Wenn man sich einen traceroute von einem anderen Anschluss aus anschaut (hier exemplarisch Colt Telecom), sieht man, dass der AS-Pfad ein ganz anderer ist, bei dem Cogent nicht als Transit genutzt wird, sondern in diesem Fall Liberty Global B.V. (AS6830) und Arelion Sweden AB (AS1299).
fw2# traceroute -IA 193.57.46.176
traceroute to 193.57.46.176 (193.57.46.176), 30 hops max, 40 byte packets
[...]
6 de-fra11b-rc1-ae-48-0.aorta.net (84.116.130.61) [AS6830] 25.537 ms 25.949 ms 25.982 ms
7 pl-ktw01a-rc1-ae-24-0.aorta.net (84.116.137.49) [AS6830] 25.769 ms 25.999 ms 25.884 ms
8 hu-bud05a-rm1-ge-0-0.aorta.net (84.116.137.30) [AS6830] 26.216 ms 26.217 ms 25.558 ms
9 pl-waw02a-rb1-ae-1-1411.aorta.net (84.116.138.65) [AS6830] 25.498 ms 25.492 ms 25.427 ms
10 metroport-ic-356348.ip.twelve99-cust.net (62.115.151.191) [AS1299] 20.744 ms 20.612 ms *
11 185.165.149.131 (185.165.149.131) [*] 20.382 ms 20.383 ms 20.379 ms
12 * * *
13 194.146.188.225 (194.146.188.225) [AS60159] 33.744 ms 33.687 ms 33.788 ms
14 193.57.46.134 (193.57.46.134) [AS60159] 33.663 ms 33.396 ms 33.429 ms
15 193.57.46.176 (193.57.46.176) [AS60159] 36.259 ms 35.866 ms 35.852 ms
fw2#
Fazit
Das beobachtete Verhalten, scheint eine Kombination aus den beiden o.g. Sachverhalten zu sein, was auch erklärt, dass es bei einigen Usern mit DNSForge-Profil funktioniert und bei anderen wiederum nicht.
Ich mutmaße mal, dass die User mit den Problemen Telekom-Kunden sind, oder über andere Provider zumindest die Infrastruktur der Telekom nutzen oder die Telekom im Routing-Pfad haben, und die User ohne Probleme vermutlich andere Provider nutzen (O2, Vodafone, Unitymedia, etc.).
Wäre interessant zu wissen, ob meine These zutrifft - hier gab es ja schon User, die von keinerlei Problemen berichtet haben.
