DNS-Resolver Quad9 perd le premier appel de blocage de sites pirates en Allemagne aujourd'hui

 

 DNS-Resolver Quad9 perd le premier appel de blocage de sites pirates en Allemagne aujourd'hui 

par Ernesto Van der Sar

 

 Accueil > Anti-Piratage > Blocage de Site > 

 Le résolveur DNS Quad9 a perdu son appel contre l'ordonnance de blocage de sites pirates de Sony Music devant le tribunal régional de Hambourg. La fondation à but non lucratif Quad9 est déçue du résultat mais n'abandonne pas pour l'instant la bataille juridique, notant que divers services Internet sont menacés si l'ordre n'est pas contesté avec succès. quad9 Plus tôt cette année, les plus grands fournisseurs Internet allemands ont accepté de bloquer volontairement les sites pirates dans le cadre d'un accord conclu avec les détenteurs de droits d'auteur. Ces blocages, qui sont mis en place à la suite d'un processus de vérification approfondi, sont généralement mis en œuvre au niveau du DNS. C'est une option relativement simple, car tous les FAI ont leurs propres résolveurs DNS.

 (dé)bloquer DNS 

 Cependant, le blocage DNS est également facile à contourner. Au lieu d'utiliser les résolveurs DNS des FAI, les abonnés peuvent passer à des alternatives telles que Cloudflare, Google, OpenDNS et Quad9. 

Ce changement relativement simple rendra les efforts de blocage des FAI inutiles. Cette solution de contournement est largement connue, également par les détenteurs de droits d'auteur. En tant que tel, il n'est peut-être pas surprenant que quelques semaines après la conclusion de l'accord de blocage allemand, Sony Music ait obtenu une injonction qui oblige le résolveur DNS Quad9 à bloquer un site pirate populaire. Une ordonnance de blocage contre un résolveur DNS est assez inhabituelle et l'organisation à but non lucratif basée en Suisse Quad9 a rapidement annoncé qu'elle ferait appel du verdict.

 La fondation a souligné qu'elle ne tolérait pas le piratage, mais estime que l'application de mesures de blocage par le biais d'intermédiaires tiers est un pas de trop. La Cour confirme l'ordonnance de blocage de site Quad9 a répété ces arguments et d'autres devant le tribunal régional de Hambourg, lui demandant d'annuler l'injonction. Après avoir examiné les commentaires des deux parties, la Cour a choisi de maintenir les exigences de blocage de sites. Le nom du site ciblé reste expurgé mais les documents légaux mentionnent que le site sans nom renvoie à de la musique piratée. Nous en avons déduit précédemment que Canna.to est la cible probable, car ce site faisait déjà partie de l'accord de blocage volontaire des FAI lorsque la procédure a été lancée.

 Ayant perdu son premier recours, Quad9 note qu'il continuera à bloquer le site, comme l'exige l'injonction. L'association est déçue de la décision de la Cour mais a annoncé qu'elle poursuivrait son appel devant une juridiction supérieure.

 Quad9 n'abandonnera pas "Nous sommes déçus que cette première série d'audiences se soit terminée par ce que nous pensons être un résultat qui n'est pas conforme aux intentions législatives du gouvernement allemand", a déclaré le directeur général de Quad, John Todd. « Il existe un grand nombre de services basés sur Internet qui, selon nous, sont en fin de compte sérieusement menacés par cette décision, et nous n'arrêterons pas nos contestations judiciaires sur cette injonction. » Quad9 dit qu'il continuera à faire appel, non seulement au nom de sa propre organisation, mais aussi pour défendre les droits de ses utilisateurs et d'autres personnes et organisations qui pourraient être affectées par ce type de commandes à l'avenir. « [Nous] continuerons de poursuivre notre combat juridique contre ce que nous pensons être un résultat qui menace le cœur même de la capacité d'Internet à être un outil utile et fiable pour tout le monde. 

Les entreprises ne devraient pas avoir la possibilité d'exiger directement que les opérateurs d'infrastructure de réseau censurent les sites », note Todd.

 Large prise en charge

 Le résolveur DNS est soutenu par plusieurs autres groupes et organisations, dont l'Association allemande de l'industrie Internet (éco), la Stiftung Mercator Schweiz et la Société allemande pour les droits à la liberté (GFF). La coordinatrice du projet GFF, Julia Reda, qui a auparavant été membre du Parlement européen pour le Parti pirate, note que les législateurs allemands ont précédemment aboli le concept de « responsabilité d'ingérence » pour les fournisseurs d'accès Internet.

Dans cet esprit, l'ordre de blocage semble être un pas dans la mauvaise direction. « Exposer les opérateurs de résolveurs DNS récursifs à des risques juridiques érode les garanties juridiques que les législateurs avaient l'intention d'établir », déclare Reda. Dans ce cas, Quad9 n'est pas directement responsable des activités de piratage. 

Cependant, l'organisation est tenue de prendre des mesures pour empêcher de futures infractions potentielles en empêchant les utilisateurs de résoudre le site de piratage de musique.

 Des dons

 Quad9 accueille favorablement le soutien du GFF et des autres organisations. Il se réjouit également du soutien du grand public. Heise a précédemment signalé que les dons avaient augmenté de 900 % après l'annonce de l'ordre de blocage plus tôt cette année. Le résolveur DNS note que ces contributions financières sont encore bien nécessaires pour couvrir les coûts financiers de la bataille juridique. Il encourage les personnes qui en ont les moyens à poursuivre leur soutien à l'appel au blocage de sites.

 

REF.: https://torrentfreak.com/dns-resolver-quad9-loses-first-pirate-site-blocking-appeal-in-germany-211206/

Facebook: Problême d'employé,de serveurs DNS ,ou hacké a 15:40 UTC ? Qui a changer la config du serveur DNS ? Hein ???

 Facebook: Problême d'employé,de serveurs DNS ,ou hacké a 15:40 UTC ? Qui a changer la config du serveur DNS ? Hein ???

 

C'est la panne la plus importante jamais observée qui a touché Facebook et ses réseaux sociaux et services de messagerie comme WhatsApp et Instagram ainsi que leurs 3,5 milliards d'utilisateurs.

7h de panne mondiale, un coût de 6 milliards de dollars... La panne géante pour Facebook, Messenger, Whatsapp et Instagram est désormais terminée ce mardi matin. 

Les réseaux sociaux et messageries du géant californien Facebook sont restés inaccessibles une partie de la journée de lundi avant un retour à la normale aux environs de minuit. Un nouveau revers pour la firme de Mark Zuckerberg.

 Ce serait plus spécifiquement, les résolveurs DNS tels que Cloudflare-Services qui convertissent ces noms de domaine en adresses IP - ont vu autant que le double du trafic habituel, car les gens continuent à tenter de charger Facebook, Instagram et WhatsApp en vain. Ces demandes ne suffisent pas pour submerger le système, mais la surtension est un rappel de la manière interdépendante et parfois fragile, Internet est vraiment.

 « Facebook ne peut pas être en panne, n'est-ce pas ? »,

 avons-nous pensé pendant une seconde. 

 Aujourd'hui 041021, à 15:51 UTC, nous avons ouvert un incident interne intitulé "Facebook DNS lookup return SERVFAIL" car nous craignions que quelque chose n'allait pas avec notre résolveur DNS 1.1.1.1. Mais alors que nous étions sur le point de publier sur notre page de statut public, nous avons réalisé que quelque chose de plus grave se passait.

 Les médias sociaux ont rapidement pris feu, rapportant ce que nos ingénieurs ont rapidement confirmé également. Facebook et ses services affiliés WhatsApp et Instagram étaient, en fait, tous en panne. Leurs noms DNS ont cessé de se résoudre et leurs adresses IP d'infrastructure étaient inaccessibles. 

C'était comme si quelqu'un avait "tiré les câbles" de leurs centres de données d'un seul coup et les avait déconnectés d'Internet. Ce n'était pas un problème DNS en soi, mais l'échec du DNS était le premier symptôme que nous avions vu d'une panne plus importante de Facebook. 

 Comment est-ce possible ?

 Mise à jour de Facebook

 Facebook a maintenant publié un article de blog donnant quelques détails sur ce qui s'est passé en interne. 

En externe, nous avons vu les problèmes BGP et DNS décrits dans cet article, mais le problème a en fait commencé par un changement de configuration qui a affecté l'ensemble du backbone interne. Cela s'est répercuté sur la disparition de Facebook et d'autres propriétés et le personnel interne à Facebook a du mal à rétablir le service. Facebook a publié un autre article de blog avec beaucoup plus de détails sur ce qui s'est passé. Vous pouvez lire ce post pour la vue intérieure et ce post pour la vue extérieure. Passons maintenant à ce que nous avons vu de l'extérieur.

 Rencontrez BGP

 BGP signifie Border Gateway Protocol. C'est un mécanisme permettant d'échanger des informations de routage entre des systèmes autonomes (AS) sur Internet. Les gros routeurs qui font fonctionner Internet ont d'énormes listes constamment mises à jour des routes possibles qui peuvent être utilisées pour livrer chaque paquet réseau à leurs destinations finales. 

Sans BGP, les routeurs Internet ne sauraient pas quoi faire et Internet ne fonctionnerait pas. Internet est littéralement un réseau de réseaux, et il est lié par BGP. BGP permet à un réseau (par exemple Facebook) d'annoncer sa présence à d'autres réseaux qui forment Internet. Au moment où nous écrivons, Facebook ne fait pas de publicité pour sa présence, les FAI et autres réseaux ne peuvent pas trouver le réseau de Facebook et il est donc indisponible. Les réseaux individuels ont chacun un ASN : un numéro de système autonome. Un système autonome (AS) est un réseau individuel avec une politique de routage interne unifiée. 

Un AS peut générer des préfixes (disons qu'il contrôle un groupe d'adresses IP), ainsi que des préfixes de transit (disons qu'il sait comment atteindre des groupes spécifiques d'adresses IP).  L'ASN de Cloudflare est AS13335.(Pourtant le 26 septembre ,une fausse page facebook circulait par un lien dans messenger a cette adresse https://l1x.eu) Chaque ASN doit annoncer ses routes de préfixe vers Internet en utilisant BGP ; sinon, personne ne saura comment se connecter et où nous trouver. Notre centre d'apprentissage a un bon aperçu de ce que sont BGP et ASN et comment ils fonctionnent. 

 Dans ce schéma simplifié, vous pouvez voir six systèmes autonomes sur Internet et deux routes possibles qu'un paquet peut utiliser pour aller du début à la fin.

 AS1 → AS2 → AS3 étant le plus rapide, et AS1 → AS6 → AS5 → AS4 → AS3 étant le plus lent, mais cela peut être utilisé si le premier échoue. 

 À 15h58 UTC, nous avons remarqué que Facebook avait cessé d'annoncer les routes vers leurs préfixes DNS. 

Cela signifiait qu'au moins les serveurs DNS de Facebook n'étaient pas disponibles. À cause de cela, le résolveur DNS 1.1.1.1 de Cloudflare ne pouvait plus répondre aux requêtes demandant l'adresse IP de facebook.com. routes-vues> afficher l'ip bgp 185.89.218.0/23 % Réseau non dans le tableau routes-vues> route-vues> afficher l'ip bgp 129.134.30.0/23 % Réseau non dans le tableau routes-vues> 

 Pendant ce temps, d'autres adresses IP Facebook restaient routées mais n'étaient pas particulièrement utiles car sans DNS, Facebook et les services associés étaient effectivement indisponibles : route-vues> afficher l'ip bgp 129.134.30.0 Entrée de table de routage BGP pour 129.134.0.0/17, version 1025798334 Chemins : (24 disponibles, meilleur n°14, table par défaut) Non annoncé à aucun pair Rafraîchir l'époque 2 3303 6453 32934 217.192.89.50 à 217.192.89.50 (138.187.128.158) Origine IGP, localpref 100, valide, externe Communauté : 3303 : 1004 3303 : 1006 3303 : 3075 6453 : 3000 6453 : 3400 6453 : 3402 chemin 7FE1408ED9C8 État RPKI introuvable rx pathid : 0, tx pathid : 0 Rafraîchir l'époque 1 routes-vues> 

 Nous gardons une trace de toutes les mises à jour et annonces BGP que nous voyons dans notre réseau mondial. À notre échelle, les données que nous collectons nous donnent une idée de la façon dont Internet est connecté et où le trafic est censé circuler depuis et vers partout sur la planète. 

 Un message BGP UPDATE informe un routeur de toute modification que vous avez apportée à une annonce de préfixe ou retire entièrement le préfixe. Nous pouvons clairement le voir dans le nombre de mises à jour que nous avons reçues de Facebook lors de la vérification de notre base de données BGP de séries chronologiques. 

Normalement, ce graphique est assez calme : Facebook n'apporte pas beaucoup de changements à son réseau minute par minute. Mais vers 15h40 UTC, nous avons vu un pic de changements de routage de Facebook. C'est alors que les ennuis ont commencé. Si nous divisons cette vue par les annonces d'itinéraires et les retraits, nous obtenons une même meilleure idée de ce qui s'est passé.

 Des routes ont été retirées, les serveurs DNS de Facebook ont ​​été déconnectés et une minute après que le problème se soit produit, les ingénieurs de Cloudflare étaient dans une pièce se demandant pourquoi 1.1.1.1 ne pouvait pas résoudre facebook.com et s'inquiétant qu'il s'agisse d'un problème avec nos systèmes. Avec ces retraits, Facebook et ses sites se sont effectivement déconnectés d'Internet.

 DNS est affecté

 En conséquence directe de cela, les résolveurs DNS du monde entier ont cessé de résoudre leurs noms de domaine. ➜ ~ creuser @1.1.1.1 facebook.com ;; ->>HEADER<<- code opération : QUERY, statut : SERVFAIL, id : 31322 ;facebook.com. DANS UN ➜ ~ creuser @ 1.1.1.1 whatsapp.com ;; ->>HEADER<<- code opération : QUERY, statut : SERVFAIL, id : 31322 ;whatsapp.com. DANS UN ➜ ~ creuser @8.8.8.8 facebook.com ;; ->>HEADER<<- code opération : QUERY, statut : SERVFAIL, id : 31322 ;facebook.com. DANS UN ➜ ~ creuser @ 8.8.8.8 whatsapp.com ;; ->>HEADER<<- code opération : QUERY, statut : SERVFAIL, id : 31322 ;whatsapp.com. 

DANS UN Cela se produit parce que le DNS, comme de nombreux autres systèmes sur Internet, possède également son mécanisme de routage. 

Lorsque quelqu'un tape l'URL https://facebook.com dans le navigateur, le résolveur DNS, responsable de la traduction des noms de domaine en adresses IP réelles auxquelles se connecter, vérifie d'abord s'il a quelque chose dans son cache et l'utilise. Sinon, il essaie de récupérer la réponse des serveurs de noms de domaine, généralement hébergés par l'entité qui en est propriétaire. Si les serveurs de noms sont inaccessibles ou ne répondent pas pour une autre raison, un SERVFAIL est renvoyé et le navigateur envoie une erreur à l'utilisateur.

 Encore une fois, notre centre d'apprentissage fournit une bonne explication sur le fonctionnement du DNS. En raison de l'arrêt de Facebook d'annoncer leurs routes de préfixe DNS via BGP, nos résolveurs DNS et tous les autres n'avaient aucun moyen de se connecter à leurs serveurs de noms. Par conséquent, 1.1.1.1, 8.8.8.8 et d'autres principaux résolveurs DNS publics ont commencé à émettre (et à mettre en cache) des réponses SERVFAIL. Mais ce n'est pas tout. Maintenant, le comportement humain et la logique d'application entrent en jeu et provoquent un autre effet exponentiel. Un tsunami de trafic DNS supplémentaire s'ensuit.

 Cela s'est produit en partie parce que les applications n'accepteront pas une erreur pour une réponse et commenceront à réessayer, parfois de manière agressive, et en partie parce que les utilisateurs finaux ne prendront pas non plus une erreur pour une réponse et commenceront à recharger les pages, ou à tuer et relancer leur applications, parfois aussi agressivement.

 Voici l'augmentation du trafic (en nombre de requêtes) que nous avons constaté sur 1.1.1.1 : Alors maintenant, parce que Facebook et leurs sites sont si grands, nous avons des résolveurs DNS dans le monde entier qui traitent 30 fois plus de requêtes que d'habitude et peuvent causer des problèmes de latence et de délai d'attente à d'autres plates-formes.

 Heureusement, 1.1.1.1 a été conçu pour être gratuit, privé, rapide (comme peut en témoigner le moniteur DNS indépendant DNSPerf) et évolutif, et nous avons pu continuer à servir nos utilisateurs avec un impact minimal. La grande majorité de nos requêtes DNS ont continué à se résoudre en moins de 10 ms.

 Dans le même temps, une fraction minimale des centiles p95 et p99 a vu ses temps de réponse augmenter, probablement en raison des TTL expirés devant recourir aux serveurs de noms Facebook et au délai d'attente.

 La limite de temporisation DNS de 10 secondes est bien connue des ingénieurs. Impact sur d'autres services Les gens recherchent des alternatives et veulent en savoir plus ou discuter de ce qui se passe. Lorsque Facebook est devenu inaccessible, nous avons commencé à voir une augmentation des requêtes DNS vers Twitter, Signal et d'autres plateformes de messagerie et de médias sociaux. Nous pouvons également voir un autre effet secondaire de cette inaccessibilité dans notre trafic WARP vers et depuis l'ASN 32934 affecté de Facebook.

 Ce graphique montre comment le trafic est passé de 15:45 UTC à 16:45 UTC par rapport à trois heures auparavant dans chaque pays. Partout dans le monde, le trafic WARP vers et depuis le réseau de Facebook a tout simplement disparu. L'Internet Les événements d'aujourd'hui nous rappellent en douceur qu'Internet est un système très complexe et interdépendant de millions de systèmes et de protocoles fonctionnant ensemble. Cette confiance, cette normalisation et cette coopération entre les entités sont au cœur de son fonctionnement pour près de cinq milliards d'utilisateurs actifs dans le monde.

 Mettre à jour Vers 21h00 UTC, nous avons vu une activité BGP renouvelée du réseau de Facebook qui a culminé à 21h17 UTC. Ce graphique montre la disponibilité du nom DNS « facebook.com » sur le résolveur DNS de Cloudflare 1.1.1.1. Il a cessé d'être disponible vers 15h50 UTC et est revenu à 21h20 UTC. Il ne fait aucun doute que les services Facebook, WhatsApp et Instagram mettront plus de temps à se mettre en ligne, mais à 21h28 UTC, Facebook semble être reconnecté à l'Internet mondial et le DNS fonctionne à nouveau.

 

Note:

 Les prises de paroles ont leur importance dans ces moments-là, et celle de John Graham-Cumming, le CTO de l'hébergeur Cloudflare, est intéressante. Le spécialiste explique avoir remarqué, quelques minutes avant que les DNS de Facebook ne tombent, que ces derniers avaient subi un nombre très important de modifications des routeurs BGP. Pour schématiser, ces routeurs permettent à la machine de fonctionner. Une erreur humaine pourrait être la cause de l'incident, mais cela reste évidemment à confirmer.

Entre-temps, l'utilisateur de Reddit u/ramenporn, qui prétendait être un employé de Facebook travaillant à ramener le réseau social d'entre les morts, a signalé, avant de supprimer son compte et ses messages, que "les services DNS pour FB ont été affectés et cela est probablement un symptôme du problème réel, et c'est que l'appairage BGP avec les routeurs d'appairage Facebook a baissé, très probablement en raison d'un changement de configuration qui est entré en vigueur peu de temps avant les pannes (a commencé à environ 1540 UTC)."Selon, Ramenporn de Reddit,il a également déclaré qu'il ne s'agissait pas d'une attaque, mais d'un changement de configuration erroné effectué via une interface Web. Ce qui pue vraiment - et pourquoi Facebook est toujours en panne quelques heures plus tard - c'est que puisque BGP et DNS sont en panne, la "connexion au monde extérieur est en panne, l'accès à distance à ces outils n'existe plus, donc la procédure d'urgence est d'obtenir un accès physique aux routeurs de peering et de faire toute la configuration localement." Bien entendu, les techniciens sur site ne savent pas comment faire et les administrateurs réseau seniors ne sont pas sur place. C'est, en bref, un gros gâchis.

 Selon Jean-Loup Delmas: Une autre affaire est en cours en parallèle, concernant une prétendue fuite des données de 1,5 milliard de profils Facebook. Ces dernières seraient en vente sur le darkweb, à la suite d’une cyberattaque effectuée peu de temps avant le bug de Facebook, mais qui n’aurait donc rien à voir avec lui, constituant une simple coïncidence. Néanmoins, il faut là aussi avancer avec prudence. Une telle récolte de données serait inédite, et consisterait en un véritable exploit. Rien ne dit que cette rumeur est crédible et que les données ont bel et bien été volées.Mais une simple attaque XSS est plausible !

Car la fausse page facebook n'avait pas l'adresse internet facebook.com!!!

C'est frort probable une attaque script intersites ? Le script intersites (XSS) est un exploit dans lequel l'attaquant attache du code à un site Web légitime qui s'exécutera lorsque la victime chargera le site Web. Ce code malveillant peut être inséré de plusieurs manières. Le plus souvent, il est soit ajouté à la fin d'une URL, soit publié directement sur une page qui affiche le contenu généré par l'utilisateur. En termes plus techniques, le cross-site scripting est une attaque par injection de code côté client. Attaque de script intersites Qu'est-ce que le code côté client ?

 Le code côté client est un code JavaScript qui s'exécute sur la machine d'un utilisateur. En termes de sites Web, le code côté client est généralement un code exécuté par le navigateur Web une fois que le navigateur a chargé une page Web. Cela contraste avec le code côté serveur, qui est exécuté sur le serveur Web de l'hôte Le code qui s'exécute côté client est très populaire dans le développement Web moderne et est utilisé sur la plupart des sites Web modernes. Étant donné que le code intersites est un élément essentiel du Web moderne, les scripts intersites sont devenus l'une des vulnérabilités de cybersécurité les plus fréquemment signalées, et les attaques de scripts intersites ont frappé des sites majeurs tels que YouTube, Facebook et Twitter.

Même problême en Mars 2021: Durée 1 hr !!!

 

Sur Downdetector, près de 20 000 signalements ont été recensés en France, et plus de 130 000 aux Etats-Unis. Les internautes ont également manifesté leur agacement sur Twitter avec les hashtags #whatsappdown et #instagramdown.

Les patrons d'instagram, WhatsApp devant les pannes #instagramdown pic.twitter.com/7hC9KGv3rG

— Morgane (@mei_atsuko) March 19, 2021

Un peu moins d’une heure après, la situation est revenue progressivement à la normale sur les différentes applications. «Des utilisateurs ont eu des difficultés à accéder à certains services Facebook à cause d’un problème technique», a confirmé auprès de l’AFP un porte-parole du groupe, qui chapeaute les trois applications, avant d’ajouter : «Nous avons résolu le problème pour tout le monde et nous nous excusons pour la gêne occasionnée.»

 

 

Selon FB: Des changements de configuration sur les routeurs backbone ?

Pour expliquer la panne générale rencontrée, Facebook évoque des changements de configuration sur les routeurs backbone qui coordonnent le trafic réseau entre les centres de données. Ils auraient causé des problèmes de communication, et par conséquent entraîné une perturbation du trafic réseau, amenant inévitablement à l’arrêt des services.Le serveur AS13335 serait situer au Kansas dans le fond de l'eau a 42 pieds dans le réservoir cheney,probablement compliqué a faire des manipulations en hardware a ce niveau la !!! 

Les ingénieurs de facebook nous expliquent qu'Au cours de l’un de ces travaux de maintenance de routine, une commande a été émise avec l’intention d’évaluer la disponibilité de la capacité du réseau fédérateur mondial, ce qui a involontairement interrompu toutes les connexions de notre réseau fédérateur(relier au gros serveur backbone AS32934), déconnectant efficacement les centres de données Facebook dans le monde. Nos systèmes sont conçus pour auditer des commandes comme celles-ci afin d’éviter de telles erreurs, mais un bogue dans cet outil d’audit l’a empêché d’arrêter correctement la commande. Un bogue ;-) ???????

Le DNS vous indique où vous rendre, et BGP vous précise comment

Sauf que pour pouvoir utiliser le DNS, il faut, comme pour tout type de serveur, aussi savoir comment s’y rendre. Or, sans BGP, trouver son chemin était justement impossible. Pour reprendre la métaphore de l’annuaire, c’est un peu comme si ce dernier ne se trouvait pas chez vous mais dans la maison d’un ami. Sans BGP, il était déjà impossible d’exploiter les informations fournies par l’annuaire, mais il était aussi tout bonnement impossible de même aller le chercher.

Qu’est-ce qui a déclenché la panne en premier lieu ?

On ne sait pas encore. L’enchaînement des faits n’est pas encore totalement connu à ce stade, mais peu avant 18 heures, lundi, Facebook a procédé à une mise à jour BGP (la « carte collaborative », donc) en expliquant que certains chemins menant à ses DNS n’étaient plus valides. Il a été soudainement très difficile de joindre ces serveurs, ce qui a bloqué une grande partie des connexions. Facebook a aussi, plus largement, déclaré comme inutilisables l’ensemble des chemins informatiques menant à ses serveurs, se coupant de fait du reste de l’Internet.

 

REF.:

Comment obtenir une vitesse Internet plus rapide en utilisant DNS Hack ?

Il existe plusieurs façons d'obtenir une vitesse Internet plus rapide dans Microsoft Windows. Aujourd'hui, je vais vous montrer un simple piratage DNS qui peut accélérer votre navigation sur le Web de façon spectaculaire. Tout d'abord, je dois vous rappeler une chose évidente qui arrive avec la plupart d'entre nous lorsque nous utilisons une connexion Internet lente. La seule chose que nous reprochons est notre fournisseur de services Internet (FAI) pour une connexion Internet lente, mais ce n'est pas le seul cas tout le temps. Parfois, le problème réside dans notre système DNS (Domain Name System). Alors, permettez-moi de vous expliquer quelque chose au sujet du DNS avant de vous indiquer la méthode pour obtenir une vitesse rapide sur Internet.Qu'est-ce qu'un DNS?DNS - Système de noms de domaine (Service / Serveur) - est quelque chose qui convertit vos noms de domaine en adresses IP.
Les noms de domaine sont généralement alphabétiques pour nous nous souvenir facilement, mais en réalité, Internet fonctionne sur les adresses IP. Le DNS convertit le nom de domaine en son adresse IP correspondante, chaque fois qu'il est utilisé comme tel. Le DNS possède un réseau propre, c'est-à-dire qu'un serveur DNS peut demander à d'autres serveurs DNS de traduire un nom de domaine spécifique sur son adresse IP correspondante jusqu'à ce qu'il obtienne le résultat correct.
Les ordinateurs et autres appareils utilisent l'adresse IP pour acheminer le trafic et il est très semblable à la numérotation d'un numéro de téléphone. DNS agit comme un opérateur intelligent qui nous aide à contourner le carnet d'adresses infinie des adresses IP. Votre DNS gère cette énorme tâche.Comment un service DNS alternatif accélérera votre navigation?
Comme je l'ai mentionné plus tôt, votre vitesse de l'Internet sans tortue n'est pas toujours la faute de votre fournisseur d'accès Internet, à la place, il se peut que votre DNS soit responsable. Alors, pourquoi ne pas utiliser un autre service DNS? Comme les pages Web actuelles continuent de devenir de plus en plus complexes en inculquant d'innombrables choses. Ainsi, les clients recherchent plusieurs recherches DNS pour rendre une seule page Web. Avec la croissance continue du Web, l'infrastructure DNS existante est plus chargée chaque jour.
Maintenant, je vais vous dire d'utiliser un service DNS public gratuit qui informera votre ordinateur d'utiliser ce service plutôt que d'utiliser votre service prescrit par le fournisseur d'accès Internet et vous aidera à obtenir une vitesse plus rapide sur Internet
Recommandé: Qu'est-ce que le DNS (Domain Name System) et comment ça marche ?

Comment accélérer la navigation sur le Web en utilisant DNS Hack?
Pour obtenir une vitesse internet plus rapide, je vais vous parler du service gratuit OpenDNS. Vous pouvez également utiliser Google DNS pour accélérer votre connexion Internet. OpenDNS est l'un des services DNS gratuits les plus populaires qui a commencé à fournir une méthode alternative à ceux qui étaient mécontents de leurs DNS existants. Par la suite, je parle de OpenDNS; Trouver Google DNS après cela.
En suivant ces étapes simples, vous pouvez indiquer à votre ordinateur d'utiliser les serveurs DNS OpenDNS au lieu de ceux que votre fournisseur de services utilise automatiquement:Ouvrir DNS:
Étape 1:
Pour obtenir une vitesse Internet plus rapide à l'aide de OpenDNS, ouvrez le panneau de configuration.
Étape 2:
Aller à Network and Internet options.network-and-internet
Étape 3:
Maintenant, cliquez sur Réseau et Centre de partage.
centre de réseau et partage
Étape 4:
Cliquez sur votre connexion Internet, puis cliquez sur Propriétés.
connexion Internet
Étape 5:
Cliquez sur Internet Protocol Version 4 (TCP / IPv4) et cliquez sur Propriétés.
DNS-hack-fast-browse
Étape 6:
Choisissez maintenant les adresses de serveur DNS suivantes pour obtenir une vitesse d'Internet plus rapide:

    Serveur DNS préféré: 208.67.222.222
    Serveur DNS alternatif: 208.67.220.220
Ipv4-config-speedup-browsing
Vous utilisez maintenant les serveurs OpenDNS qui vous permettent d'obtenir une vitesse internet plus rapide.
Pour configurer IPv6:
Mettez en surbrillance le protocole Internet Version 6 (TCP / IPv6) et cliquez sur Propriétés, et choisissez les adresses de serveur DNS suivantes:

    Serveur DNS préféré: 2620: 0: ccc :: 2
    Serveur DNS alternatif: 2620: 0: ccd :: 2DNS-hack-faster-browsing
Google DNS:
Remplacez ces adresses par les adresses IP des serveurs DNS Google à l'étape 6.
Pour IPv4: 8.8.8.8 et / ou 8.8.4.4.
Pour IPv6: 2001: 4860: 4860 :: 8888 et / ou 2001: 4860: 4860 :: 8844
Conclusion:
Il existe plus d'avantages de OpenDNS et de Google DNS que d'obtenir une vitesse internet plus rapide. Habituellement, si le serveur DNS de votre fournisseur de services diminue, vous devenez incapable d'utiliser Internet, mais avec la méthode OpenDNS et Google DNS, même si le serveur DNS du fournisseur de services est en panne, vous pouvez naviguer sur Internet normalement.
Google DNS et OpenDNS fonctionnent très bien, mais les gens préfèrent Google DNS ces jours-ci. Vous pouvez choisir d'aller pour l'un de ces derniers et voir si votre Internet accélère.
Avez-vous aimé cette méthode pour obtenir une vitesse internet plus rapide en utilisant un simple DNS hack? Dites-nous dans les commentaires!
En savoir plus sur le DNS (Domain Name System) et son travail ici.

Source.:

The Pirate Bay, T411 : contourner un blocage DNS, c'est trop facile !

DR

Ce n’est pas parce qu’un site est banni par la justice que celui-ci devient réellement inaccessible. Il existe des moyens techniques simples pour contourner ce blocage.

Le 4 décembre dernier, le TGI de Paris a ordonné aux opérateurs Orange, Bouygues, Free et SFR d’empêcher leurs internautes d’accéder au site thepiratebay.se ainsi qu’à certains de ses sites miroirs. Cette décision faisait suite à une plainte de la Société civile des producteurs photographiques (SCPP), qui voit d’un mauvais œil le partage de contenu musical protégé par le droit d’auteur. Mais comment ce blocage sera-t-il mis en œuvre concrètement ? Et peut-on le contourner ? En un mot : oui, et c'est d'ailleurs tellement simple que ce genre de censure n'a que très peu d'intérêt. Voici quelques éléments pour y voir plus clair.

Comment les FAI bloquent-ils les sites jugés illégaux ?

Lorsqu’une décision de justice ordonne le blocage d’un site, le choix technique est généralement laissé aux FAI. D’après l’Association de fournisseurs d’accès (AFA), c’est exclusivement le blocage DNS qui est utilisé, pour des raisons pratiques et de coûts. Le DNS, c’est l’annuaire du web. Ce système permet de transposer une URL (www.01net.com par exemple)  en adresse IP (173.31.6.199 par exemple), utilisable par les routeurs pour acheminer les données du Net.
Lorsqu’un internaute veut accéder à un site web, son navigateur va généralement récupérer la bonne adresse IP au travers du résolveur DNS de son FAI. Un résolveur DNS est un logiciel qui se charge de répondre à une requête DNS, soit directement (parce qu’il connait déjà l’URL), soit indirectement (en interrogeant le registre concerné, tel que .COM, .FR ou .SE). C’est au niveau de ce résolveur que le FAI va mettre en œuvre le blocage ordonné par la justice. Lorsque son client voudra accéder à un site bloqué, ce logiciel ne lui fournira pas l’adresse IP recherchée, mais l’aiguillera sur un message de type « Attention, ce site a été bloqué ou n’existe pas ».

Une fois mis en œuvre, un blocage DNS est-il effectif partout ?

Non. Tout d’abord, un blocage de site ordonné par la justice française n’est valable qu’en France. A l’étranger, le site visé pourra donc être accessible. Par ailleurs, tous les FAI français ne sont pas forcément concernés par une décision de blocage. Dans le cas de The Pirate Bay, seuls quatre opérateurs ont été sommés de mettre en œuvre le blocage : Orange, Bouygues, Free, et SFR. Si vous êtes client de Numéricable ou d’un FAI associatif, vous n’êtes pas concerné.
Enfin, le blocage n’est effectif que sur les sites qui sont nommés par la décision de justice. Pour contourner cette mesure, il suffit donc que quelqu’un crée un site miroir. C’est d’ailleurs ce que vient de faire le Parti Pirate français pour The Pirate Bay. Pour bloquer ce nouveau site, il faudra lancer une nouvelle procédure judiciaire.

Les internautes peuvent-ils contourner un blocage DNS ?

Oui, et il existe même plusieurs façons de le faire. La première est simple, mais pas forcément pratique: changer de FAI. Pour continuer à télécharger leurs torrents favoris, les fans de The Pirate Bay pourraient ainsi s’abonner à Numéricable ou à French Data Network, qui ne sont pas concernés par la décision de justice.
Une autre solution un peu plus compliquée consiste à changer de résolveur DNS. Cela peut se faire soit au niveau du routeur d’accès, soit au niveau du terminal. Tous les routeurs d’accès ne permettent pas de configurer un serveur DNS. Il faut se reporter à la notice. Sur un terminal, cela dépend du système d’exploitation. Pour Windows 7, par exemple, il faut aller dans « Panneau de configuration -> Réseau et Internet -> Connexion au réseau local -> Propriétés -> Protocole Internet version 4 -> Propriétés ». Puis il faut cocher la case « Utiliser l’adresse de serveur DNS suivante : » et insérer les adresses IP qui vont bien.

© DR

Sur Mac OS X, il faut aller dans « Préférences système -> Réseau -> Avancé -> DNS ». On peut alors renseigner les adresses IP du nouveau résolveur.

© DR

Sur iOS ou Android, on ne peut pas changer de DNS pour une connexion cellulaire : c’est l’opérateur mobile qui décide, un point c’est tout. En mode Wifi, en revanche, c’est possible. Il faut aller dans les menus de paramètres. Pour avoir plus d’informations, voici une note de blog intéressante de Stéphane Bortzmeyer.

D’accord, mais quel résolveur DNS choisir ?

Il existe plusieurs résolveurs DNS qui sont libres d’accès, par exemple Google Public DNS (8.8.8.8 / 8.8.4.4), OpenDNS (208.67.222.222 / 208.67.220.220) ou celui de French Data Network (80.67.169.12).  Mais choisir un nouveau DNS est aussi une question de confiance. Que fera Google des données de connexion qu’il recevra ? Pourront-elles être siphonnées par les autorités américaines, par le biais du Patriot Act ? Mon nouveau DNS n’est-il pas soumis à son tour à une procédure de filtrage ou de blocage ? Ce sont là de vraies questions.
C’est pourquoi certains paranoïaques, qui ne font confiance à personne, optent pour une autre solution : créer son propre résolveur DNS. Dans ce cas, on est dépendant de personne. Mais cette solution est assez technique et dépasse le cadre de cet article. Les plus téméraires pourront commencer par cette autre note de blog de Stéphane Bortzmeyer.
source.:

***************************

ou bien:
Comme je me refuse catégoriquement à conseiller à qui que ce soit d’utiliser les DNS de Google, sachant ce que cette société fait des informations qu’elle recueille sur vous et comment elle piétine allègrement votre vie privée, comme par ailleurs OpenDNS n’est plus indépendant, je vous propose d’utiliser les services d’OpenNIC, qui ne garde aucune trace de votre surf, et est totalement libre de toute influence (pour ne pas dire plus) de quelque gouvernement que ce soit. La seule différence que j’ai pu observer par rapport à l’ICANN, c’est que ces DNS ne résolvent pas les adresses ayant .tk pour extension. Dans la mesure où la quasi totalité des sites qui utilisent cette extension sont peu recommandables, cela ne me semble pas être un point bloquant. Si vous avez cependant besoin de vous rendre sur un site ayant une telle extension, il vous faudra passer par son adresse IP.
Il va sans dire que si vous préférez utiliser d’autres services que ceux d’OpenNIC (ceux de la FDN, par exemple, que je n’ai pas osé vous recommander de peur qu’ils ne tiennent pas l’afflux de charge), c’est à votre convenance. Il vous suffit de remplacer les adresses IP par celles qui auront votre préférence.
Commencez par vous rendre sur cette page : https://www.opennicproject.org/nearest-servers/, et copiez deux des quatre adresses IP qui vous sont proposées (une adresse IP est une série de quatre nombres compris entre 0 et 255).

Si rien ne s’affiche, c’est vraisemblablement un de vos modules complémentaires
qui bloque l’exécution des javascripts, il vous faut le désactiver temporairement.

Si malgré cela, vous n’obtenez toujours aucune adresse IP, choisissez-en deux parmi les quatre ci-dessous, vous ne perdrez au pire que quelques millisecondes, et ce seulement à votre première visite sur un site.

Si vous utilisez Windows :

1) Si vous êtes sous Windows XP, cliquez sur le Menu Démarrer, puis sur le panneau de configuration. Choisissez « Connexions réseau et internet », puis « Connexions réseau ».
2) Si vous êtes sous Windows Vista, cliquez sur le Menu Démarrer, puis sur le panneau de configuration. Choisissez « Réseau et internet », puis « Centre Réseau et partage », puis « Gérer les connexions réseau ».
3) Si vous êtes sous Windows 7, cliquez sur le Menu Démarrer, puis sur le panneau de configuration. Choisissez « Réseau et internet », puis « Centre Réseau et partage », puis « Modifier les paramètres de la carte ».
4) Si vous êtes sous Windows 8, cliquez sur le Bureau. Cliquez avec le bouton droit de votre souris sur l’icône du réseau de la barre des tâches (en bas à droite), puis « Modifier les paramètres de la carte » une fois que le Centre réseau et partage s’est ouvert.

Vous devez avoir en principe au moins deux connexions différentes (une filaire sans doute nommée Ethernet ou Lan, et une WiFi). Choisissez l’une des deux, cliquez dessus avec le bouton droit de votre souris, et sélectionnez « Propriétés » (il me semble que sous Windows 8, il faut cliquer avec le bouton gauche, et choisir le bouton « Propriétés » dans la fenêtre qui s’ouvre).
Une fenêtre s’ouvre. Dans le cadre central, cliquez (simple clic) sur « Protocole internet version 4 (TCP/IPv4) », puis cliquez sur « Propriétés ».
Dans la nouvelle fenêtre qui s’ouvre (onglet « Général »), changez l’option « Obtenir les adresses des serveurs DNS automatiquement » pour sélectionner à la place « Utiliser l’adresse de serveur DNS suivante ».

À l’emplacement « Serveur DNS préféré », saisissez :

178.32.122.65

À l’emplacement « Serveur DNS auxiliaire », saisissez :

37.187.0.40

Validez en cliquant sur « OK ».
Faites exactement la même chose pour votre(vos) autre(s) connexion(s).

Votre navigateur ayant en mémoire toutes les correspondances URL/adresse IP des sites que vous avez visités, et celles-ci ayant été établies par le DNS de votre FAI, il vous faut maintenant les effacer.

Fermez-le, puis ouvrez une invite de commande (cmd.exe), et tapez :

ipconfig /flushdns

Pensez aussi à redémarrer aussi votre client BitTorrent
C’est tout, vous utilisez maintenant OpenNIC. Si les changements n’ont pas été pris en compte, un redémarrage de Windows résoudra le problème.

---

Si vous utilisez Mac :

Ouvrez le Menu Pomme et cliquez sur « Préférences système ». Dans la fenêtre qui s’ouvre, choisissez « Réseau ».
Choisissez la première connexion de la liste à gauche, et cliquez sur le bouton « Avancé ».
Cliquez sur l’onglet « DNS », et ajoutez en tête de la liste des serveurs DNS ceux d’OpenNIC (vous pouvez même supprimer les autres si vous ne pensez plus les utiliser) :

178.32.122.65

37.187.0.40

Validez en cliquant sur « OK ».

Votre navigateur ayant en mémoire toutes les correspondances URL/adresse IP des sites que vous avez visités, et celles-ci ayant été établies par le DNS de votre FAI, il vous faut maintenant les effacer. Ouvrez un terminal (vous le trouverez dans applications / utilitaires)

Si vous utilisez OS X Yosemite 10.10.4, tapez :

sudo killall -HUP mDNSResponder

Si vous utilisez OS X Yosemite 10.10 à 10.10.3, tapez :

sudo discoveryutil mdnsflushcache

Si vous utilisez OS X Mavericks, Mountain Lion, ou Lion, tapez :

sudo killall -HUP mDNSResponder

Si vous utilisez Mac OS X 10.6, tapez :

sudo dscacheutil -flushcache

Pensez aussi à redémarrer aussi votre client BitTorrent
C’est tout, vous utilisez maintenant OpenNIC. Si les changements n’ont pas été pris en compte, un redémarrage du système résoudra le problème.

---

Si vous utilisez Linux :

1) Si vous utilisez un gestionnaire de bureau, vous devez avoir une icône du réseau dans votre barre des tâches (si vous n’en avez pas et ne désirez pas la mettre, ou si vous n’avez pas installé de barre des tâches, vous pouvez toujours vous rendre dans les paramètres du système — choisissez Netwok Manager — ou passer aux étapes 2 ou 3 ci-dessous).
Cliquez dessus (bouton gauche ou droit selon votre environnement) et choisissez l’option « Propriétés » (qui peut être « Modifier », sous Xfce notamment).
Choisissez votre première connexion et cliquez sur « Modifier » ou « Options » (cela dépend de votre distribution).

Rendez-vous dans les paramètres IPv4.
Si la « Méthode » est « Automatique (DHCP) », changez-la pour « Adresses automatiques uniquement (DHCP) ». Sinon, n’y touchez pas.

178.32.122.65, 37.187.0.40

Validez, et faites la même chose pour vos autres connexions.
Videz maintenant votre cache DNS.

Ouvrez un terminal, et tapez :

sudo /etc/init.d/dns-clean force-reload

Pensez aussi à redémarrer aussi votre client BitTorrent
C’est tout, vous utilisez maintenant OpenNIC. Si les changements n’ont pas été pris en compte, un redémarrage résoudra le problème (redémarrer les connexions réseau devrait suffire).

2) Si vous utilisez une distribution Debian ou dérivée de Debian (comme Ubuntu), le changement via le network manager peut n’être pas suffisant. Dans ce cas, il vous faut éditer vos fichiers de configuration.

Ouvrez un terminal, et tapez :

sudo votre_éditeur_de_texte_préféré /etc/resolv.conf

En fin de fichier, ajoutez les lignes :

nameserver 178.32.122.65

nameserver 37.187.0.40

et allez à la ligne. Enregistrez les modifications et fermez le fichier.
S’il est écrit dans le fichier (ce sera le cas sur les variantes d’Ubuntu) :
« # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN »
il faut alors écrire les lignes en question dans « /etc/resolvconf/resolv.conf.d/base » :

sudo votre_éditeur_de_texte_préféré /etc/resolvconf/resolv.conf.d/base

et dans « /etc/resolvconf/resolv.conf.d/head », pour rendre les changements persistants :

sudo votre_éditeur_de_texte_préféré /etc/resolvconf/resolv.conf.d/head

Il y a le même message dans ce dernier fichier que dans resolv.conf, mais il ne faut pas en tenir compte, ce que vous écrivez ne sera pas écrasé (ce texte est simplement lu pour être recopié dans resolv.conf à chaque réécriture de ce dernier).

Ensuite, il faut faire une mise à jour de resolvconf :

sudo resolvconf -u

Et votre fichier /etc/resolv.conf contient bien les lignes :
nameserver 178.32.122.65
nameserver 37.187.0.40
Videz maintenant votre cache DNS.

Ouvrez un terminal, et tapez :

sudo /etc/init.d/dns-clean force-reload

Pensez aussi à redémarrer aussi votre client BitTorrent
C’est tout, vous utilisez maintenant OpenNIC. Si les changements n’ont pas été pris en compte, un redémarrage résoudra le problème (redémarrer les connexions réseau devrait suffire).

3) Si vous utilisez une distribution ayant un dossier « /etc/sysconfig » (en général celles utilisant des paquets rpm), et que vous préférez éditer vos fichiers de configuration, vous êtes concerné par ce point 3.
Attention, je n’ai pas pu tester cette procédure. Elle fonctionnait autrefois sous OpenSuse, mais je ne garantis pas que les emplacements et les noms n’aient pas changé.

Ouvrez un terminal, et tapez :

sudo votre_éditeur_de_texte_préféré /etc/sysconfig/network/config

Changez la ligne « MODIFY_RESOLV_CONF_STATIC_DNS » pour :

MODIFY_RESOLV_CONF_STATIC_DNS="178.32.122.65 37.187.0.40"

Enregistrez les changements, et, toujours dans le terminal, tapez :

sudo /sbin/rcnetwork restart-all-dhcp-clients

pour redémarrer les connexions réseau. Videz maintenant votre cache DNS.

Ouvrez un terminal, et tapez :

sudo /etc/init.d/dns-clean force-reload

Pensez aussi à redémarrer aussi votre client BitTorrent
C’est tout, vous utilisez maintenant OpenNIC. Si les changements n’ont pas été pris en compte, un redémarrage résoudra le problème (redémarrer les connexions réseau devrait suffire).




Source.:

Filtrage DNS

Dernièrement la justice française a décide de bloquer les sites Piratebay et t411 (à l'heure où sont écrites ces lignes, la demande a été faite, la justice n'a pas encore rendu de verdict).
Le site NextImpact en parle : piratebay-bloque-suspendu-t50048.html

D'ici quelques jours, piratebay.se ne devrait donc plus être accessible en France et peut-être aussi t411.me
Le filtrage sera effectué par les FAI (Fournisseurs d'accès Internet) et se fera au niveau des résolutions DNS des adresses concernées.

Cette page explique comment fonctionne ce filtrage.

DISLAIMER : je vous rappelle que le téléchargement d'oeuvre soumis à des droits d'auteurs est interdit et répréhensible par la loi.

Qu'est ce que le filtrage DNS ?

Pour comprendre ce qu'est le filtrage DNS, il faut avoir quelques notions sur le fonctionnement d'un réseau.
Toutes les machines d'un réseaux se voient attribuer une adresse IP (un peu comme une plaque d'immatriculation) qui permet de l'identifier sur le réseau et surtout de la contacter.
Ces adresses sont sous la forme de chiffre par exemple : 192.168.1.1
Vous l'aurez remarqué, ces adresses IPs ne sont pas faciles à retenir.

Dès lors il a été mis en place des adresses litérales plus faciles à retenir :
http://www.google.fr
http://www.malekal.com
ftp.malekal.com
etc

A chaque de ces adresses correspondent une ou plusieurs adresses IPs.
Le travail du service DNS est de faire fonctionner ces correspondances.

Dès lors quand vous tapez http://www.malekal.com - une requête DNS est faite afin de connaître l'adresse IPs qui correspond à cette adresse afin de contacter le serveur malekal.com
Exemple ci-dessous où on demande l'adresse IP correspondant à http://www.google.fr et http://www.malekal.com



Le filtrage DNS consiste donc à empécher de faire correspondre l'adresse littéral à l'adresse IP afin de rendre la connexion vers le serveur impossible.
En général, l'adresse retournée est 0.0.0.0 ou 127.0.0.01 ou un serveur géré par l'administration qui effectue le blocage afin de rediriger les internautes vers un serveur à eux pour afficher une page spécifique.

Notez que ces modifications de DNS peuvent parfois être effectuées par un hébergeur de son propre chef, par exemple, si un serveur est la victime d'une attaque DDoS qui perturbe très fortement le service de l'hébergeur, il peut arriver que l'adresse ciblée soit modifier pour que les ordinateurs zombies qui participent à l'attaque ne le ciblent plus.

Est-il possible de contourner un filtrage DNS ?

Dans le cas d'un filtrage DNS décidé par un pays suite à une décision justice, il est possible de le contourner.
Le filtrage se faisant sur les serveurs DNS des FAI, il suffit d'utiliser des serveurs publiques où le filtrage DNS n'a pas été effectué.
Mais il est tout à fait possible techniquement de bloquer une adresse au niveau mondiale, par exemple, dans le cas d'un malware.

Les deux services publiques et gratuits les plus connus sont : GoogleDNS et OpenDNS.

Il existe deux manières de changer ses DNS :

• Soit au niveau de la configuration du routeur, ceci devrait s'appliquer à tous les ordinateurs qui utilisent ce routeur. Dans le cas d'une boix en général, ce filtrage n'est pas possible, vous n'avez pas la main.
• Dans la configuration réseau de chaque ordinateur.

La page suivante explique comment modifier manuellement (second paragraphe) les serveurs DNS de chaque interface réseau : reinitialiser-les-serveurs-noms-dns-t48312.html
Si vous avez du Wifi et filaire, il faut le faire sur la carte Wifi et réseau local.

• Les adresses DNS des serveurs OpenDNS : 208.67.222.222 et 208.67.220.220
• Les adresses DNS des serveurs GoogleDNS : 8.8.8.8 et 8.8.4.4

Notez qu'OpenDNS permet grâce à ces DNS d'agir en contrôle parental et bloquer l'accès à sites sites selon la thématique, se reporter à cette page : opendns-controle-parental-t48437.html#p377305

Première règle élémentaire de sécurité : on réfléchit puis on clic et pas l'inverse - Les fichiers/programmes c'est comme les bonbons, quand ça vient d'un inconnu, on n'accepte pas

Source.:

P2P: Changer de serveur résolveur DNS facilement

Première rédaction de cet article le 8 janvier 2012
Dernière mise à jour le 9 janvier 2012

---

La sortie, le 30 décembre 2011, du décret n° 2011-2122 relatif aux modalités d'arrêt de l'accès à une activité d'offre de paris ou de jeux d'argent et de hasard en ligne non autorisée, décret qui permet à l'ARJEL de demander le blocage d'un site de paris ou de jeux en ligne, a ramené sur le devant de la scène la question du blocage via le DNS. En effet, le décret dit explicitement « Lorsque l'arrêt de l'accès à une offre de paris ou de jeux d'argent et de hasard en ligne non autorisée a été ordonné, [...] les [FAI] procèdent à cet arrêt en utilisant le protocole de blocage [sic] par nom de domaine (DNS) ». Il existe plusieurs façons de comprendre cette phrase. Si le FAI décide de mettre en œuvre cet arrêt en configurant ses résolveurs DNS pour mentir, un moyen simple de contourner cette censure sera alors pour les utilisateurs de changer de résolveur DNS. Est-ce simple ? Est-ce réaliste ? Des logiciels peuvent-ils aider ?

D'abord, un petit rappel de vocabulaire, car j'ai déjà lu pas mal d'articles sur le sujet, où l'auteur est plein de bonne volonté et veut vraiment aider les autres à contourner la censure, mais où il ne connait pas vraiment le DNS et où il utilise un vocabulaire approximatif, voire complètement faux. Il y a deux sortes de serveurs DNS : la première, ce sont les serveurs faisant autorité, qui sont ceux qui contiennent les données (par exemple, les serveurs de DENIC ont la liste de tous les noms de domaine en .de, des serveurs de la société NS14 font autorité pour le domaine shr-project.org, etc). L'ARJEL ou un autre censeur ne peut pas toujours agir sur eux car ils peuvent être situés en dehors de la juridiction française.

Et il y a les résolveurs DNS. Ils ne connaissent au démarrage aucune donnée et servent uniquement de relais et de caches (stockage temporaire de données). Ils sont typiquement gérés par votre FAI ou bien par le service informatique de votre boîte. Ce sont eux qui sont indiqués à la machine cliente (en général par le protocole DHCP), qui les utilisera à chaque fois qu'elle aura une question (c'est-à-dire pas moins d'une centaine de fois pour la seule page d'accueil de CNN).

Si on veut censurer en France l'accès à un site de jeu en ligne, par le protocole DNS, c'est un bon endroit pour attaquer. Il en existe d'autres, mais que je garde pour d'autres articles. Modifier le comportement du résolveur est facile (les logiciels ont déjà ce qu'il faut pour cela) et certains FAI le faisaient déjà pour des raisons financières.

Mais c'est aussi une technique de censure relativement facile à contourner : l'utilisateur de la machine cliente peut changer la configuration de son système pour utiliser d'autres résolveurs que ceux de son FAI, par exemple ceux de Telecomix, qui promettent de ne pas censurer. C'est cette technique qui est discutée dans cet article.

Si vous lisez les forums un peu au hasard, vous trouverez souvent des allusions à cette méthode, de la part de geeks vantards qui affirment bien haut « rien à foutre de leur censure à la con, je change mon DNS car je suis un top-eXpeRz et je surfe sans filtrage ». La réalité est plus complexe. Prenons l'exemple d'une machine Ubuntu (il y a peu près les mêmes problèmes sur Windows ou Mac OS X). La liste des résolveurs DNS utilisés figure dans le fichier /etc/resolv.conf. Suffit-il d'éditer ce fichier, comme on le lit souvent (et bien à tort) ?

• Déjà, il faut rappeler au frimeur de forum que la grande majorité des utilisateurs de l'Internet n'ont même pas idée qu'ils peuvent choisir (et je ne parle pas seulement du résolveur DNS, mais aussi du navigateur, du système d'exploitation, etc). Si on veut que la solution soit accessible à tout le monde, pas seulement à quelques geeks auto-proclamés, elle doit être simple.
• Même sur Ubuntu, tout le monde ne sait pas éditer un fichier système (surtout qu'il faut être root).
• Le frimeur à grande gueule qui écrit sur forum.blaireaux.com/index.php découvrira vite, s'il essayait ce qu'il prêche, qu'éditer resolv.conf n'est pas la bonne méthode, car le client DHCP effacera ses modifications à la prochaine connexion. Il faut modifier la configuration dudit client DHCP (cela varie énormément selon le système et le logiciel installé ; sur ma Debian, en ce moment, c'est /etc/resolvconf/resolv.conf.d/head).
• Sur certains systèmes d'exploitation, changer un réglage aussi banal est très difficile. Par exemple, sur Android (merci à Aissen pour les informations), les serveurs DNS utilisés sur le réseau mobile ne sont pas modifiables et, sur le Wi-Fi, on ne peut les changer que si on coupe DHCP. Comme la publicité fait tout son possible pour migrer les utilisateurs vers les accès Internet sur téléphone mobile, bien plus contrôlés et moins libres, l'avenir est inquiétant.
• Une fois qu'on sait quel fichier éditer et comment, reste la question, que mettre dans ce fichier ? Il existe plusieurs résolveurs publics situés en dehors du pouvoir de l'ARJEL, et le plus souvent cité est OpenDNS. Intéressant paradoxe : pour échapper à la censure et garder sa liberté de citoyen, on utilise un résolveur menteur, qui pratique lui-même la censure (et parfois se trompe). Utiliser OpenDNS, c'est se jeter dans le lac pour éviter d'être mouillé par la pluie. Sans compter leurs autres pratiques, comme l'exploitation des données personnelles (le résolveur DNS utilisé sait tout de vous... chaque page Web visitée lui envoie au moins une requête...). À noter qu'on peut avoir aussi un résolveur local à sa machine, ce point est traité un peu plus loin.

À noter que tous les cas ne peuvent pas être couverts dans un article. Par exemple, on peut aussi envisager de changer les réglages DNS sur la box si elle sert de relais DNS pour le réseau local vers les « vrais » résolveurs.

Pour résoudre tous ces problèmes, on peut écrire des documentations (exemples à la fin de cet article). Mais la plupart des utilisateurs auront du mal à les suivre et je pense donc que la bonne solution est la disponibiité d'un logiciel qui automatise tout cela. Quel serait le cahier des charges d'un tel logiciel ?

• Tourne sur les systèmes utilisés par M. Toutlemonde (Windows, Android, Ubuntu, etc).
• Indépendant de l'application (le DNS ne sert pas que pour le Web) et marche donc avec tous les services (c'est pourquoi je n'ai pas discuté dans cet article des extensions Firefox comme MAFIAAFire ou DeSOPA - ce dernier ayant en outre un mode de fonctionnement très bizarre).
• Simple à utiliser.
• Vient avec une liste pré-définie de bons résolveurs. Je préférerais que cette liste n'inclue pas les résolveurs menteurs comme ceux d'OpenDNS. En tout cas, il est impératif qu'on puisse ajouter les résolveurs de son choix.
• M. Toutlemonde va certainement avoir des problèmes pour décider s'il doit se servir de « Telecomix » ou « Comodo » ou « Level-3 » pour ne citer que quelque uns des résolveurs publics les plus fameux. Il faudrait donc que le logiciel teste ces résolveurs automatiquement, pour leurs performances, bien sûr (la plupart des articles trouvés sur le Web sur le thème « comment choisir son résolveur DNS ? » ne prennent en compte que leur vitesse, pas leur sincérité, contrairement à cet article) mais aussi pour leur obéissance à la censure. Le logiciel devrait venir avec une liste de domaines peut-être censurés (wikileaks.org, etc) et tester les réponses des résolveurs candidats. Ce n'est pas facile à faire car il faut aussi connaître les bonnes réponses, et elles peuvent changer. Peut-être le logiciel devrait-il interroger des résolveurs de confiance pour avoir cette information ? Le fait de tester pourrait même permettre de choisir automatiquement un résolveur, ce qui serait certainement meilleur pour M. Toutlemonde.
• Autre cas vicieux (merci à Mathieu Goessens), celui des résolveurs DNS qui, en violation des bonnes pratiques, contiennent des données spécifiques qu'on ne trouve pas dans le DNS public. C'est le cas de pas mal de portails captifs de hotspots, par exemple. dnssec-trigger gère ce problème en ayant un mode spécial, manuellement activé, « Hotspot sign-on ». Mais il y a pire : certains FAI (notamment Orange) utilisent des données non publiques pour certains services réservés aux clients (VoIP, serveur SMTP de soumission, etc) donc une solution qui gère la connexion initiale ne suffit pas. La seule solution dans ce cas est d'avoir un mécanisme d'aiguillage qui envoie les requêtes pour certains domaines à certains résolveurs.

Un tel logiciel est vulnérable à un blocage du port 53. Si cette mesure se répand, il faudra aussi que le logiciel teste s'il peut atteindre des résolveurs publics et des serveurs faisant autorité, ou bien s'il faut passer à d'autres méthodes comme de tunneler le DNS sur TLS, port 443, comme le permet déjà Unbound, dans sa version de développement. D'autres attaques suivront alors (par exemple des FAI qui annonceront les adresses 8.8.8.8 et 8.8.4.4 sur leur propre réseau, pour se faire passer pour Google Public DNS, profitant du fait que ce service n'est pas authentifié).

Compte-tenu de ce cahier des charges, quels sont les logiciels qui conviennent aujourd'hui ? Il n'en existe aparemment qu'un seul, DNS Jumper (je ne suis pas sûr d'avoir mis un lien vers le site officiel, ce logiciel n'a pas de références bien précises et, son source n'étant pas distribué, on peut être inquiet de ce qu'il fait). DNS Jumper tourne sur Windows, assure les quatre premières fonctions de mon cahier des charges mais pas l'avant-dernière : il ne vérifie pas que le résolveur est digne de confiance. Il est décrit, par exemple, dans « Easily Switch Between 16 DNS Servers with DNS Jumper » (l'article est un peu ancien, le logiciel s'est perfectionné depuis), ou, en français, dans « DNS Jumper - Changez rapidement de serveurs DNS ».

Les autres logiciels restent à écrire (un truc comme DNS Helper ne compte pas, puisqu'il ne permet de changer... que pour les DNS de Google). Mais que les censeurs ne se réjouissent pas, les logiciels vont vite sortir, écrire un tel programme n'est pas un exploit technique, et la demande est forte, avec le décret ARJEL déja cité pour la France, SOPA pour les États-Unis, etc.

Sur le problème général de changer manuellement ses résolveurs DNS, un bon article est « How to Change DNS Server » de Remah (Windows seulement). Pour Mac OS, un bon article est « Disabling DNS servers from DHCP ».

Quelques petits détails techniques pour finir : on peut parfaitement installer un serveur DNS résolveur sur sa propre machine (enfin, sur un ordinateur portable, pas sur un smartphone). La résolution DNS sera alors entièrement sous le contrôle d'un logiciel qu'on gère, fournissant ainsi le maximum de sécurité. Le processus n'est pas très compliqué sur Unix, ni même sur Windows (merci à Gils Gayraud et Mathieu Bouchonnet pour leur aide sur Windows). On peut le rendre encore plus simple avec des logiciels astucieux comme dnssec-trigger, qui ne teste pas la censure (son but est tout autre) mais pourrait servir de point de départ à un paquetage simple d'installation, vraiment utilisable par M. Toutlemonde (ce n'est pas encore le cas). Par contre, un tel résolveur local a des conséquences négatives sur l'infrastructure du DNS : comme il n'y a plus de cache partagé (avec le résolveur/cache du FAI, une requête pour www.bortzmeyer.org reste en mémoire et bénéficie à tous les clients du FAI), les serveurs faisant autorité verront leur charge s'accroître.

Pour éviter cet inconvénient, une des solutions serait pour le résolveur local de faire suivre les requêtes aux résolveurs du FAI (de tels résolveurs sont nommés forwarders). Mais cela implique de détecter lorsque le résolveur du FAI ment, pour le court-circuiter dans ce cas. DNSSEC fournit une piste intéressante pour cela mais, début 2012, les résolveurs ayant cette fonction forwarder (BIND et Unbound) n'ont pas de tel service de détection et de contournement.

Pire encore, on peut combiner le résolveur local (ou le remplacer) avec des fichiers statiques locaux (/etc/hosts sur Unix, C:\WINDOWS\system32\drivers\etc\hosts sur Windows) mais la maintenance de tels fichiers serait un cauchemar.

Cela ne veut pas dire que cela n'arrivera pas : dans ce maelstrom d'attaques et de contre-attaques, les solutions les plus mauvaises seront certainement déployées par certains acteurs et le futur est sombre pour le système de résolution de noms.

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)

Source.: