Mon blog

Avant de lire cet intéressant article, merci de prendre connaissance d'un avertissement préalable : dès qu'il s'agit de la Chine, il faut bien admettre qu'on ne sait pas grand'chose. La plupart des gens qui pontifient sur la situation de l'Internet en Chine ne parlent pas chinois et ne connaissent du pays que les hôtels internationaux de Pékin et Shanghai. (Le prix de l'énormité pro-chinoise revient au député UMP pro-LOPPSI Jacques Myard pour son soutien à la dictature.) Quand il s'agit du DNS, un des services les moins compris d'Internet, le taux de production de conneries augmente considérablement et la combinaison des deux fait donc que la plupart des phrases où il y a « DNS » et « Chine » sont fausses...

Je vais donc essayer de ne pas faire comme Myard, de ne parler que de ce que je connais, ce qui va donc rendre cet article assez court et plein de conditionnels. Contrairement aux films policiers états-uniens, à la fin de cet article, vous ne connaitrez pas le nom du coupable, vous ne saurez même pas s'il y a eu crime...

À plusieurs reprises (par exemple lors de la réunion IETF à Paris en 2005) a été discutée la question d'un détournement du trafic des serveurs DNS de la racine en Chine, afin de mettre en œuvre les politiques, notamment de censure, de la dictature chinoise. Il est très difficile de savoir exactement ce qui se passe en Chine car les utilisateurs chinois, pour des raisons culturelles mais, surtout, par peur de la répression, ne diffusent guère d'informations. Bien sûr, des tas de gens voyagent en Chine mais ils ne sont pas forcément experts du DNS et il est difficile d'obtenir d'eux des résultats de mtr ou des dig exécutés correctement et avec les bonnes options. Les rapports existants sur la censure de l'Internet en Chine sont souvent pauvres en détails techniques.

Toutefois, de temps en temps, le détournement a des conséquences visibles à l'extérieur. C'est ainsi que, le 24 mars, le responsable technique de .cl note que le serveur racine I, anycasté et géré par Netnod, répond bizarrement depuis le Chili :

$ dig @i.root-servers.net www.facebook.com A

; <<>> DiG 9.6.1-P3 <<>> @i.root-servers.net www.facebook.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7448
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.facebook.com.              IN      A

;; ANSWER SECTION:
www.facebook.com.       86400   IN      A       8.7.198.45

;; Query time: 444 msec
;; SERVER: 192.36.148.17#53(192.36.148.17)
;; WHEN: Wed Mar 24 14:21:54 2010
;; MSG SIZE  rcvd: 66

Les serveurs racine ne font pas autorité pour facebook.com. Il aurait donc du renvoyer une réference aux serveurs de .com. Au lieu de cela, on trouve une adresse IP inconnue. Bref, quelqu'un détourne le trafic du serveur. En effet :

• Aussi bien les gérants du serveur I que ceux qui l'hébergent nient toute modification des données reçues de Verisign (qui gère le serveur maître de la racine).
• Les autres serveurs de la racine (sauf, curieusement, D) sont également affectés.
• Le seul trafic détourné est celui en UDP, TCP n'a pas de problèmes. Les traceroutes vont parfois vers des instances fiables du serveur I, par exemple au Japon, ce qui semble indiquer que la manipulation ne concerne que le port 53 celui du DNS.
• Les noms affectés sont ceux de service censurés en Chine, comme Facebook ou Twitter (pas uniquement pour des raisons politiques, mais également parce que ces services ont des concurrents chinois).

À noter que le pirate ne se cache même pas. Si on utilise la requête CH TXT hostname.bind (on demande au serveur son nom), au lieu du vrai nom (par exemple s1.sth), on obtient le nom du pirate (par exemple c1-zaojunmiao-ns1) ce qui montre bien que le vrai serveur racine I est innocent. Si vous voulez tester vous-même, le réseau 123.112.0.0/12, hébergé par China Unicom, est un exemple curieux (à noter qu'il ne répond que pour les noms censurés) :

% dig A www.facebook.com @123.123.123.123 

; <<>> DiG 9.5.1-P3 <<>> A www.facebook.com @123.123.123.123
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44684
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.facebook.com.              IN      A

;; ANSWER SECTION:
www.facebook.com.       86400   IN      A       37.61.54.158

;; Query time: 359 msec
;; SERVER: 123.123.123.123#53(123.123.123.123)
;; WHEN: Fri Mar 26 10:46:52 2010
;; MSG SIZE  rcvd: 66

(L'adresse 37.61.54.158 n'est pas actuellement affectée et n'est pas une adresse de Facebook.)

Une autre solution pour tester est de trouver un résolveur DNS ouvert en Chine (c'est la méthode suivie par l'article de Lowe, Winters et Marcus cité plus loin). Quelques essais/erreurs et on trouve que ns.bnu.edu.cn veut bien répondre (attention, il est très lent) :

% dig +short @ns.bnu.edu.cn www.bortzmeyer.org
208.75.84.80

La réponse est correcte. Et avec un nom censuré ?

% dig +short @ns.bnu.edu.cn www.twitter.com   
37.61.54.158

Réponse mensongère (37.0.0.0/8 n'est même pas alloué).

Enfin, si vous êtes situé en Chine, c'est encore plus simple (ici dans le Liaoning) :

% dig A www.facebook.com.
...
;; ANSWER SECTION:
www.facebook.com.       86400   IN      A       46.82.174.68

Cette adresse n'est pas officiellement allouée. Encore plus drôle, une adresse IPv4 multicast :

% dig A www.twitter.com
...
;; ANSWER SECTION:
www.twitter.com.        86400   IN      A       243.185.187.39

À noter que les résultats ne seront pas forcément les mêmes selon que le nom de domaine est un IDN ou pas. La censure ne trafique pas que le routage !

Il est donc très probable qu'il existe en Chine des copies pirates des serveurs racine, et que les FAI chinois ont bricolé leur IGP (OSPF ou autre) pour détourner le trafic à destination des serveurs racine (variante de l'explication : des équipements intermédiaires, par exemple des routeurs, réécrivent les paquets). Cela n'explique quand même pas tout (par exemple pourquoi les copies fiables installées en Chine voient quand même un trafic DNS non négligeable) mais, sans tests détaillés faits un peu partout en Chine, difficile d'en dire plus.

À propos de tests détaillés, si vous êtes en Chine, et que vous avez une machine Unix, j'apprécierai que vous fassiez tourner le programme dns-china.sh et que vous me renvoyiez le résutat. Comme il produit beaucoup de données (et prend du temps), une façon de le faire tourner est sh dns-china.sh 2>&1 > /tmp/dns-china.log et vous pouvez ensuite m'envoyer le fichier /tmp/dns-china.log. Précisez bien si vous voulez que je cite votre nom, je remercie normalement tout le monde mais, ici, pour des raisons évidentes, je ne citerai que les gens qui le demandent. Un exemple de résultat (depuis un hôtel pékinois) est disponible.

Merci aux premiers et anonymes (pour vous, pas pour moi) testeurs, qui ont permis de voir que la Chine, c'est grand, et qu'on n'observe pas le même résultat selon les régions et/ou les opérateurs (par exemple, un test depuis Shanghai montre d'autres résultats, où les réponses des serveurs racine ne sont pas réécrites).

Bref, une fois qu'il est établi qu'il y a réécriture de certaines réponses DNS en Chine, revenons au Chili. Pourquoi ont-ils vu le problème ? Une fuite de ce bricolage de routes (analogue à celle qui avait touché YouTube) explique sans doute que l'annonce du serveur pirate ait atteint l'autre bout du Pacifique...

On pourrait penser qu'il suffit aux internautes chinois de créer un VPN avec un réseau à l'étranger, avec service DNS, pour échapper à cette censure mais la dictature est efficace : elle ne compte pas sur une seule méthode technique, elle en utilise plusieurs (filtrage IP, interception HTTP, DPI, etc).

Parmi les sources d'information fiables sur les manipulations DNS en Chine, l'excellent article technique de Graham Lowe, Patrick Winters et Michael L. Marcus « The Great DNS Wall of China » (bonne méthodologie et étude sérieuse) ou le « Report about national DNS spoofing in China ». Des bizarreries dues au filtrage chinois avaient déjà été signalées. Le NIC chilien a documenté ses observations en espagnol et en anglais. Les réécritures faites en Chine par la censure peuvent avoir des conséquences techniques complexes, et parfois défavorables au censeur (voir l'analyse touffue de David Dagon, le chercheur en sécurité bien connu). Et quelques articles en anglais sont parus sur le récent problème décrit ici : « China censorship leaks outside Great Firewall via root server » (plutôt technique et de bonne qualité), « Accidentally Importing Censorship » (bonne analyse technique avec notamment une analyse de la probabilité de voir la censure depuis l'extérieur), « China's Great Firewall spreads overseas » ou « Web traffic redirected to China in mystery mix-up ». Si vous voulez un logiciel qui peut détecter certaines réécritures faites en Chine, il y a ScholarZhang (ne me demandez pas de traduire le README !) Une version autonome a été publiée.

D'autre part, Jean-Marc Liotier a fait une très bonne traduction en anglais de cet article, pour ceux qui sont plus à l'aise avec la langue de Jasper Fforde.

Merci à Hauke Lampe et Marco Davids pour leur aide technique et bien sûr à Mauricio Vergara Ereche pour ses excellentes observations depuis Santiago.