Mon blog

Le 16 novembre, deux pannes successives ont affecté les résolveurs DNS d'Orange. Que s'est-il passé exactement, et quelles conséquences peut-on en tirer ?

Commençons par les observations. Au moins, il s'agira de faits. Les deux pannes sont survenues approximativement entre 0840 UTC (soit quasiment en même temps que la plénière de l'IETF dont le thème était... « Attacks Against the Architecture » !) et 1030 pour la première, et entre 1315 et 1410 (toujours UTC) pour la seconde. N'ayant pas de compte chez Orange, j'ai utilisé deux sources d'informations, les rézosocios, où d'innombrables messages ont signalé la panne, et les sondes RIPE Atlas. Pour ces dernières, j'ai demandé des sondes se trouvant dans l'AS 3215, celui d'Orange (notez qu'il abrite des services très différents, ne dépendant pas forcément des mêmes résolveurs DNS). À ma connaissance, Orange n'a rigoureusement rien communiqué, ni pendant la panne (malgré les innombrables cris lancés par ses clients sur les rézosocios), ni après, donc je ne peux me fier qu'à ces observations. Les messages des utilisateurs d'Orange étaient pour la plupart trop vagues (« rien ne marche »), ne citant même pas un nom de domaine qu'on puisse ensuite tester. Personne hélas pour procéder à une récolte sérieuse de données, par exemple avec dig. Ces messages des utilisateurs ne peuvent donc servir qu'à signaler et confirmer qu'il y avait un gros problème. Mais les sondes Atlas nous en disent davantage.

Que nous montrent-elles ? Je prends par exemple le domaine de l'Université Stanford. Si je veux vérifier qu'il est bien visible, je demande à cent sondes RIPE Atlas de résoudre ce nom en adresse IP :

% atlas-resolve --requested 100 online.stanford.edu
[] : 1 occurrences 
[171.67.216.22] : 33 occurrences 
[171.67.216.23] : 28 occurrences 
[171.67.216.21] : 37 occurrences 
Test #6935163 done at 2016-11-17T04:56:58Z

C'était le lendemain de la panne, et tout marche bien (une seule sonde n'a pas eu de réponse, et cela peut être de la faute de son réseau d'accès). Mais pendant la panne ? On voyait, en se limitant à l'AS 3215, des choses comme :

% atlas-resolve --requested 100 --as 3215 online.stanford.edu
[TIMEOUT(S)] : 13 occurrences 
[ERROR: SERVFAIL] : 65 occurrences 
[171.67.216.22] : 8 occurrences 
[171.67.216.23] : 7 occurrences 
[171.67.216.21] : 7 occurrences 
Test #6934676 done at 2016-11-16T08:53:51Z

Regardons de plus près. La majorité des sondes RIPE Atlas situées dans l'AS d'Orange n'a pu résoudre le nom, et a au contraire obtenu un code SERVFAIL (SERVer FAILure), indiquant que le résolveur (je reviens sur ce terme plus loin) utilisé n'a pu joindre aucun des serveurs faisant autorité pour le domaine stanford.edu. Pas mal de sondes n'ont simplement pas eu de réponses de leur résolveur à temps.

Mais cette unique observation ne nous permet pas de dire que le problème venait d'Orange. Il est parfaitement possible que ce soit Stanford qui ait des ennuis, panne ou dDoS. Il faut donc, comme toujours lorsqu'on fait des observations scientifiques, comparer avec des mesures faites dans d'autres circonstances. Ici, on va simplement demander aux sondes situées dans un pays voisin, l'Allemagne :

    
% atlas-resolve --requested 100 --country DE online.stanford.edu 
[] : 1 occurrences 
[171.67.216.22] : 33 occurrences 
[171.67.216.23] : 31 occurrences 
[171.67.216.21] : 35 occurrences 
Test #6934677 done at 2016-11-16T08:54:06Z

Au pays de Konrad Zuse, toutes les sondes ou presque ont une réponse. Cela laisse entendre que tout va bien à Stanford et que le problème ne vient pas de l'université californienne. (J'aurais aussi pu tester avec un autre AS français, celui de SFR ou de Free.)

Autre façon de voir que le problème était bien chez Orange et pas du côté des domaines testés, essayer avec d'autres domaines :

%  atlas-resolve --requested 100 --as 3215 kotaku.com
[ERROR: SERVFAIL] : 47 occurrences 
[151.101.1.34 151.101.129.34 151.101.193.34 151.101.65.34] : 50 occurrences 
Test #6934730 done at 2016-11-16T10:10:01Z

% atlas-resolve --requested 100 --as 3215 spotify.com
[194.132.197.147 194.132.198.165 194.132.198.228] : 76 occurrences 
[ERROR: SERVFAIL] : 19 occurrences 
[TIMEOUT(S)] : 4 occurrences 
Test #6934675 done at 2016-11-16T08:52:10Z
    

Tous ces domaines marchaient parfaitement depuis d'autres AS ou d'autres pays.

Donc, problème de résolution DNS chez Orange. Comme l'ont vite découvert bien des utilisateurs, changer de résolveur DNS suffisait à résoudre le problème (ce qu'on pouvait également tester avec ce programme atlas-resolve et l'option --nameserver).

Notons bien, qu'il s'agissait des résolveurs DNS, pas des serveurs faisant autorité, comme cela avait été le cas récemment lors de l'attaque contre Dyn. La distinction est cruciale car ces deux types de serveurs DNS n'ont pas grand'chose en commun. Si vous lisez un article qui parle de « serveur DNS » tout court, sans préciser s'il s'agit d'un résolveur ou bien d'un serveur faissant autorité, méfiez-vous, c'est souvent un signe d'ignorance, ou de négligence, de la part de l'auteur de l'article.

Maintenant, les remarques. D'abord, beaucoup de gens (par exemple dans cet article de Numerama, mais aussi dans d'innombrables tweets) ont suggéré de passer des résolveurs DNS d'Orange (ceux utilisés par défaut par les abonnés à ce FAI) à ceux de Google Public DNS ou bien à ceux de Cisco OpenDNS. La plupart des sociétés à but lucratif doivent payer des commerciaux et des chargés de relation publique pour faire leur publicité, mais Google n'en a pas besoin, ayant des millions de vendeurs bénévoles et enthousiastes parmi ses utilisateurs. Mais ceux qui écoutent ces conseils et passent à Google Public DNS lui donneront les données personelles qui permettent leur propre surveillance (cf. le RFC 7626 sur le caractère sensible des requêtes DNS). Je ne développe pas davantage ce point ici, Shaft l'a fait mieux que moi. J'observe que, si ce genre de pannes continue, les utilisateurs français dépendront presque tous, pour une activité critique, d'un résolveur états-unien d'une entreprise privée. Cela devrait logiquement agiter ceux qui nous parlent tout le temps de souveraineté numérique, mais, en général, ces gens ne sont pas intéressés par les problèmes concrets et opérationnels.

Mais alors quelle serait la bonne solution ? Le mieux évidemment est d'utiliser des résolveurs proches, donc a priori dans le cas idéal, ceux de son FAI. Ceux-ci ne devraient pas tomber en panne, le DNS étant absolument indispensable à tout usage de l'Internet. Mais lorsque des pannes aussi longues surviennent, il est normal d'envisager d'autres solutions, et la bonne est certainement d'avoir un résolveur sur son réseau local (pas forcément sur chaque machine), ce qui est facile avec des équipements comme le Turris Omnia.

Notez qu'une minorité des sondes RIPE Atlas sont déjà sur un réseau local qui utilise un tel résolveur. Cela explique en partie pourquoi, dans les tests ci-dessus, un certain nombre de sondes arrivaient à résoudre les noms de domaine, même au plus fort de la panne. (Cela n'explique qu'une partie du phénomène. Il semble que certains noms avaient un taux de réussites plus fort que d'autres, ce qui ne peut pas s'expliquer par le choix du résolveur.) Notez qu'on peut avoir l'adresse IP du résolveur utilisé par la sonde (avec l'option --displayresolvers) mais que cela ne renseigne pas tellement. D'abord, c'est souvent une adresse IP privée (RFC 1918), ensuite, le premier résolveur vu par la sonde fait fréquemment suivre à un résolveur plus gros, qu'on ne voit pas, et qui peut être ou ne pas être un résolveur « officiel » du FAI. Je vous montre quand même le résultat pour l'une des mesures faites ci-dessus (notez la bogue pour le cas du timeout, où le résolveur n'est pas connu) :

% atlas-resolve -r 100 --as 3215 --displayresolvers --measurement 6934670  kotaku.com    
[ERROR: SERVFAIL] : 27 occurrences (resolvers ['172.31.255.254', '192.168.1.1', '80.10.246.2', '192.168.2.1', '192.168.254.254', '192.168.3.1'])
[151.101.1.34 151.101.129.34 151.101.193.34 151.101.65.34] : 69 occurrences (resolvers ['2a01:cb08:898c:fc00::1', '172.16.3.1', '192.168.1.1', '10.10.11.4', '10.63.0.252', '10.112.0.1', '8.8.8.8', '192.168.119.1', '192.168.1.9', '192.168.0.1', '10.0.0.34', '80.10.246.136', '192.168.248.153', '192.168.4.10', '192.168.1.40', '192.168.221.254', '149.202.242.66', '192.168.255.254', '192.168.28.1', '192.168.2.1', '10.0.0.1', '192.168.0.31', '194.2.0.20', '192.168.10.10'])
[TIMEOUT(S)] : 4 occurrences (resolvers <__main__.Set instance at 0x7fedc8194f80>)
Test #6934670 done at 2016-11-16T08:44:41Z

Deuxième sujet de réflexions sur cette panne, que s'est-il passé ? En l'absence de toute communication de la part d'Orange, on ne peut guère que spéculer. Notons tout de suite qu'il ne s'agissait pas cette fois d'un détournement (comme lorsque Orange avait redirigé Google et Wikipédia vers le Ministère de l'Intérieur) mais d'une absence de réponse. Cette absence dépendait des domaines. Je n'ai pas eu immédiatement de signalement d'un problème pour un domaine hébergé en France, seulement pour des domaines états-uniens (c'est après, donc trop tard pour les mesures, que j'ai appris que des domaines hébergés en France étaient également touchés). Comme le code de retour SERVFAIL indique que le résolveur n'a pas réussi à parler aux serveurs faisant autorité, on peut donc supposer que les liens menant à ces réseaux outre-Atlantique étaient inutilisables. Suite à une erreur de configuration, par exemple dans des ACL ? À un problème de routage vers certaines destinations ? À une attaque par déni de service ? Je ne le sais pas. Mais je me demande bien quelle était la panne ou l'attaque qui pouvait bloquer les résolveurs, tout en laissant passer toutes les autres machines (puisque, une fois qu'on avait un résolveur normal, le trafic n'était pas affecté).