Retour à la liste

Etude et plan d'actions suite à l'incident de résolution validante du 12 février 2011 - point d'étape

mercredi 23 mars 2011 00:00:00

Bonjour, comme indiqué dans notre précédent communiqué sur l'incident DNSsec du 12 février 2011, nous devions cette semaine prendre un certain nombre de décisions concernant le plan d'action suite à l'incident. Vous trouverez dans ce billet une synthèse de l'avancée de nos travaux et décisions.

Faits nouveaux En l'état aujourd'hui, plusieurs faits nouveaux sont à prendre en compte. Le bug BIND à l'origine du premier incident du 12/02/2011 a fait l'objet d'un patch qui a été déployé après les phases de test nécessaires. Il est à noter que ce patch n'est à ce jour inclus dans aucune des distributions standard de BIND et qu'il convient donc de l'appliquer à la main pour pouvoir l'utiliser de façon opérationnelle ce qui nous éloigne des standards de production habituels. Un nouvel incident de signature, impactant uniquement l'enregistrement SOA cette fois, a eu lieu le 13 mars 2011. Sans rentrer dans les détails chronologiques du déroulé de l'incident on peut résumer l'événement de la façon suivante : Phase 1 : Suite aux changements d'états de clés du .fr survenus quelques heures plus tôt, BIND termine ses opérations de signatures et de traitements internes et modifie l'enregistrement de type privé permettant d'indiquer l'état du processus de signature. Ces modifications impliquent de resigner des enregistrements, dont le SOA. Une perte de connexion avec les HSM empêche Bind d'accéder aux clés, mais il lance malgré tout une signature bien que les clés soient déclarées inutilisables. Le résultat est une zone où manque la signature du SOA mais BIND publie tout de même la zone pour laquelle il manque manifestement une signature. Phase 2 : Recevant la zone incorrecte, les esclaves BIND (tous les serveurs du .fr sauf deux) ont servi une zone dont seul le SOA n'était pas signé. Par contre, les deux esclaves NSD (a et c.nic.fr) ont considéré que la zone n'était plus signée et se sont mis à ne plus envoyer de signatures du tout. Impacts : Cela n'aurait eu que peu de conséquences pratiques sauf pour les gens qui demandaient explicitement le SOA dans le cas des serveurs tournant avec BIND. Par contre l'absence de signature sur les DNSKEY est considérée par les résolveurs validants comme une erreur fatale et tous les résolveurs ayant la malchance de demander à a.nic.fr ou c.nic.fr affichaient une erreur (SERVFAIL  pour le client). C'est ce problème qui a eu des conséquences externes visibles. Traitement côté logiciels : Cette nouvelle bogue BIND a été signalée à l'ISC lundi 14 à 02:00 (ticket [ISC-Bugs #23642]) et reconnue presque tout de suite comme une bogue de "timing" (si le processus de signature se déclenche à certains moments, il corrompt la zone). Elle n'est pas reproductible à volonté mais l'ISC a produit un patch (patch 3075). La bogue NSD, quant à elle, a été reproduite en laboratoire puis signalée aux NLnetlabs le lundi à 04:00 (#369 ) et reconnue. Il n'existe pas encore de patch sur cette bogue à ce jour. Décisions et actions Nous avons décidé au vu de ces événements et malgré le risque sur le niveau de service de résolution validante de maintenir notre DS dans la racine afin d'afficher notre confiance dans le travail qui est effectué par l'AFNIC, par ses partenaires et collègues à l'international pour renforcer les différents éléments structurants de l'univers DNSsec. Nous sommes conscients que les incidents survenus pourraient avoir été induits par l'architecture AFNIC complexe qui sollicite les briques logicielles à leur limite. A côté des efforts conjoints pour corriger les défauts qui peuvent survenir dans les différents composants en cours de test et/ou de production, notre travail se porte sur une amélioration de la couverture de ce risque en cherchant à en limiter au maximum l’impact. Un travail collaboratif avec la communauté technique impliquée dans le développement et l’exploitation de DNSsec est entrepris pour concevoir, développer et livrer des nouveaux éléments standards utilisables par tous dans la chaine de publication. Le coeur de ce travail sera la livraison d'un proxy intermédiaire avant publication dont la tâche sera d'analyser entièrement une zone avant diffusion sur les serveurs esclaves. Ce travail a déjà commencé en interne et dans le cadre d'un groupe de travail monté avec le RIPE NCC, l'ICANN, ainsi que plusieurs TLDs interessés par cet outil. Ce composant, à défaut de prémunir d'une bogue, devrait permettre d'éviter la diffusion d'une zone non intègre d'un point de vue signature sur le réseau. Une version AFNIC de ce proxy sera déployée d'ici le 5 avril. Cela constituera le premier maillon de validation qui devrait garantir un retour au niveau de service de résolution attendu par la communauté. Enfin l’une des  conséquences de ces travaux est le possible report de l'ouverture en production du service d'insertion des DS dans la zone .fr. Ce service est à ce jour prêt et livré sur notre Banc de Test depuis le mardi 22 mars. Il est donc disponible à l’essai pour nos clients. -- Philippe Renaut Directeur technique
Haut de page

A propos de l'AFNIC

Créée en 1997, l’Afnic - Association Française pour le Nommage Internet en Coopération - est une association à but non lucratif. Désignée par l'État pour gérer les noms de domaine en .fr, elle en assure la promotion auprès des entrepreneurs et des particuliers. Gestionnaire historique du .fr avec plus de 3,2 millions de noms de domaine à ce jour, elle se positionne également comme fournisseur de solutions techniques et de services de registre : elle accompagne ainsi 14 projets de nouveaux domaines Internet de premier niveau dont le .paris et le .bzh. L’Afnic est implantée à Saint-Quentin en Yvelines : 80 personnes travaillent ainsi à ce bien commun qu’est l’Internet français. L’Afnic reverse 90% des bénéfices du .fr à la Fondation Afnic pour la solidarité numérique, qui finance des projets internet solidaire sur l’ensemble du territoire français. www.afnic.fr.