Résumé

  • À la plénière RIPE 92, Robert Kisteleki a expliqué être le contact administratif ou technique de plusieurs domaines, dont certains appartiennent à d’autres. Il a cité aussi l’hébergement de courriels, les machines virtuelles, le DNS secondaire, les renouvellements et l’accès aux comptes.
  • Il a appelé des volontaires à préparer d’éventuelles recommandations RIPE sur la continuité de ces services, avec des droits de remplacement et de révocation. La fiche officielle de son intervention présente le document comme une idée à travailler.

La générosité a parfois une date d’expiration. Un ingénieur accepte de garder le domaine d’un ami, d’héberger son courrier ou de faire tourner un DNS secondaire. Les années passent. Les utilisateurs voient un service stable; celui qui reçoit la facture et sait rétablir le compte reste seul. Robert Kisteleki a mis ce décalage au centre de sa prise de parole, le 21 mai 2026 à Édimbourg.

Il a pris son propre cas. Pour certains noms de domaine, y compris des noms dont il n’est pas propriétaire, il figure comme contact administratif ou technique. Que deviennent les sites et les personnes qui en dépendent s’il est momentanément ou durablement indisponible? La question porte moins sur sa biographie que sur une répartition des commandes qu’on n’a jamais écrite. Le titulaire possède le nom; le bénévole connaît le registrar, les échéances et les procédures de récupération.

La transcription de RIPE 92 élargit l’inventaire: serveur de messagerie ou simple relais MX, machine virtuelle prêtée, matériel accueilli en centre de données, DNS secondaire, petit service social. Chaque ligne possède sa propre horloge. Un domaine non renouvelé peut changer de mains; ses adresses électroniques peuvent alors servir dans des demandes de récupération. Un serveur impayé peut disparaître. Un certificat arrive à terme. Un utilisateur perd son second facteur d’authentification et personne d’autre ne peut l’aider. Kisteleki énumérait des scénarios de panne, pas une série d’incidents mesurés.

Le réflexe de confier tous les mots de passe à plusieurs amis crée un autre danger. Kisteleki a rappelé qu’une personne autrefois digne de confiance peut cesser de l’être. Pour assurer la relève, il faut donc connaître le propriétaire du service, les personnes habilitées à intervenir, le déclencheur de leur intervention et le moyen de leur retirer cet accès. La continuité et la révocation forment un seul problème pratique.

Il n’a pas présenté une norme achevée. Il a demandé des volontaires pour réunir des cas, envisager une table des matières et peut-être rédiger un document RIPE ou une pratique courante. Jan Zorz a proposé la task force des Best Current Operational Practices comme point de départ. La présentation officielle parle bien d’une possibilité. Ce stade précoce rend l’appel plus utile: les exploitants peuvent encore mettre sur la table leurs oublis les plus ordinaires.

Une fiche minimale suffirait à changer la situation pour nombre de petits services. Quel nom expire quand? Quel compte paie l’hébergement? Qui peut modifier la zone DNS? À qui appartient le courrier et qui peut restaurer l’accès? Qui retire les droits du remplaçant après l’urgence? Ces réponses devraient être connues du bénéficiaire avant que l’opérateur habituel cesse de répondre.

La communauté aime dire qu’elle fonctionne parce que les gens s’entraident. Kisteleki a montré le revers de cette force: une aide laissée sans transmission devient une dépendance invisible. La première vraie preuve d’une relève sera une répétition faite avec les personnes concernées, pendant que le gardien du service peut encore corriger le plan.