Résumé

  • L’objet de DNS inverse présenté en février avec deux valeurs nserver: identiques contient maintenant ns1.ibits.xyz et ns2.ibits.xyz. Le relevé de septembre retrouve ces deux noms dans le renvoi du parent et obtient une réponse SOA faisant autorité du premier. Il serait faux de présenter l’ancien doublon comme encore présent.
  • Compter des attributs, distinguer des cibles DNS, observer une réponse et démontrer une indépendance face aux pannes ne revient pas au même. Une protection contre la saisie répétée peut réduire une ambiguïté sans garantir le service ni justifier de nouvelles sanctions sur les ressources.

Le mot qui a changé la discussion

Dans un modèle d’objet WHOIS, « multiple » n’est pas une promesse de secours. Ce marquage autorise un attribut à apparaître plusieurs fois ; il ne fixe pas, à lui seul, un minimum de deux occurrences. Une partie de l’échange consacré aux serveurs de noms d’AFRINIC a pourtant porté sur cette lecture. La précision paraît modeste. Elle change le remède envisagé : empêcher un doublon exact n’exige pas nécessairement d’interdire tous les objets ne désignant qu’une seule cible.

Le 2026-02-19, Frank Habicht a soumis une question au groupe de travail sur la base de données. Un nouvel objet, 8.c.4.f.f.0.c.2.ip6.arpa, contenait deux fois ns1.ibits.xyz. Fallait-il refuser la création quand deux attributs avaient exactement le même contenu ? Il demandait aussi quelles vérifications existaient déjà et précisait ne pas intervenir en qualité de président. Il s’agissait d’une proposition de discussion, pas de l’annonce d’une règle.

Le lendemain, il a admis que la rédaction documentaire alors disponible permettait cette saisie. Son objection concernait l’erreur humaine susceptible de suivre : un lecteur pressé pouvait voir deux lignes et en déduire l’existence de deux serveurs faisant autorité. Son message complémentaire montrait un renvoi du parent ne comportant qu’une cible NS. Une requête SOA distincte auprès de cette cible obtenait REFUSED. Les deux résultats ne décrivaient pas la même défaillance.

Le premier expliquait pourquoi le nombre de lignes exagérait le nombre de cibles DNS. Le second concernait le service de la zone par le serveur interrogé. Un nom répété peut répondre correctement ; deux noms différents peuvent ne pas répondre. Mélanger ces dimensions ferait d’un problème de représentation la preuve d’une indisponibilité générale. Le dossier ne le permet pas, et son état actuel oblige à être encore plus précis.

Le cas concret n’est plus celui de février

À 04 h 12 UTC, le 2026-09-14, une consultation en lecture seule du même objet a trouvé ns1.ibits.xyz et ns2.ibits.xyz. Une requête NS adressée à ns1.afrinic.net a également renvoyé ces deux cibles. Enfin, une requête SOA au premier serveur a produit NOERROR, le drapeau de réponse faisant autorité et un enregistrement SOA. Le service WHOIS public permet de retrouver l’objet ; ces constats proviennent des requêtes WHOIS et DNS précisément délimitées ici.

Cette observation est une contre-preuve importante à toute affirmation selon laquelle le doublon signalé serait toujours visible ou le premier serveur refuserait toujours cette requête. Elle ne démontre pas qui a modifié l’objet, à quelle date, ni pour quelle raison. Elle ne révèle pas non plus une modification générale du contrôle des saisies. Une correction dans un objet peut avoir été faite sans nouvelle règle commune ; aucun auteur de la correction n’a été identifié par cette vérification.

Le relevé ne comprend pas de requête SOA au second serveur, de contrôle des réponses PTR, de mesures depuis plusieurs régions ou d’essai de basculement. Nous n’avons pas cartographié les adresses des deux noms, leurs chemins réseau, leurs sites ou leurs prestataires. Une réponse du premier serveur confirme un fait limité et utile. Elle ne certifie ni tous les accès ni toutes les conditions de panne.

Une histoire mieux fondée commence donc par retirer l’accusation devenue inexacte. Le dossier conserve son intérêt, mais ailleurs : il montre comment une base de données peut afficher deux éléments qu’un autre système traite comme un seul. Le bon résultat de septembre n’efface pas cette leçon. La leçon, en retour, ne doit pas effacer le bon résultat.

Ce que le DNS compte vraiment

La section 5 de RFC 2181 donne la raison technique. Un ensemble d’enregistrements DNS, ou RRSet, rassemble des enregistrements ayant le même nom propriétaire, la même classe et le même type, mais des données différentes. Deux enregistrements dont toutes ces composantes et les données sont identiques n’ajoutent pas un second élément utile ; les serveurs doivent supprimer les doublons rencontrés. Répéter une cible NS ne crée donc pas une autre cible de délégation.

La base WHOIS et le DNS ne servent cependant pas exactement le même lecteur. La première rend accessibles les attributs soumis et facilite leur modification. Le second fournit les données nécessaires à la résolution. Si une interface laisse compter les attributs comme des services indépendants, le DNS peut se comporter correctement tout en laissant l’être humain tirer une conclusion erronée du registre. C’est une ambiguïté de contrôle et de présentation, pas la preuve d’une attaque.

Le domaine affiché en février illustrait cette différence de façon inhabituelle : les deux lignes avaient exactement le même contenu. Le cas actuel retire l’ambiguïté sur les noms. Il reste impossible de passer directement de « deux noms distincts » à « deux possibilités indépendantes de survie ». La pluralité textuelle, la pluralité des cibles et la pluralité des dépendances sont trois propriétés séparées.

RFC 2182, consacré aux serveurs DNS secondaires, raisonne en termes de pannes plausibles. Il souligne la dispersion géographique et topologique. Deux machines dans la même pièce peuvent protéger contre l’arrêt d’une machine tout en tombant ensemble lors d’une coupure électrique. Des services séparés géographiquement peuvent encore dépendre d’une administration commune. Ce sont des hypothèses à vérifier dans une évaluation opérationnelle, non une description mesurée de la zone examinée.

Il faut aussi éviter l’erreur inverse. Un seul nom peut donner accès à une infrastructure distribuée ; deux noms ne prouvent pas nécessairement deux machines, deux adresses ou deux chemins. Nous n’avons démontré aucune de ces architectures dans cet exemple. La recommandation de diversité ne fournit pas par elle-même une cartographie des dépendances réelles d’un opérateur.

Une recommandation n’est pas une cardinalité imposée

La réponse du 20 février expliquait le sens de la multiplicité en citant le manuel alors lié. Le 2026-03-23, Sylvain BAYA a reconnu sa première lecture erronée. Il a néanmoins proposé d’élargir la réflexion : restrictions sur les objets à une seule cible, comparaison des attributs, traitement des délégations non servies correctement et document de bonnes pratiques. Sa position mérite examen, mais elle n’était pas une décision collective.

Le modèle public interrogé en septembre marque encore nserver: comme obligatoire, répétable et clé inverse. Sa description précise les noms admis, la possibilité d’un point final et certaines adresses de liaison. Elle n’énonce pas, à elle seule, un minimum de deux noms distincts. Aucune tentative de création ou de modification n’a été effectuée pour tester les vérifications de tous les canaux de production. Lire un modèle n’équivaut pas à éprouver chaque comportement du système.

Les instructions de DNS inverse d’AFRINIC recommandent au moins deux serveurs de noms pour la redondance. Elles décrivent aussi la configuration préalable et sa vérification avant propagation de la délégation. Cette recommandation a une logique opérationnelle claire. La transformer en condition générale d’acceptation serait néanmoins une décision supplémentaire, avec un périmètre, un calendrier et des conséquences propres pour les objets existants.

L’argument favorable à une démarche plus large est solide : empêcher un doublon ne fournit pas le serveur secondaire absent et ne permet pas à une cible de faire autorité pour la zone. Des conseils de déploiement et une aide concrète peuvent apporter davantage qu’un message de refus. Mais cela ne rend pas inutile un avertissement de saisie ; cela rappelle simplement qu’il ne résout pas tout. Les outils de correction et les investissements de résilience n’ont pas le même propriétaire ni le même coût.

Corriger sans écraser des données utiles

Une protection limitée pourrait montrer à l’éditeur que deux attributs identiques correspondent à une seule cible distincte. Un refus proposé lors de la création pourrait également l’obliger à retirer une répétition accidentelle. Dans les deux cas, l’objectif serait de rendre la saisie moins trompeuse, non de garantir deux services opérationnels. Cette analyse ne prouve pas qu’une telle protection a été déployée chez AFRINIC.

La comparaison doit toutefois respecter la sémantique. La casse ou un point final facultatif ne produisent pas nécessairement des noms DNS différents. À l’inverse, la description actuelle permet certaines adresses IPv4 ou IPv6 après un nom de serveur situé dans le domaine délégué. Deux attributs comportant des données de liaison différentes et légitimes ne doivent pas être effacés au seul motif que leur nom cible est identique.

Une présentation honnête pourrait conserver le nombre d’attributs bruts et afficher séparément le nombre de noms cibles canoniques. Elle préserverait les données de liaison et réserverait les constatations opérationnelles à une autre indication, datée et documentée. Le lecteur saurait alors si « deux » désigne des lignes, des noms ou des réponses observées. Aucun de ces chiffres ne deviendrait subrepticement une attestation de résistance à une panne de fournisseur.

Sources