Retour à la liste

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

vendredi 18 février 2011 00:00:00

Le samedi 12 février 2011, un incident lié à la signature de la zone .fr s’est produit et a eu des échos auprès de la plupart des professionnels et utilisateurs impliqués actuellement dans le déploiement de DNSsec. Afin de faire bénéficier de cette expérience la communauté la plus large nous avons choisi de faire le récit et l'analyse la plus détaillée possible pour servir de bases à d'éventuels échanges sur le sujet.

1. Chronologie de l'incident - 14h - La zone .fr devient inaccessible à tout résolveur validant hors des heures ouvrées. Le problème portant sur un type d'enregistrement (NSEC3) non encore surveillé, notre dispositif d’alerte n’a pas pu nous signaler l’incident. - 15h04 - Nous avons été alertés par des tiers sur les canaux de communication interpersonnelle (twitter, coup de téléphones...) et commençons les diagnostics - 15h30 - Nous avons publié sur notre situation et l’état de notre analyse à plusieurs reprises sur twitter (@afnic_op) et le blog des opérations de l'afnic (http://operations.nic.fr). - 16h30 - Le diagnostic, long à établir (cf. ci-dessous), est partiellement effectué, en tous cas suffisamment pour qu'une action soit entreprise avec succès pour résoudre le problème. - 17h50 - La zone redevient accessible normalement à tout résolveur validant. Nous avons communiqué sur la reprise et avons échangé avec divers observateurs pour affiner le diagnostic et recueillir le maximum d'information sur ce qui a été observé et consigné depuis l’extérieur. 2. Analyse et diagnostic Rappelons tout d'abord quelques éléments de l'architecture de publication de l'AFNIC. L'AFNIC a un système de rafraichissement horaire de la zone .fr basé sur du Dynamic Update conformément à la RFC 2136. Afin d'intégrer le mécanisme de signature DNSsec de façon compatible avec cette technologie, il a été décidé d'utiliser les fonctionnalités correspondantes de Bind. Pour disposer d’un mécanisme de gestion des clés et des repositories exploitable en interne, nous avons choisi le logiciel  OpenDnsssec et déployé  un mécanisme de synchronisation avec Bind. Enfin des boîtiers HSM (Hardware Security Module) sont mis en œuvre pour le stockage des clés et la signature. Cette architecture particulière nous conduit à faire appel à des fonctionnalités de Bind assez avancées et probablement peu utilisées dans la plupart des dispositifs de signature en exploitation. Nous sommes de fait confrontés à des incidents qui font que nous sommes les premiers à effectuer des retours de bugs sur ces fonctions.  A l'heure de l’incident de signature, soit 14h, une clé (la ZSK 43893 qui ne signait plus depuis très longtemps et devait donc pouvoir être retirée sans risque) a été retirée : c’est vraisemblablement l'événement déclencheur. En effet, au moment de la suppression d'une clé déjà inactive, Bind effectue un traitement de recalcul de l'arbre NSEC3 étonnamment long. Pendant ce recalcul un bug de signature apparait que nous allons détailler ci-dessous. C’est la version 9.7.1-P2 de BIND que nous utilisons en production pour signer dynamiquement la zone à publier. En cas de signature dynamique (ce qui arrive pour les mises à jour dynamiques, mais _pas_ uniquement) BIND produit des enregistrements d'un type privé à l'apex (TYPE65534, voir la documentation de BIND, doc/arm/Bv9ARM.ch04.html, section « Private-type records ») qui nécessitent de mettre à jour les enregistrements de type NSEC3. C'est à ce niveau que Bind se comporte de façon erratique. Ci-dessous un exemple issu de la zone .fr du jour de la panne.   rr:  meqimi6fje5ni47pjahv5qigu1lv3jlj.fr.     5400    IN      NSEC3    1 1 1 BADFE11A O5SMCS6CUNUQC5RFJ6S94TGGRFH1TVC7 NS SOA TXT NAPTR    RRSIG DNSKEY NSEC3PARAM TYPE65534   sig: meqimi6fje5ni47pjahv5qigu1lv3jlj.fr.     5400    IN      RRSIG    NSEC3 8 2 5400 20110408081500 20110207081500 2331    fr   OFDRwZAgzDT1y8fTJ1XCfHlajEAHzqk2dsJaCR1TSednnBSEkctIUP6AsZuD+EOZtEPCM2Oe3cI/fG2GfA1nAUDaS1INN3I6YRpB3n2/oCfKBvs68fvCexBOIgz+oc74VrPvjDtPkVyGbJ5ImSlwu8Uc8rTXKh47CdS0AdJLmso= La signature ci-dessus ne correspond pas à l’enregistrement NSEC3 mais à ce dernier privé du « TYPE65534 ». BIND a ajouté un type au NSEC3, sans changer la signature, qui devient invalide. Une bogue assez proche de celle constatée à l’incident a été reproduite en laboratoire mais dans un environnement différent de celui de production Afnic. Elle affecte tous les BIND livrés, même le récent 9.7.3. Elle a été signalée à l'ISC [ISC-Bugs #23232], reconnue et corrigée dans le code source par le patch 3020. La correction n’est pas encore disponible dans une version de BIND officiellement livrée). Une autre bogue, nettement plus proche de la panne, a été reproduite en laboratoire en reproduisant les conditions de production de l’Afnic. D’après notre analyse, la correction de cette bogue permettrait de corriger de façon directe les problèmes que nous avons rencontrés sous la zone .fr. Afin d'être le plus détaillé et précis possible, nous préférons encore pousser notre expérimentation avant de délivrer un rapport de bogue à l'ISC . En effet, cette bogue n'a pas encore testée avec d'autres versions que la 9.7.1 et nous ne savons pas si elle est, par exemple, corrigée par une version plus récente. D’autre part, cette bogue aurait la propriété de ne plus affecter les opérations après un délai qui semble dépendre de la taille de la zone. Parallèlement au travail de correction de cette bogue, nous identifions et analysons plus dans le détail les événements qui se produisent au moment de la rotation et de la suppression des anciennes clés. Ce sont ces phases de rotation qui semblent déclencher notre incident de signature par l’effet croisé de ce bug Bind et du caractère spécifique de notre architecture de signature. 3. Plan d'action Devant cette situation préoccupante, nous avons sérieusement étudié la possibilité de retirer la DS de .fr de la racine afin d'éviter tout problème de résolution validante. Au vu de l'analyse effectuée, il nous semble que cette bogue n’apparaît qu’au moment du retrait de clés lors des rotations. C’est pourquoi nous avons décidé d’appliquer la stratégie suivante à deux phases : Phase 1 17 - 21 février : approfondissement du bug Bind et ouverture d'un ticket à l'ISC 21 février - 10 mars : mise en œuvre d'un mécanisme de surveillance supplémentaire par résolution validante complète avant transfert de la zone sur les serveurs esclaves. x mars : livraison et déploiement d'un patch au bug identifié et mise à jour global des BINDs. Phase 2 Si les actions planifiées en phase 1 s’avéraient insuffisantes, ce qui ne dépendra pas que de nous, ou devaient se prolonger au-delà du 21 mars ou si un autre incident en production sur le .fr affectait la résolution validante, l'AFNIC pourrait demander le retrait de la DS de la racine jusqu'à stabilisation des couches logicielles utilisées et revalidation de l'architecture de signature. Ces actions pourraient avoir un impact sur le plan d'action opérationnel de l’AFNIC, qui prévoit à ce jour une ouverture de la délégation dnssec au 5 avril 2010. Le cas échéant, nous communiquerons ultérieurement sur ce point. 4. Conclusion DNSsec reste une technologie complexe pour laquelle toutes les couches logicielles utilisées n'ont pas encore été testées en production dans toutes les configurations. Il est donc compréhensible que certaines bogues puissent être encore rencontrées. La réactivité de l'ISC notamment et le partage d'expérience entre registres nous laissent malgré tout confiants sur le fait que cette période de stabilisation sera la plus courte possible et ne n’obérera pas les possibilités de mise en production de DNSsec à grande échelle. Nous sommes intéressés à développer le partage d'expérience avec tous les registres ayant une architecture proche de la nôtre, notamment Bind avec Dynamic update. Nous rappelons aux exploitants de résolveurs validant  la relative jeunesse de l’exploitation de DNSSEC et les invitons à rester vigilants et à ne pas hésiter à collaborer avec nous en mode préventif ou correctif sur la mise en œuvre de la technologie DNSSEC. L’adresse à utiliser pour approfondir les échanges sur ce point est celle de notre responsable DNSSEC : Vincent Levigneron : vincent.levigneron@afnic.fr Philippe Renaut Directeur Technique    
Haut de page

A propos de l'AFNIC

L’Afnic (Association française pour le nommage Internet en coopération) est une association française à but non lucratif. Depuis 20 ans, nous sommes l'office d'enregistrement pour la gestion des adresses internet sous l’extension .fr. Nous gérons également les extensions ultramarines .re (Ile de la Réunion), .pm (Saint-Pierre et Miquelon), .tf (Terres australes et antarctiques françaises), .wf (Wallis et Futuna), .yt (Mayotte). Ce qui représente plus de 3,2 millions de noms de domaine et sommes l’opérateur technique de 14 entreprises et collectivités ayant choisi d’avoir leur propre extension dont .paris, .bzh, .alsace, .corsica, .mma, .ovh, .leclerc ou encore .sncf. Nous sommes engagés à accompagner la transformation numérique des TPE/PME grâce à notre dispositif Réussir en .fr (www.reussir-en.fr) et proposons une offre gratuite d’accompagnement à la présence en ligne allant des outils de diagnostic aux formations sur le terrain dans toute la France. En tant qu’association, nous fédérons une communauté de plus d’une centaine de membres aux profils variés mais tous acteurs du web : bureaux d’enregistrement, entreprises, fédérations, utilisateurs, institutionnels, etc. Notre rôle s’inscrit dans une mission d’intérêt général plus large, qui consiste à contribuer au quotidien à un internet sûr et stable, ouvert aux innovations où la communauté internet française joue un rôle de premier plan. Par ailleurs, nous reversons 90% des bénéfices de la gestion du .fr à notre Fondation Afnic pour la solidarité numérique (www.fondation-afnic.fr) qui finance chaque année une trentaine de projets visant à réduire la fracture numérique sur tout le territoire français.