Résumé

  • Soumis le 10 avril 2012 par Tim McGinnis, AFPUB-2012-DNS-001-DRAFT-01 proposait de conditionner toute nouvelle délégation DNS inverse à l’existence, dans la base AFRINIC, d’une affectation ou d’une sous-allocation correctement enregistrée.
  • Le Draft 1 visait une difficulté réelle : un registre d’adresses qui ne décrit pas l’usage en aval perd de sa valeur pour l’identification des responsables et pour la coordination technique. Mais une absence dans la base n’établit ni l’inutilisation d’un espace d’adresses, ni une faute, ni l’abandon d’un droit.
  • La section 3.3 protégeait expressément les délégations inverses approuvées avant une éventuelle ratification. Le texte ne proposait donc pas de supprimer les délégations existantes ; il agissait prospectivement sur les allocations ultérieures et les nouvelles demandes.
  • Le compte rendu d’AFRINIC-16, le 18 mai 2012, attribue à l’auteur des proportions supérieures à 60 % d’opérateurs ayant enregistré des affectations et proches de 40 % n’en ayant enregistré aucune. Sans dénominateur, date de requête, méthode ni audit, ces chiffres décrivent un argument de réunion, pas une mesure indépendante.
  • AFRINIC est ici un teneur de registre privé et un coordinateur technique. Il peut authentifier une demande, vérifier le fait précis dont dépend une délégation et corriger ses dossiers. Il n’est ni régulateur, ni police, ni organe de punition, ni juge, et un refus de DNS ne saurait être présenté comme une peine légitime.
  • La bonne architecture aurait associé à toute condition préalable une notification authentifiée, l’identification exacte de l’objet et de la zone concernés, une règle de preuve publiée, un délai de traitement, une voie de correction, un examen indépendant et un retour rapide au dernier état vérifié en cas d’erreur.

Une proposition étroite, un conflit institutionnel profond

À première vue, « No Reverse Unless Assigned » semble énoncer une règle de bon sens : pas de délégation inverse sans affectation enregistrée. Le nom promet une correspondance simple entre deux plans de données. D’un côté, la base du registre doit indiquer à qui une partie d’un bloc a été affectée ou sous-allouée. De l’autre, le DNS inverse doit publier, pour les adresses concernées, le chemin qui permettra d’obtenir des enregistrements PTR. Si le premier plan ne comporte aucune trace du réseau en aval, pourquoi le registre devrait-il configurer le second ?

Le Draft 1, soumis le 10 avril 2012, transformait cette intuition en condition opérationnelle. Tim McGinnis présentait AFPUB-2012-DNS-001-DRAFT-01 comme une modification d’AFPUB-2005-v4-001. Le texte décrivait une base publique d’information sur les réseaux, nourrie par l’enregistrement des affectations, et rappelait que la politique de 2005 considérait l’inscription dans la base Whois d’AFRINIC comme un élément de validité de l’affectation. Il qualifiait son mécanisme d’« enforcement ». Ce vocabulaire révèle l’ambition du projet ; il ne confère aucune autorité publique à l’institution qui l’emploie.

Le conflit ne portait donc pas seulement sur la propreté d’une base. Il portait sur le choix du levier. Au lieu de détecter une lacune, d’en avertir l’opérateur et de l’aider à la réparer, la section 3.1 liait l’octroi d’une nouvelle délégation DNS inverse à la présence d’une affectation ou d’une sous-allocation « correctement enregistrée ». Une donnée manquante ou mal reconnue pouvait ainsi produire un résultat à un autre étage : le service demandé ne serait pas configuré.

Ce déplacement est institutionnellement important. Une entrée absente peut correspondre à plusieurs réalités : l’opérateur n’a rien déclaré ; il a déclaré à une granularité que la règle de rapprochement ne reconnaît pas ; une mise à jour authentifiée attend encore son traitement ; la base ou l’interface présente un retard ; un agent a associé le mauvais objet à la mauvaise plage ; ou la demande de délégation elle-même décrit imparfaitement la zone. Le même symptôme — « aucun objet correspondant trouvé » — recouvre donc des causes différentes.

Si la réponse est un refus technique, la qualité de la procédure de diagnostic devient aussi importante que l’obligation d’enregistrer.

Le Draft 1 avait néanmoins une qualité qu’une lecture rapide de son titre peut masquer. Sa section 3.3 excluait le retrait des délégations inverses déjà approuvées avant une éventuelle ratification. Seules les allocations postérieures auraient été touchées. Autrement dit, le texte n’organisait pas une campagne de coupure rétroactive. Il dessinait une règle prospective pour les nouvelles situations et, dans sa section 3.2, un dispositif de rappels aux LIR disposant déjà d’une délégation inverse mais sans affectation ou sous-allocation enregistrée.

Cette clause de sauvegarde réduisait considérablement le rayon d’impact immédiat. Elle reconnaissait, même sans le formuler en ces termes, qu’un état technique fonctionnel mérite une protection particulière. Une délégation active peut être intégrée à des procédures, à des contrôles de réputation ou à des systèmes de journalisation. La défaire au seul motif d’un dossier incomplet aurait fait peser sur la continuité un risque sans rapport nécessaire avec la réalité opérationnelle du réseau. Le Draft 1 ne franchissait pas ce pas.

Il ne faut pas, en sens inverse, lui attribuer les mécanismes d’une version ultérieure. Le présent examen s’arrête au texte identifié comme Draft 1 dans les documents de 2012. Le Draft 2, ses différences et la suite du processus constituent un autre objet. Cette séparation est indispensable : lire une règle postérieure dans le texte du 10 avril revient à juger une proposition à partir de dispositions qu’elle ne contenait pas.

Trois sections, trois fonctions distinctes

La section 3.1 formait le cœur du mécanisme. AFRINIC ne devait plus accorder de délégation inverse pour l’espace d’adresses qu’il administrait si aucune affectation ou sous-allocation de cet espace n’était correctement enregistrée dans sa base. Le texte ne définissait pas la granularité exacte à laquelle « cet espace » devait être rapproché d’une zone inverse. Il ne faut notamment pas importer rétrospectivement un seuil plus précis issu d’une autre version. Cette indétermination est substantielle, car les frontières d’un objet de registre et celles d’une délégation DNS ne se superposent pas toujours d’elles-mêmes.

La section 3.2 visait le stock de situations existantes, mais par la communication, non par la suppression. Les LIR qui disposaient d’un DNS inverse pour des allocations sans affectations ou sous-allocations repérées devaient être contactés. MyAFRINIC et le courrier électronique étaient envisagés. Les modalités détaillées restaient confiées au personnel du Secrétariat.

Ce choix gardait de la souplesse, mais laissait hors du texte des garanties déterminantes : quel message faisait foi, quel destinataire était réputé atteint, quelle anomalie exacte devait être corrigée, quel délai de réponse s’appliquait et comment contester un rapprochement erroné ?

La section 3.3, enfin, établissait la limite temporelle. Les délégations inverses associées à des allocations approuvées avant la ratification ne devaient pas être retirées. La proposition aurait affecté les allocations ultérieures. Cette distinction interdit deux récits excessifs. Le premier ferait du Draft 1 un simple message pédagogique sans conséquence : c’est faux, puisque la section 3.1 conditionnait un nouveau service. Le second en ferait un plan de démantèlement des délégations existantes : c’est tout aussi faux, puisque la section 3.3 les protégeait.

Ces trois fonctions auraient dû être évaluées séparément. Le rappel d’une obligation documentaire n’a pas le même niveau de conséquence que le refus d’un changement technique. La protection d’un état antérieur n’est pas une validation générale du motif de refus appliqué aux demandes futures. Et la capacité administrative de retrouver une entrée dans une base ne répond pas, à elle seule, à la question de savoir si cette entrée est réellement absente ou seulement invisible au test utilisé.

Le compte rendu d’AFRINIC-16 montre que le débat du 18 mai 2012 avait perçu une partie de cette complexité. L’auteur y a présenté l’exactitude des affectations enregistrées comme le problème à résoudre et le DNS inverse comme un moyen d’incitation. Le raisonnement économique était clair : si le contrôle existant n’intervenait qu’au moment où un membre demandait davantage d’espace, un opérateur qui n’en redemandait pas pouvait ne jamais ressentir de pression pratique pour améliorer ses déclarations. La perspective d’avoir besoin d’une délégation inverse créait un autre moment de vérification.

Selon le même compte rendu, l’auteur a cité une proportion supérieure à 60 % de fournisseurs ayant enregistré des affectations et proche de 40 % n’en ayant enregistré aucune. Il a également été question d’un seuil souple de 80 % lié à la démonstration d’usage ou d’enregistrement avant une nouvelle demande d’espace. Ces nombres expliquent la logique du débat, mais ne permettent pas d’en reconstituer la base empirique. Le compte rendu ne livre ni population observée, ni date d’extraction, ni requête, ni traitement des dossiers incomplets, ni audit indépendant.

Dire qu’une réunion a enregistré ces chiffres est exact ; dire qu’ils établissaient l’ampleur réelle du problème serait aller au-delà de la preuve disponible.

Des participants ont interrogé l’efficacité du mécanisme, la charge pour le personnel et son caractère applicable. Ils ont aussi rappelé que l’Internet peut fonctionner sans DNS inverse et discuté de l’idée de scanner des ports, y compris de la nécessité éventuelle d’obtenir le consentement des opérateurs. Ces interventions ne constituent pas des conclusions techniques ou juridiques adoptées. Elles montrent plutôt que la proposition mettait en relation plusieurs problèmes — qualité du registre, observation des réseaux, dépendance au DNS, capacité de traitement — qui auraient exigé des réponses plus distinctes.

Le résultat procédural est lui aussi précis et limité. AFRINIC-16 a enregistré l’absence de consensus et le retour du projet sur la liste. Le 29 novembre, les diapositives d’AFRINIC-17 identifiaient encore le Draft 1 comme la version courante et en reproduisaient les trois sections opératoires. Le rapport annuel 2012 a ensuite indiqué que les propositions discutées à AFRINIC-17 n’avaient pas obtenu de consensus. Ces documents prouvent la date, le texte présenté, les propos attribués et le résultat enregistré. Ils ne prouvent ni ratification, ni mise en œuvre, ni légitimité générale du processus, ni autorité publique d’AFRINIC.

Le DNS inverse, uniquement là où le mécanisme l’exige

Pour comprendre l’enjeu, il suffit d’un rappel technique resserré. Dans le DNS IPv4, des zones sous IN-ADDR.ARPA organisent la recherche inverse. Un enregistrement PTR permet d’associer une adresse à un nom. Pour publier les PTR correspondant à un espace, l’opérateur doit pouvoir administrer la zone pertinente ou recevoir une délégation qui le conduit vers ses serveurs de noms. Le registre, placé du côté parent de cette chaîne pour l’espace qu’il coordonne, peut donc détenir une étape nécessaire à la création ou à la modification de la délégation.

Cette dépendance ne signifie pas que le DNS inverse commande le routage des paquets. Une adresse peut rester joignable sans PTR. L’absence de résolution inverse ne constitue donc pas, par elle-même, une extinction de la connectivité IP. Elle peut cependant avoir des effets plus étroits et variables. Certains services examinent la présence ou la cohérence entre un PTR et un enregistrement direct ; certains outils opérationnels, journaux et mécanismes de réputation utilisent les noms inverses ; des configurations incohérentes peuvent déclencher des refus ou rendre l’identification plus difficile.

La RFC 1912 traite ces problèmes comme de bonnes pratiques et des sources possibles d’incidents, non comme la preuve que tout service exige un PTR.

Le Draft 1 utilisait cette valeur opérationnelle comme levier documentaire. C’est précisément pourquoi le vocabulaire importe. Refuser une demande parce que le registre ne peut pas encore vérifier le lien nécessaire à une délégation est une décision technique provisoire, qui doit être explicable et corrigible. Refuser pour « punir » une déclaration tardive transformerait le même service en instrument disciplinaire. Le premier cas peut relever du rôle étroit d’un coordinateur ; le second suppose un pouvoir de contrainte qu’un registre privé ne possède pas.

La différence tient au lien de nécessité. Si AFRINIC doit savoir quelle zone déléguer, à quel demandeur authentifié et vers quels serveurs, il peut exiger les preuves directement requises pour effectuer ce changement sans erreur. Si l’objet manquant dans Whois ne change ni l’identité du demandeur, ni l’étendue de la zone, ni l’autorité opérationnelle sur les serveurs, l’utilisation du DNS comme moyen de pression pour une obligation administrative séparée devient beaucoup plus difficile à justifier. La question utile n’est donc pas « le registre peut-il dire non ? » en général.

Elle est : « quel fait précis manque pour accomplir ce changement précis en sécurité ? »

Préserver le registre sans sacraliser le gardien

Une base publique d’affectations et de sous-allocations a une valeur concrète. Elle aide à identifier les contacts responsables, à orienter le traitement des incidents et à comprendre la distribution d’un espace. Son exactitude mérite des procédures sérieuses. Un registre qui accumule des entrées périmées, ambiguës ou absentes ne remplit pas correctement sa fonction de tenue de livres. L’erreur serait de conclure que l’importance du livre agrandit automatiquement les pouvoirs du gardien.

AFRINIC est un registre régional privé, un opérateur de services de registre et un coordinateur technique. Il peut allouer et enregistrer des ressources numériques dans le cadre de ses relations, maintenir un historique, authentifier des instructions et coordonner des dépendances comme le DNS inverse. Il n’est pas un État, un législateur, un régulateur, une police, un procureur, un organe de punition, un confiscateur, un tribunal ou un souverain. La publication d’une politique, la participation à une réunion, l’enregistrement d’un consensus ou la dépendance technique à un service ne créent pas ces qualités.

Cette frontière ne rend pas le registre impuissant. Elle lui impose une discipline de proportionnalité fonctionnelle. Il peut vérifier les conditions nécessaires au service demandé. Il peut dire qu’une preuve manque, exposer la règle de rapprochement et inviter le demandeur à compléter son dossier. Il peut suspendre le traitement d’une modification qu’il ne peut pas authentifier. Il peut corriger une entrée démontrée fausse et consigner la correction.

Mais il ne peut déduire d’un objet manquant qu’un réseau n’existe pas, que des adresses ne sont pas utilisées, qu’un titulaire a abandonné ses intérêts ou qu’une faute mérite une privation technique.

Cette distinction protège aussi la qualité des données. Un système qui traite toute divergence comme une désobéissance encourage les corrections précipitées et les déclarations faites pour débloquer un service, même lorsque le bon diagnostic reste incertain. À l’inverse, une procédure qui décrit exactement l’anomalie — plage, objet attendu, zone inverse, heure de la requête, résultat de la recherche — permet à l’opérateur et au registre d’établir ensemble le fait. La conformité durable vient alors de la traçabilité, pas de la peur d’une coupure.

Le mot « enforcement » employé dans le projet doit ainsi être lu comme l’auto-description d’un moyen d’incitation, non comme la reconnaissance d’un pouvoir légal. Une institution ne peut créer sa propre autorité en nommant son action. L’existence d’une dépendance opérationnelle augmente même l’exigence de retenue : plus un service est difficile à remplacer, moins son contrôle doit servir à régler des questions extérieures à sa fonction immédiate.

Le vrai défaut : l’absence d’une théorie du faux négatif

Le Draft 1 décrivait un résultat binaire : affectation ou sous-allocation correctement enregistrée, ou absence d’un tel objet. Il ne décrivait pas le chemin par lequel le système parvenait à cette conclusion. Or un refus n’est fiable que si le test qui le déclenche l’est aussi.

Imaginons, sans prétendre qu’un de ces incidents s’est produit, les états que la procédure devait pouvoir distinguer. Une affectation peut avoir été saisie mais ne pas encore être visible. Elle peut couvrir une plage plus large ou plus étroite que celle recherchée. Elle peut exister sous un objet dont le type ou la relation n’est pas celui que le script attend. Une correction peut être en attente de validation. Le compte du demandeur peut être authentique mais ne pas disposer du rôle exact permettant d’éditer l’objet. Le registre peut associer la demande à la mauvaise allocation parente.

Une faute de saisie peut porter sur le préfixe, le contact ou le serveur de noms. Dans tous ces cas, le message « aucune affectation enregistrée » serait incomplet, voire trompeur.

Le faux négatif est particulièrement coûteux quand la conséquence dépasse l’écran de validation. Si le système refuse simplement de sauvegarder un brouillon et indique le champ erroné, la correction est locale. S’il refuse une délégation attendue pour un service en préparation, le demandeur doit diagnostiquer à la fois son dossier, les critères du registre et l’état du DNS. Le coût d’une erreur de rapprochement se déplace alors vers l’opérateur, alors que l’information nécessaire pour l’expliquer se trouve souvent chez le registre.

Une politique robuste aurait donc défini non seulement l’obligation substantielle, mais aussi le test : quel objet compte comme affectation ou sous-allocation ; quelle relation avec l’allocation parente est requise ; comment traiter les chevauchements ou les granularités différentes ; à quel instant la base est observée ; quel état de traitement est acceptable ; et quelle preuve remplace temporairement une entrée lorsque le retard est imputable au système. Sans ces éléments, « correctement enregistré » donne une direction mais pas une décision reproductible.

La section 3.2 ne comblait pas ce vide. MyAFRINIC et le courriel sont des canaux, pas une procédure. Un rappel utile doit nommer le fait en cause, permettre de vérifier l’identité de l’expéditeur, indiquer une action, définir un délai de service et offrir une réponse traçable. Laisser les détails au Secrétariat peut convenir pour la mise en page d’un message ; cela devient insuffisant lorsque ces détails déterminent si une demande technique avance ou reste bloquée.

Une retenue réelle, mais incomplète

La protection des délégations préexistantes mérite d’être considérée comme un choix de conception, pas comme une note de bas de page. En conservant le dernier état actif, le Draft 1 évitait qu’un audit documentaire rétrospectif ne produise une dégradation immédiate du DNS. Il séparait le traitement du passé de la condition imposée aux demandes futures. Cette asymétrie est raisonnable : créer un nouvel état exige de vérifier la demande ; défaire un état ancien exige généralement une justification plus forte, car l’action peut perturber des dépendances déjà établies.

Mais le caractère prospectif ne résout pas tout. Une nouvelle délégation peut elle aussi être importante pour un réseau nouvellement déployé, pour une réorganisation interne ou pour la mise en cohérence d’un service. Le demandeur a donc besoin d’un chemin de sortie lorsqu’un refus repose sur une erreur. La section 3.3 limite la population exposée ; elle ne fournit ni motif détaillé, ni délai de correction, ni examen, ni retour rapide après une mauvaise décision.

Le Draft 1 se trouve ainsi dans une position intermédiaire. Il n’était ni le plan punitif rétroactif que son titre peut suggérer, ni une simple règle de validation sans conséquence. Il reconnaissait la continuité pour le stock existant, tout en sous-spécifiant les garanties applicables au flux nouveau. C’est cette combinaison, et elle seule, qui permet d’en tirer une leçon utile sans déformer son histoire.