La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Installation fibre Free => Discussion démarrée par: Ilovelinux68 le 05 mai 2025 à 11:22:32
-
Bonjour à toutes et à tous,
Je ne suis pas certain que mon sujet soit parfaitement à sa place ici, car il n'est pas strictement lié à Free. Si c'est le cas, je m'excuse par avance auprès de la modération.
J'ai une question concernant l'optimisation de la connexion internet, et plus particulièrement le rôle des serveurs DNS.
Est-il préférable d'utiliser les serveurs DNS de son FAI pour bénéficier du meilleur routage possible et donc, potentiellement, de meilleures performances d'accès aux sites web et services ?
Je comprends bien qu'un serveur DNS a pour rôle principal de traduire un nom de domaine.
Ma question est la suivante : les serveurs DNS des FAI vont-ils plus loin ? Est-ce qu'ils sont configurés pour retourner des adresses IP spécifiques, peut-être celles de serveurs (comme les CDN) situés plus près de l'utilisateur ou sur des chemins réseau optimisés par le FAI lui-même, afin d'améliorer la latence ou le débit ? Autrement dit, ces DNS "orientent-ils" subtilement le trafic pour optimiser le chemin au sein du réseau de l'opérateur ?
Ou bien, est-ce que l'utilisation de n'importe quel serveur DNS public réputé (comme ceux de Cloudflare à 1.1.1.1, Google à 8.8.8.8, Quad9 à 9.9.9.9, etc.) donnera des performances globalement similaires ?
En bref : le choix du DNS a-t-il un impact significatif sur le chemin emprunté par mes données sur Internet, au-delà de la simple traduction nom de domaine <-> IP ?
Merci d'avance pour vos éclaircissements !
-
En bref : le choix du DNS a-t-il un impact significatif sur le chemin emprunté par mes données sur Internet, au-delà de la simple traduction nom de domaine <-> IP ?
Il peut, oui.
Les CDN et autres gros sites aiguillent parfois le trafic de l'utilisateur vers un serveur proche en fonction de l'adresse IP source du résolveur DNS, en partant du principe que le client sera sur le même réseau... ce qui ne tient pas si le client utilise un DNS hors de son réseau, bien sûr.
Le protocole DNS a été étendu avec une extension "client subnet" pour ajouter le subnet du *client* et permettre un meilleur aiguillage et résoudre ce problème, mais:
- tous les résolveurs DNS publics ne le supportent pas (CloudFlare par exemple),
- tous les CDN n'utilisent pas cette info,
- certains CDN font de l'anycast, et donc n'utilisent pas le DNS pour aiguiller les utilisateurs vers un serveur plus proche,
- seuls les gros acteurs, finalement, disposent de l'infra pour rapprocher le contenu des utilisateurs.
Donc je pense qu'il y a un impact théorique, mais qu'en soit il est soit imperceptible, soit très faible.
Question subsidiaire : quel intérêt à utiliser un DNS tiers plutôt que le cache local (box et/ou cache dans le réseau du FAI) ? Envoyer son trafic DNS à Google ou CloudFlare n'est, selon moi, pas neutre.
La latence de résolution DNS ajoutée par l'utilisation d'un serveur situé sur un autre réseau est probablement insignifiante elle aussi quand tout fonctionne bien (quelques ms-10ms max), mais en cas de souci de routage entre le FAI et ce réseau (congestion ou incident de routage), on peut avoir une indisponibilité.
-
Question subsidiaire : quel intérêt à utiliser un DNS tiers plutôt que le cache local (box et/ou cache dans le réseau du FAI) ? Envoyer son trafic DNS à Google ou CloudFlare n'est, selon moi, pas neutre.
Personnellement, j'utilise un bon AdGuard Home pour me permettre de supprimer certaines publicités sur les jeux mobiles. En plus de faire du cache en local, derrière cela, c'est le DNS https://www.dns0.eu/fr qui utilise la technologie EDNS anonymisé pour accélérer les diffusions vers les CDN. Dans ce cas-là alors, utiliser le DNS du FAI ne sert à rien si l'EDNS permet en effet d'utiliser les bons CDN ?
-
Bonjour,
je ne suis pas un expert des DNS, néanmoins dans un domaine particulier j'en utilise des différents du reste de la panoplie pour gagner jusqu'à 2 minutes au démarrage et jusqu'à beaucoup à l'heure, celui de mes "engins" qui servent à regarder la télévision.
Mes Firestick Amazon utilisent 94.140.14.14 et 94.140.15.15, que ce soit TF1+ ou France TV, M6+ ou BFMbidule, j'y gagne un temps fou.
-
J'ai pihole qui tourne direct sur ma Delta dans une VM, et les champs DNS de la Freebox, ipv4 comme ipv6, pointent dessus.
Les sources sont Google, Cloudflare, et FDN. Ça choisit aléatoirement entre les 3.
Aucun problème, que ce soit d'accès ou de lenteur. mafreebox.freebox.fr fonctionne.
-
J'ai pihole qui tourne direct sur ma Delta dans une VM, et les champs DNS de la Freebox, ipv4 comme ipv6, pointent dessus.
Les sources sont Google, Cloudflare, et FDN. Ça choisit aléatoirement entre les 3.
Aucun problème, que ce soit d'accès ou de lenteur. mafreebox.freebox.fr fonctionne.
J'ai pas non plus de lenteur. La n'est pas la question 8) c'est plus une question technique et une question pour ma culture général !
-
Ma question est la suivante : les serveurs DNS des FAI vont-ils plus loin ?
Oui, ils font aussi du filtrage pour interdire l'accès à des sites non autorisés :
--> phishing, malware
--> parentale (violence, pornographie).
--> gouvernementale.
--> entreprise (blocage de streaming, réseaux sociaux).
D'où l'usage d'autres serveurs DNS qui ne filtrent pas.
-
Oui, ils font aussi du filtrage pour interdire l'accès à des sites non autorisés :
--> phishing, malware
--> parentale (violence, pornographie).
--> gouvernementale.
--> entreprise (blocage de streaming, réseaux sociaux).
D'où l'usage d'autres serveurs DNS qui ne filtrent pas.
N'importe quoi...
Les FAI ne bloquent QUE les sites en fonction de la législation en vigueur ou de décisions de justice.
(Et encore, il y a des décisions qui concernent spécifiquement les 4 gros opérateurs et c'est tout. )
Donc chez nous, tu peux te faire contaminer par un malware, tu peux voir des vidéos porno violentes, tu peux aller sur le site des impots, et même aller mater netflix chez nos usagers professionnels/entreprises Par exemple, en ce moment je regarde des femmes qui te crachent dessus, te compressent les couilles et te godent jusqu'à ce que tu éjacules, ça me permet de relativiser par rapport aux gens qui me cassent les couilles autrement (et tout ceci grâce à nos dns) :D
-
Pourtant Adguard (https://adguard-dns.io/fr/welcome.html) le fait.
--> "dns.adguard.com" supprime les publicités, les trackers.
--> "dns-family.adguard.com" supprime les pourriels, les porno et les site de -18 ans.
Par mon FAI SFR, il y a des sites qui sont interdits alors que si je passe par DNS Google, je peux y accéder.
@ Optix : ce n'est pas parce que tu n'interdis rien chez toi, que c'est le cas chez d'autres.
-
Pourtant Adguard (https://adguard-dns.io/fr/welcome.html) le fait.
--> "dns.adguard.com" supprime les publicités, les trackers.
--> "dns-family.adguard.com" supprime les pourriels, les porno et les site de -18 ans.
Par mon FAI SFR, il y a des sites qui sont interdits alors que si je passe par DNS Google, je peux y accéder.
@ Optix : ce n'est pas parce que tu n'interdis rien chez toi, que c'est le cas chez d'autres.
C'est exactement que j'ai expliqué...
Du coup je répète :
Les FAI ne bloquent QUE les sites en fonction de la législation en vigueur ou de décisions de justice.
(Et encore, il y a des décisions qui concernent spécifiquement les 4 gros opérateurs et c'est tout. )
Voilà pourquoi tu as des sites qui passent chez Google et pas chez ton gros opérateur.
Voilà pourquoi tu as des services tiers (adgard) qui font plus de choses qu'un DNS d'opérateur (qui doit rester neutre, hors décision de justice, etc)
-
Du coup, je ne comprends pas pourquoi tu me dis :
N'importe quoi...
-
Du coup, je ne comprends pas pourquoi tu me dis :
Je me suis géné...
Mais essaye de taper "femdomempire.com" ou "kink.com", volets fermés, dans une pièce, seul.
Normalement c'est pas filtré :)
Et donc ça démontrera que tu peux voir de la violence et du porno depuis le DNS du FAI :)
-
Je peux pas croire que personne ici n'est jamais testé la difference entre cloudflare google et le dns du fai.
Pour moi le plus rapide (à Paris), c'est cloudflare et quad9 bizarrement.
-
J'ai testé tes sites et en effet, je peux y accéder, même avec mon navigateur google Chrome où je suis dans la "Protection renforcée".
Un exemple qui ne fonctionne "Z-Library (https://z-lib.id/)" où la législation française interdit l'accès (https://www.lemonde.fr/pixels/article/2024/09/12/z-library-la-justice-ordonne-le-blocage-du-site-de-telechargement-illegal_6315099_4408996.html), mais j'ai quand même l'accès par SFR.
Autre exemple, mais qui fonctionne : "Torrent9 (https://torrent9.app/), pas d'accès via SFR.
C'est le jeu du chat et de la souris. Pas toujours très efficace ces interdictions.
-
Par mon FAI SFR, il y a des sites qui sont interdits alors que si je passe par DNS Google, je peux y accéder.
Bonjour Artemus,
toi qui a les deux montreurs de télévision officiels de chez SFR, le gros truc 8 tout pas beau et son plus élégant petit frère Connect TV, peux-tu me dire s'il est possible de leur assigner des DNS spécifiques et ainsi éviter de perdre ton temps à subir de la réclame si d'aventure il te vient à l'idée de regarder un programme de rattrapage?
Technique qui fonctionne bien sur Android et assimilés avec les applis des chaînes, que du bonheur.
Ne veut rien savoir avec Oqee de Free, impossible pour d'autres raisons avec les combines Orange et probablement pas chez Bouygues qui impose sa sauce pour le Wi-Fi.
-
moi j'attend de voir une preuve concrete que utiliser un autre dns que celui du FAI puisse augmenter significativement les perfs.
-
On va dire que ça les augmente de manière indirecte (quand ça bloque tous les pisteurs, scripts de pubs, etc)
-
toi qui a les deux montreurs de télévision officiels de chez SFR, le gros truc 8 tout pas beau et son plus élégant petit frère Connect TV, peux-tu me dire s'il est possible de leur assigner des DNS spécifiques
Je n'ai pas la BOX 8 TV SFR mais le décodeur TV Plus SFR ainsi que le connect TV SFR. Le multicast fonctionne que si j'ai mis les serveurs DNS de SFR. En OTT, je n'ai pas besoin des serveurs DNS de SFR, mais j'ai quand même la publicité.
et ainsi éviter de perdre ton temps à subir de la réclame si d'aventure il te vient à l'idée de regarder un programme de rattrapage?
Je sais, c'est pénible, mais TF1 a fait fort en introduisant le blocage de la publicité à partir de la télécommande sur les replay ainsi que sur les enregistrements et je ne peux plus les boycoter comme je le faisais avant. Mais le pire dans cette publicité, c'est toujours la même comme s'il y avait un bouclage sur la même diffusion.
moi j'attend de voir une preuve concrète que utiliser un autre dns que celui du FAI puisse augmenter significativement les perfs.
Je suis comme toi, pas du tout convaincu que changer de serveurs DNS va augmenter les performances.
-
moi j'attend de voir une preuve concrete que utiliser un autre dns que celui du FAI puisse augmenter significativement les perfs.
Du coup le dns du FAI serai meilleures pour augmenté les perfs? Ta des preuves?
-
Du coup le dns du FAI serai meilleures pour augmenté les perfs? Ta des preuves?
Je pose ça là :
[cedric@fedora ~] $ dig @8.8.8.8 google.fr | grep time
;; Query time: 23 msec
[cedric@fedora ~] $ dig @213.226.72.231 google.fr | grep time
;; Query time: 3 msec
-
Je pose ça là :
[cedric@fedora ~] $ dig @8.8.8.8 google.fr | grep time
;; Query time: 23 msec
[cedric@fedora ~] $ dig @213.226.72.231 google.fr | grep time
;; Query time: 3 msec
Effectivement j'ai fait plusieurs nom de domaine random test avec des
Biscotte@PtitChat:~# dig @192.168.1.75 (Adguard) vidal.ru | grep time
;; Query time: 191 msec
Biscotte@PtitChat:~# dig @192.168.1.254 (Freebox) vidal.ru | grep time
;; Query time: 67 msec
Biscotte@PtitChat:~# dig @192.168.1.75 annuaire-medical.cm | grep time
;; Query time: 747 msec
Biscotte@PtitChat:~# dig @192.168.1.254 annuaire-medical.cm | grep time
;; Query time: 207 msec
Biscotte@PtitChat:~# dig @192.168.1.75 tabletki.ua | grep time
;; Query time: 499 msec
Biscotte@PtitChat:~# dig @192.168.1.254 tabletki.ua| grep time
;; Query time: 23 msec
Donc vaut mieux que sur ma configuration Adguard je fasse pointé le vers la freebox ou bien si vous avez le dns de free en direct c'est mieux !
-
Je peux pas croire que personne ici n'est jamais testé la difference entre cloudflare google et le dns du fai.
Let's see...
$ dig -t aaaa lafibre.info @2620:fe::fe | grep time
;; Query time: 19 msec
$ dig -t aaaa lafibre.info @2620:fe::fe | grep time
;; Query time: 19 msec
$ dig -t aaaa lafibre.info @2620:fe::fe | grep time
;; Query time: 19 msec
$ dig -t aaaa lafibre.info @2620:fe::fe | grep time
;; Query time: 27 msec
$ dig -t aaaa lafibre.info @2620:fe::fe | grep time
;; Query time: 15 msec
$ dig -t aaaa lafibre.info @2620:fe::fe | grep time
;; Query time: 19 msec
$ dig -t aaaa lafibre.info @2620:fe::fe | grep time
;; Query time: 19 msec
$ dig -t aaaa lafibre.info @2620:fe::fe | grep time
;; Query time: 19 msec
$ dig -t aaaa lafibre.info @2620:fe::fe | grep time
;; Query time: 19 msec
Quad9 : 19.4ms en moyenne
$ dig -t aaaa lafibre.info @2606:4700:4700::1111 | grep time
;; Query time: 11 msec
$ dig -t aaaa lafibre.info @2606:4700:4700::1111 | grep time
;; Query time: 7 msec
$ dig -t aaaa lafibre.info @2606:4700:4700::1111 | grep time
;; Query time: 15 msec
$ dig -t aaaa lafibre.info @2606:4700:4700::1111 | grep time
;; Query time: 11 msec
$ dig -t aaaa lafibre.info @2606:4700:4700::1111 | grep time
;; Query time: 23 msec
$ dig -t aaaa lafibre.info @2606:4700:4700::1111 | grep time
;; Query time: 11 msec
$ dig -t aaaa lafibre.info @2606:4700:4700::1111 | grep time
;; Query time: 19 msec
$ dig -t aaaa lafibre.info @2606:4700:4700::1111 | grep time
;; Query time: 11 msec
$ dig -t aaaa lafibre.info @2606:4700:4700::1111 | grep time
;; Query time: 12 msec
Cloudflare : 13.3 ms en moyenne
$ dig -t aaaa lafibre.info @2001:4860:4860::8888 | grep time
;; Query time: 19 msec
$ dig -t aaaa lafibre.info @2001:4860:4860::8888 | grep time
;; Query time: 23 msec
$ dig -t aaaa lafibre.info @2001:4860:4860::8888 | grep time
;; Query time: 19 msec
$ dig -t aaaa lafibre.info @2001:4860:4860::8888 | grep time
;; Query time: 15 msec
$ dig -t aaaa lafibre.info @2001:4860:4860::8888 | grep time
;; Query time: 19 msec
$ dig -t aaaa lafibre.info @2001:4860:4860::8888 | grep time
;; Query time: 35 msec
$ dig -t aaaa lafibre.info @2001:4860:4860::8888 | grep time
;; Query time: 19 msec
$ dig -t aaaa lafibre.info @2001:4860:4860::8888 | grep time
;; Query time: 11 msec
$ dig -t aaaa lafibre.info @2001:4860:4860::8888 | grep time
;; Query time: 19 msec
Google : 19.8ms en moyenne
$ dig -t aaaa lafibre.info @2a01:cfc4:2000:2::12 | grep time
;; Query time: 7 msec
$ dig -t aaaa lafibre.info @2a01:cfc4:2000:2::12 | grep time
;; Query time: 7 msec
$ dig -t aaaa lafibre.info @2a01:cfc4:2000:2::12 | grep time
;; Query time: 7 msec
$ dig -t aaaa lafibre.info @2a01:cfc4:2000:2::12 | grep time
;; Query time: 7 msec
$ dig -t aaaa lafibre.info @2a01:cfc4:2000:2::12 | grep time
;; Query time: 11 msec
$ dig -t aaaa lafibre.info @2a01:cfc4:2000:2::12 | grep time
;; Query time: 7 msec
$ dig -t aaaa lafibre.info @2a01:cfc4:2000:2::12 | grep time
;; Query time: 7 msec
$ dig -t aaaa lafibre.info @2a01:cfc4:2000:2::12 | grep time
;; Query time: 7 msec
$ dig -t aaaa lafibre.info @2a01:cfc4:2000:2::12 | grep time
;; Query time: 7 msec
Orange : 7.4 ms en moyenne
$ dig -t aaaa lafibre.info @2a01:cb08:xxxx:xxxx::1 | grep time
;; Query time: 0 msec
$ dig -t aaaa lafibre.info @2a01:cb08:xxxx:xxxx::1 | grep time
;; Query time: 0 msec
$ dig -t aaaa lafibre.info @2a01:cb08:xxxx:xxxx::1 | grep time
;; Query time: 3 msec
$ dig -t aaaa lafibre.info @2a01:cb08:xxxx:xxxx::1 | grep time
;; Query time: 3 msec
$ dig -t aaaa lafibre.info @2a01:cb08:xxxx:xxxx::1 | grep time
;; Query time: 0 msec
$ dig -t aaaa lafibre.info @2a01:cb08:xxxx:xxxx::1 | grep time
;; Query time: 0 msec
$ dig -t aaaa lafibre.info @2a01:cb08:xxxx:xxxx::1 | grep time
;; Query time: 0 msec
$ dig -t aaaa lafibre.info @2a01:cb08:xxxx:xxxx::1 | grep time
;; Query time: 0 msec
$ dig -t aaaa lafibre.info @2a01:cb08:xxxx:xxxx::1 | grep time
;; Query time: 0 msec
Resolver/cache local (unbound sur le routeur) : 0.6ms en moyenne
Donc vaut probablement mieux taper au plus proche, mais la différence est quasiment imperceptible...
-
C'est sur la différence entre 4 ms et 15 ms et c'est imperceptible pour une personne normale ! Je ne cherche pas à gagner 11 ms ! Je veux juste enrichir ma culture générale ! Par contre, il y a une grosse différence majeure sur Netflix ! Avec le DNS de Free, je tape sur un serveur Netflix en IPv6 à Strasbourg au lieu de monter sur Paris 8) et en IPv6 chez Free, étonnamment, c'est du direct vers Strasbourg donc je ne remonte pas du tout vers Paris. Alors qu'avec l'autre DNS bah je remonte de l'ipv6 vers Paris
-
C'est sur la différence entre 4 ms et 15 ms et c'est imperceptible pour une personne normale ! Je ne cherche pas à gagner 11 ms ! Je veux juste enrichir ma culture générale ! Par contre, il y a une grosse différence majeure sur Netflix ! Avec le DNS de Free, je tape sur un serveur Netflix en IPv6 à Strasbourg au lieu de monter sur Paris 8) et en IPv6 chez Free, étonnamment, c'est du direct vers Strasbourg donc je ne remonte pas du tout vers Paris. Alors qu'avec l'autre DNS bah je remonte de l'ipv6 vers Paris
Par contre truc étonnant... quand je ping google.com ou .fr maintenant je remontent probablement vers les usa
PS C:\Users\Clément> tracert google.fr
Détermination de l’itinéraire vers google.fr [2404:6800:4005:81e::2003]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 2a01:e0a:22:3df0::1
2 1 ms 1 ms 1 ms 2a01:e01:6:f836:481::ffff
3 * * * Délai d’attente de la demande dépassé.
4 * * * Délai d’attente de la demande dépassé.
5 * * * Délai d’attente de la demande dépassé.
6 * * * Délai d’attente de la demande dépassé.
7 15 ms 15 ms 16 ms iboss-ic-361506.ip.twelve99-cust.net [2001:2035:0:1b2c::2]
8 15 ms 15 ms 14 ms 2a00:1450:8121::1
9 15 ms 15 ms 15 ms 2001:4860:0:1::1af6
10 15 ms * * 2001:4860:0:1::7fd0
11 228 ms 228 ms 230 ms 2001:4860::c:4004:4a30
12 237 ms 238 ms 238 ms 2001:4860::c:4002:aa51
13 239 ms 239 ms 239 ms 2001:4860::c:4002:a0bf
14 * * * Délai d’attente de la demande dépassé.
15 229 ms 228 ms 228 ms 2001:4860::c:4003:9139
16 238 ms 238 ms 238 ms 2001:4860::c:4001:36fe
17 237 ms 237 ms 237 ms 2001:4860::9:4001:d5c
18 228 ms * 228 ms 2001:4860:0:1::781b
19 228 ms 228 ms 228 ms 2001:4860:0:1::6bb1
20 227 ms 228 ms 227 ms nchkga-af-in-x03.1e100.net [2404:6800:4005:81e::2003
-
Les CDN et autres gros sites aiguillent parfois le trafic de l'utilisateur vers un serveur proche en fonction de l'adresse IP source du résolveur DNS, en partant du principe que le client sera sur le même réseau... ce qui ne tient pas si le client utilise un DNS hors de son réseau, bien sûr.
Donc je pense qu'il y a un impact théorique, mais qu'en soit il est soit imperceptible, soit très faible.
Pas forcément. On peut voir encore régulièrement des résolutions vers la plateforme du coin faite via les DNS de l'ISP, et vers un cluster à perpète via les DNS publics ; aux US dans le pire des cas, mais j'avais vu des plateformes en Pologne sur de l'Akamai (ou peut-être du Google).
Bref, utiliser les DNS de son ISP reste le plus pertinent à tout point de vue.
-
Oui, clairement, et d'ailleurs c'est ce que constate ilovelinux avec Netflix :
Par contre, il y a une grosse différence majeure sur Netflix ! Avec le DNS de Free, je tape sur un serveur Netflix en IPv6 à Strasbourg au lieu de monter sur Paris 8) et en IPv6 chez Free, étonnamment, c'est du direct vers Strasbourg donc je ne remonte pas du tout vers Paris. Alors qu'avec l'autre DNS bah je remonte de l'ipv6 vers Paris
Donc oui, dans le cas où l'ISP déploie des noeuds netflix/CDN/autre cache dans son réseau, utiliser ses DNS est probablement meilleur.
-
Déjà constaté ça avec Netflix effectivement.
Depuis le Pays-Basque :
- FTTH Orange + DNS Orange : serveur Netflix hébergé chez Orange à Poitiers
- FTTH Orange + DNS public : serveur Netflix hébergé chez un CDN sans doute en IDF vu la latence
- FTTH Bouygues + DNS Bouygues : serveur Netflix hébergé chez Bouygues à Toulouse
- FTTH Bouygues + DNS public : serveur Netflix qui semble hébergé à Marseille ou en IDF selon les moments
Après faut pas se faire d'idées, à l'usage lors d'un visionnage vidéo je n'ai jamais remarqué de différence.
-
Après faut pas se faire d'idées, à l'usage lors d'un visionnage vidéo je n'ai jamais remarqué de différence.
Autant optimiser les transferts réseaux, non? C'est quand même le principe.
-
Autant optimiser les transferts réseaux, non? C'est quand même le principe.
Bien évidemment, mais ce que je veux dire c'est qu'il ne faut pas nécessairement s'arrêter à cela et peser le pour et le contre.
Dans mon cas, utiliser mon propre serveur DNS qui utilise ensuite un serveur public me rend des services concrets, je ne vais pas m'en passer sous prétexte d'un flux Netflix ou autre qui irait jusqu'à Marseille au lieu de Toulouse alors que ça n'a aucune incidence négative à l'usage.
-
C'est sur la différence entre 4 ms et 15 ms et c'est imperceptible pour une personne normale ! Je ne cherche pas à gagner 11 ms !
C'est surtout perceptible quand tu fais des requêtes DNS en cascade.
Par exemple un blog, une page d'un forum avec des avatars/signatures, ou un site web très mal branlé avec plein de pubs qui va demander des ressources à droite à gauche et provoquer 50 voire 100 lookups pour des sous-domaines, etc.
Là du coup, tes temps de réponses vont s'additionner, et tu peux facilement taper dans les centaines de millisecondes, et là ça devient perceptible.
-
Dans mon cas, utiliser mon propre serveur DNS qui utilise ensuite un serveur public me rend des services concrets
Simple question, si tu configures ton serveur pour être resolveur/cache plutôt que simple cache/forwarder, est-ce que tu tombes bien sur les caches locaux ?
Ca fait des années que je fais tourner mon propre resolver/cache sur mon routeur, du coup, ca me rend curieux de savoir si ce sont les serveurs de la zone DNS netflix.com qui aiguillent en fonction de l'adresse IP source du résolveur, ou si ce sont les DNS de l'ISP qui magouillent avec des zones privées (j'espère pas... mais plus rien ne me surprend).
Je pourrais faire un test, mais j'ai pas d'abonnement netflix.
-
Du coup j'ai bien changer mes dns pour ce de free (212.27.40.240 ou 212.27.40.241)
Quand je ping google en ipv4 ou IPV6 j'ai 227 ms. Une idée d’où ça peut venir?
ping -4 google.fr
Envoi d’une requête 'ping' sur google.fr [142.250.198.227] avec 32 octets de données :
Réponse de 142.250.198.227 : octets=32 temps=227 ms TTL=115
Réponse de 142.250.198.227 : octets=32 temps=227 ms TTL=115
Réponse de 142.250.198.227 : octets=32 temps=227 ms TTL=115
Réponse de 142.250.198.227 : octets=32 temps=227 ms TTL=115
Statistiques Ping pour 142.250.198.227:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 227ms, Maximum = 227ms, Moyenne = 227ms
ping -6 google.fr
Envoi d’une requête 'ping' sur google.fr [2404:6800:4005:819::2003] avec 32 octets de données :
Réponse de 2404:6800:4005:819::2003 : temps=238 ms
Réponse de 2404:6800:4005:819::2003 : temps=237 ms
Réponse de 2404:6800:4005:819::2003 : temps=237 ms
Réponse de 2404:6800:4005:819::2003 : temps=238 ms
Statistiques Ping pour 2404:6800:4005:819::2003:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 237ms, Maximum = 238ms, Moyenne = 237ms
Traceroute :
tracert -4 google.fr
Détermination de l’itinéraire vers google.fr [142.250.198.227]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.1.254
2 * * * Délai d’attente de la demande dépassé.
3 15 ms 16 ms 15 ms station3.multimania.isdnet.net [194.149.174.100]
4 15 ms 15 ms 16 ms prs-b3-link.ip.twelve99.net [62.115.46.68]
5 15 ms 15 ms 15 ms google-ic-344096.ip.twelve99-cust.net [62.115.174.29]
6 15 ms 14 ms 15 ms 216.239.40.77
7 15 ms 15 ms 15 ms 108.170.255.238
8 16 ms 17 ms 17 ms 209.85.255.106
9 97 ms 98 ms 99 ms 216.239.43.184
10 106 ms 105 ms 106 ms 192.178.81.231
11 151 ms 151 ms 151 ms 142.250.213.70
12 300 ms 238 ms 238 ms 142.250.58.53
13 238 ms 238 ms 238 ms 142.251.49.204
14 234 ms 237 ms 234 ms 209.85.142.192
15 238 ms 237 ms 238 ms 74.125.245.5
16 234 ms 234 ms 234 ms 142.251.64.175
17 227 ms 227 ms 227 ms nchkgb-ah-in-f3.1e100.net [142.250.198.227]
tracert -6 google.fr
Détermination de l’itinéraire vers google.fr [2404:6800:4005:819::2003]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 2a01:e0a:22:3df0::1
2 1 ms 1 ms <1 ms 2a01:e01:6:f836:481::ffff
3 * * * Délai d’attente de la demande dépassé.
4 * * 15 ms 2a01:e01:6::2
5 * * * Délai d’attente de la demande dépassé.
6 * * * Délai d’attente de la demande dépassé.
7 15 ms 15 ms 15 ms iboss-ic-361506.ip.twelve99-cust.net [2001:2035:0:1b2c::2]
8 14 ms 15 ms 15 ms 2a00:1450:812f::1
9 * 16 ms 15 ms 2001:4860:0:1::51fa
10 16 ms 15 ms 16 ms 2001:4860:0:1::81ce
11 228 ms 229 ms 229 ms 2001:4860::c:4004:4a30
12 242 ms 241 ms 241 ms 2001:4860::c:4002:aa51
13 238 ms 239 ms 239 ms 2001:4860::c:4002:a0bf
14 * * * Délai d’attente de la demande dépassé.
15 238 ms 238 ms 239 ms 2001:4860::c:4003:2e38
16 239 ms 239 ms 238 ms 2001:4860::c:4001:36fe
17 239 ms 239 ms 238 ms 2001:4860::1:0:ca31
18 237 ms 237 ms 237 ms nchkga-ad-in-x03.1e100.net [2404:6800:4005:819::2003]
-
Pacontre quand je remets les DNS de dns0 j'ai à nouveau 16 ms
ping -4 google.fr
Envoi d’une requête 'ping' sur google.fr [142.250.179.67] avec 32 octets de données :
Réponse de 142.250.179.67 : octets=32 temps=15 ms TTL=116
Réponse de 142.250.179.67 : octets=32 temps=15 ms TTL=116
Réponse de 142.250.179.67 : octets=32 temps=14 ms TTL=116
Réponse de 142.250.179.67 : octets=32 temps=15 ms TTL=116
Statistiques Ping pour 142.250.179.67:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 14ms, Maximum = 15ms, Moyenne = 14ms
ping -6 google.fr
Envoi d’une requête 'ping' sur google.fr [2a00:1450:4007:813::2003] avec 32 octets de données :
Réponse de 2a00:1450:4007:813::2003 : temps=15 ms
Réponse de 2a00:1450:4007:813::2003 : temps=14 ms
Réponse de 2a00:1450:4007:813::2003 : temps=15 ms
Réponse de 2a00:1450:4007:813::2003 : temps=14 ms
Traceroute
tracert -4 google.fr
Détermination de l’itinéraire vers google.fr [142.250.179.67]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.1.254
2 * * 15 ms cbv-mx9-ae1.intf.routers.proxad.net [194.149.162.6]
3 15 ms 14 ms 15 ms station3.multimania.isdnet.net [194.149.174.100]
4 15 ms 15 ms 15 ms prs-b3-link.ip.twelve99.net [62.115.46.68]
5 15 ms 14 ms 15 ms google-ic-344096.ip.twelve99-cust.net [62.115.174.29]
6 15 ms 16 ms 16 ms 216.239.40.79
7 16 ms 15 ms 15 ms 142.251.49.133
8 15 ms 15 ms 15 ms par21s19-in-f3.1e100.net [142.250.179.67]
tracert -6 google.fr
Détermination de l’itinéraire vers google.fr [2a00:1450:4007:813::2003]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 2a01:e0a:22:3df0::1
2 1 ms 1 ms 1 ms 2a01:e01:6:f836:481::ffff
3 * * * Délai d’attente de la demande dépassé.
4 * * * Délai d’attente de la demande dépassé.
5 * * * Délai d’attente de la demande dépassé.
6 * 15 ms * prs-b3-link.ip.twelve99.net [2001:2035:0:2923::1]
7 15 ms 15 ms 15 ms iboss-ic-361506.ip.twelve99-cust.net [2001:2035:0:1b2c::2]
8 15 ms 15 ms 15 ms 2a00:1450:8121::1
9 15 ms 15 ms 15 ms 2001:4860:0:1::1af6
10 15 ms 15 ms * 2001:4860:0:1::7fce
11 15 ms 16 ms 15 ms 2001:4860::c:4004:4a2e
12 15 ms 16 ms 15 ms 2001:4860::9:4003:6042
13 16 ms 15 ms * 2001:4860:0:1::8223
14 15 ms 15 ms 15 ms 2001:4860:0:1::51f9
15 15 ms 14 ms 15 ms par21s19-in-x03.1e100.net [2a00:1450:4007:813::2003
-
Google semble te router assez loin de chez toi... traceroute vers cette destination depuis Orange (je suis pas chez Free):
$ mtr 2404:6800:4005:819::2003
Start: 2025-05-06T17:58:41+0200
1.|-- gw1-vlan3 (2a01:cb08:xxxx:xxxx::1) 0.0% 10 0.8 0.8 0.7 1.0 0.1
2.|-- xxxxxxxxxxxxxxxxxxxxx 0.0% 10 1.7 1.7 1.4 2.4 0.3
3.|-- 2a01:cfc0:200:8000:xxxx:xxxx:xxxx:xxxx 0.0% 10 8.8 8.9 8.7 9.5 0.2
4.|-- 2a01:cfc4:0:400::3 90.0% 10 8.8 8.8 8.8 8.8 0.0
5.|-- 2001:4860:1:1::36a 0.0% 10 8.9 8.8 8.4 9.1 0.2
6.|-- 2001:4860:0:1::81c3 0.0% 10 9.7 9.9 9.3 10.5 0.4
7.|-- 2001:4860:0:1::28fa 0.0% 10 8.9 12.7 8.1 40.6 10.1
8.|-- 2001:4860::c:4004:4a2f 0.0% 10 8.5 8.8 8.5 9.4 0.4
9.|-- 2001:4860::c:4002:a55c 0.0% 10 85.0 84.8 84.2 85.3 0.4
10.|-- 2001:4860::c:4000:d2a0 10.0% 10 98.5 98.7 98.0 99.3 0.5
11.|-- 2001:4860::c:4002:b0db 0.0% 10 139.1 139.4 139.1 140.1 0.3
12.|-- 2001:4860::c:4000:e103 40.0% 10 223.8 224.0 223.8 224.4 0.2
13.|-- 2001:4860::c:4000:db82 0.0% 10 230.4 230.4 229.7 232.4 0.8
14.|-- 2001:4860::9:4001:d5c 0.0% 10 229.3 233.8 229.3 245.6 6.4
15.|-- 2001:4860:0:1::8999 0.0% 10 229.8 230.1 229.8 232.2 0.7
16.|-- 2001:4860:0:1::16ad 0.0% 10 229.7 229.6 229.4 229.9 0.2
17.|-- nchkga-ad-in-x03.1e100.net (2404:6800:4005:819::2003) 0.0% 10 229.6 229.8 229.4 230.3 0.3
On se ballade assez loin, probablement entre pays, dans le réseau de Google... va savoir pourquoi.
En IPv4, chez Free, tout le trafic remonte de toute facon en région parisienne pour ressortir d'un tunnel (Free n'a plus que de l'IPv6 dans son réseau d'accès et de collecte FTTH, le trafic v4 est encapsulé dans IPv6). Donc tu vas taper un serveur google.fr en région parisienne en IPv4, c'est à peu près certain.
Mais bon, vu que si tu as de l'IPv6, tu vas joindre Google en IPv6, on s'en balance un peu.
-
de mon coté a ca l'air tranquile
tracert -4 google.fr
Détermination de l’itinéraire vers google.fr [142.250.179.67]
avec un maximum de 30 sauts :
1 2 ms 2 ms 1 ms 192.168.1.254
2 * * * Délai d’attente de la demande dépassé.
3 16 ms * * station3.multimania.isdnet.net [194.149.174.100]
4 16 ms 18 ms 16 ms prs-b3-link.ip.twelve99.net [62.115.46.68]
5 17 ms 17 ms 17 ms google-ic-344096.ip.twelve99-cust.net [62.115.174.29]
6 16 ms 16 ms 17 ms 216.239.40.77
7 17 ms 16 ms 17 ms 142.251.49.131
8 17 ms 17 ms 16 ms par21s19-in-f3.1e100.net [142.250.179.67]
-
On se ballade assez loin, probablement entre pays, dans le réseau de Google... va savoir pourquoi.
En IPv4, chez Free, tout le trafic remonte de toute facon en région parisienne pour ressortir d'un tunnel (Free n'a plus que de l'IPv6 dans son réseau d'accès et de collecte FTTH, le trafic v4 est encapsulé dans IPv6). Donc tu vas taper un serveur google.fr en région parisienne en IPv4, c'est à peu près certain.
Mais bon, vu que si tu as de l'IPv6, tu vas joindre Google en IPv6, on s'en balance un peu.
Aprés en IPV4 ou IPV6 j'ai pluis de 200 ms avec les DNS DE FREE
Alors que sans dns de free normal j'ai 16 ms
-
de mon coté a ca l'air tranquile
tracert -4 google.fr
Détermination de l’itinéraire vers google.fr [142.250.179.67]
avec un maximum de 30 sauts :
1 2 ms 2 ms 1 ms 192.168.1.254
2 * * * Délai d’attente de la demande dépassé.
3 16 ms * * station3.multimania.isdnet.net [194.149.174.100]
4 16 ms 18 ms 16 ms prs-b3-link.ip.twelve99.net [62.115.46.68]
5 17 ms 17 ms 17 ms google-ic-344096.ip.twelve99-cust.net [62.115.174.29]
6 16 ms 16 ms 17 ms 216.239.40.77
7 17 ms 16 ms 17 ms 142.251.49.131
8 17 ms 17 ms 16 ms par21s19-in-f3.1e100.net [142.250.179.67]
Tu utilise les dns de free?
-
Comparez ce qui est comparable.
Je vois du traceroute, du ping (donc du débug niveau 3), alors qu'on parle de DNS (donc niveau applicatif).
Et je vois de l'IPv6 quand la comparaison d'après se fait en v4.
Restez cohérents.
Déjà, est-ce que la réponse à "google.fr" en AAAA entre un DNS Free et un DNS tiers est la même ?
-
Comparez ce qui est comparable.
Je vois du traceroute, du ping (donc du débug niveau 3), alors qu'on parle de DNS (donc niveau applicatif).
Et je vois de l'IPv6 quand la comparaison d'après se fait en v4.
Restez cohérents.
Déjà, est-ce que la réponse à "google.fr" en AAAA entre un DNS Free et un DNS tiers est la même ?
Non pas la même.
dig @212.27.40.240 google.fr
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> @212.27.40.240 google.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12913
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.fr. IN A
;; ANSWER SECTION:
google.fr. 72 IN A 142.250.198.227
;; Query time: 0 msec
;; SERVER: 212.27.40.240#53(212.27.40.240) (UDP)
;; WHEN: Tue May 06 18:09:38 CEST 2025
;; MSG SIZE rcvd: 54
dig @45.90.28.69 google.fr
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> @45.90.28.69 google.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60571
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.fr. IN A
;; ANSWER SECTION:
google.fr. 264 IN A 172.217.20.163
;; Query time: 71 msec
;; SERVER: 45.90.28.69#53(45.90.28.69) (UDP)
;; WHEN: Tue May 06 18:10:11 CEST 2025
;; MSG SIZE rcvd: 54
-
Déjà, est-ce que la réponse à "google.fr" en AAAA entre un DNS Free et un DNS tiers est la même ?
Il me semble bien qu'il observe des réponses différentes : 2a00:1450:4007:813::2003 / 142.250.179.67 avec "dns0" et 2404:6800:4005:819::2003 / 142.250.198.227 pour google.fr avec les DNS de free.
-
Il me semble bien qu'il observe des réponses différentes : 2a00:1450:4007:813::2003 / 142.250.179.67 avec "dns0" et 2404:6800:4005:819::2003 / 142.250.198.227 pour google.fr avec les DNS de free.
C'est exact exactement ça pour l'ipv6
-
Tu utilise les dns de free?
ben ouais, 192.168.1.254
-
ben ouais, 192.168.1.254
Mémé en essayant de mettre le dns en 192.168.1.254 j'ai une réponse pour google.fr en 142.250.197.131 avec 230 ms
-
verifie que t'as rien de renseigné dans les param dns sur mafreebox.freebox.fr ?
-
verifie que t'as rien de renseigné dans les param dns sur mafreebox.freebox.fr ?
ça ne viens pas de mafreebox.freebox.fr car même en utilisant en direct le dns de free 212.27.40.240 / 212.27.40.241. J'ai exactement là même réponse que si j'essaye avec l'ip de la box
-
Simple question, si tu configures ton serveur pour être resolveur/cache plutôt que simple cache/forwarder, est-ce que tu tombes bien sur les caches locaux ?
Ca fait des années que je fais tourner mon propre resolver/cache sur mon routeur, du coup, ca me rend curieux de savoir si ce sont les serveurs de la zone DNS netflix.com qui aiguillent en fonction de l'adresse IP source du résolveur, ou si ce sont les DNS de l'ISP qui magouillent avec des zones privées (j'espère pas... mais plus rien ne me surprend).
Non, pas forcément. Chez Akamai en tous cas, les IPs des DNS des ISP sont connues (pour émission de requêtes en masse, ou même directement par échange d'informations manuellement), et des statistiques sont faites automagiquement pour savoir quoi faire avec les requêtes qui en viennent.
Quand c'est une IP d'un client qui interroge directement (ou un DNS qui n'est que très peu solicité et qui n'a pas été expressément déclaré), on peut avoir de mauvaises surprises et se retrouver aux US par exemple (déjà vu plein de fois).
je n'ai jamais remarqué de différence.
ça n'a aucune incidence négative à l'usage.
Tu te rends bien compte que «moi j'ai rien remarqué» n'est aucunement synonyme de «ça n'a aucune incidence négative» ? :P
-
C'est pour cela que je lui demandais si il pouvait faire un test :-)