Download Probleme bei Apple Geräten

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.

3 Likes

Ich würde sagen du hast das schön ausführlich ermittelt und ich bin da 100% bei dir.
Das muss Cogent klären und für dickere Leitungen sorgen bzw. den Übeltäter im Cogentnetz nullrouten.

Ja, bin Telekom Kunde ……

Bin auch Telekom künde und habe das Problem. Danke für die Analyse, auch wenn man da nicht direkt was ändern kann.

Echt nervig. Problem besteht ja leider immer noch.
Muss als Workaround bei Verbindung mit den Apple Servern jedesmal manuell anderen DNS hinterlegen ……

Bin schon am überlegen nach einer anderen Lösung zu suchen für mein Heim- und Mobilnetz :slightly_frowning_face:

Was denken die anderen betroffenen?

Habt ihr das mal an Apple reported? Macht doch dort mal nen Supportcase auf ! Dann können die sich mal kümmern und ihre Provider ansprechen.

Bei Apple bekam ich nur die Rückmeldung mich an meien DNS Anbieter zu wenden bzw. zu wechseln.

Ich teste jetzt mal Adguard DNS (öffentlichen) - bisher mal keine Probleme …… Wobei ich lieber hier bleiben würde ……

nein ihr dürft auch nicht sagen das ihr den und den DNS nutzt, ihr müsst dem Support mit dem Traceroute/MTR kommen und sagen das dort Probleme von Telekom zur Ukraine auftreten.

Dann müsste das jemand anderes übernehmen - ich hab leider auch überhaupt kein Sachverstand zu dem ganzen. Bei Rückfragen kann ich ja nichts dazu sagen ….