Bonsoir, j'espère ne pas faire un sujet en double (?). Je vais tenter de vous expliquer le problème que je rencontre depuis que je suis abonné à Orange (Fibre & Mobile).

Pour info je suis sous MacOs Sierra 10.12.3 en Wifi 5 ghz (testé également en Ethernet et Wifi 2,4 ghz pour ce que je vais évoquer ci-dessous).

Je m'explique : j'ai changé, tel que je le faisais avant chez Free (également en fibre optique), les DNS d'Orange par ceux de Google : aucun souci pour la navigation ni les téléchargements en général SAUF pour tout ce qui transite par l'App Store : aussi bien les mises à jour que le téléchargement d'applications.

J'ai testé plusieurs autres DNS tels que FDN, OpenDNS, LDN, etc, etc... Même problème ! Dès que je remets les DNS Orange les téléchargement sur l'App Store redeviennent rapides.

Je n'ai pas pris de mesures réelles dans ce cas précisèment. Cela dit, pas besoins d'être ingénieur pour constater l'énorme différence de débit entre des DNS alternatifs et ceux d'Orange concernant l'App Store... Petite anecdote, en testant les DNS de LDN je n'ai même pas pu me connecter à l'App Store (je parle du login). En remettant ceux d'Orange, ça marche.

Un exemple "parlant" : en téléchargeant une application de 110 Mo sur l'App Store via les DNS Orange ça prend 3/4 secondes (je suis en 200 mbps). Avec les DNS alternatifs le temps donné est de 9 minutes...

Autre détail qui correspond à l'exactitude avec la problématique suscitée mais cette fois sur iOS (j'ai testé avec un iPhone 6 et iPad Mini 4) : j'ai changé les DNS Orange et le même phénomène se produit, et donc, uniquement sur l'App Store; y compris avec des applications tierces telles qu'Opera VPN et/ou Adguard Pro et son mode VPN. Dans les 2 cas ces applications (il en existent quelques autres sur l'App Store iOS) modifient les DNS de l'iPhone.

Une idée ?

EDIT : je viens de tester avec l'application DNSCrypt (excellente de surcroît) et seuls quelques serveurs DNS (très peu malgré la longue liste) permettent le téléchargement à plein régime sur l'AppStore. Autrement dit, les autres DNS alternatifs ont quasiment tous le même souci de lenteur excessive sur l'App Store.

Ok... Donc il semblerait que le "bridage" soit du côté d'Apple ?

D'accord je vois Enfin bon c'est pas le drame, on ne fait pas des mises à jour tous les jours mais bon... A la rigueur en utilisant un outil comme DNSCrypt ça facilite la tache puisque qu'on peut activer/désactiver les DNS par un simple clic.

Dans tous les cas merci pour les explications

Avec un resolveur tiers, on peut perdre de l'information et être orienté vers un noeud pas forcèment le plus près au niveau réseau...

On peut même être plus précis: quand on utilise autre chose que le DNS de son FAI, on a très souvent des performances moisies avec les CDN (donc pour l'énorme majorité du trafic des utilisateurs lambdas).
Pour être servi par les serveurs, les clusters, les peerings les plus proches, les plus efficaces et les moins chargés, il n'y a pas le choix.

Les conseils contraires sur le sujet sont mal avisés.

Ca n'est plus trop vrai quand meme

C'est le cas général.

Et y'a des techniques comme EDNS pour améliorer les choses.

Il y a la RFC 7871 qui a quelques mois, donc dont les implèmentations sont encore rares (Google) - et il faut que ce soit implèmenté coté resolvers et coté CDN.

La c'est juste Apple qui fait pas "robuste" (ou c'est un problème propre a Orange...).

Apple fait comme tout le monde (les autres CDN), c'est tout: en gros, l'IP du serveur et sa proximité avec le client vont dépendre du résolveur récursif DNS qui interroge ses serveurs DNS faisant autorité.


Pour des raisons idéologiques (quand on lit des foutaises sur des histoires de "pureté des résolutions de nom" il y a de quoi rester perplexe) ou d'incompréhension technique, certains conseillent ou utilisent même des DNS sans rapport avec leur réseau, lointains ou non largement anycastés, etc... donc le pire des cas.

Les meilleures performances sont obtenues avec les DNS du FAI ; c'est absurde de se tirer des balles dans le pied avant même tout transfert de donnée.