Résumé

  • Dans un objet domain AFRINIC, mnt-domains référence le mainteneur qui peut autoriser la création d’objets directement sous l’arbre enregistré.
  • Cette autorisation ne démontre ni la configuration des serveurs, ni une délégation active, ni des réponses faisant autorité, ni l’existence de PTR utiles.

Une permission de registre, pas une réponse DNS

Le manuel de la base AFRINIC attribue à mnt-domains une fonction limitée et précise : dans un objet domain, il référence le mainteneur autorisant la création d’objets immédiatement inférieurs dans l’arbre. Le champ répond donc à une question de contrôle des modifications. Il permet d’examiner quelles références d’authentification encadrent une mise à jour ou un litige.

Il ne contient cependant aucun résultat de requête, numéro de série de zone, code de réponse, mesure de latence, validation DNSSEC ou valeur PTR. Il ne met aucun serveur en ligne. Déduire l’exploitation d’un service à partir de cette seule référence revient à confondre une permission inscrite dans un registre avec l’observation d’un système distribué.

La délégation inverse exige d’autres preuves

Le guide AFRINIC consacré au DNS inverse décrit une séquence distincte. Le détenteur configure d’abord la zone sur ses serveurs, puis crée l’objet domain correspondant. AFRINIC vérifie la configuration avant propagation de la délégation et propose un contrôle de lameness. Les serveurs proposés apparaissent dans les valeurs nserver.

Chaque élément répond à une question différente. L’objet décrit l’espace inverse et ses serveurs déclarés. mnt-domains décrit l’autorité sur la création d’objets enfants. La zone parente montre la délégation publiée. Des requêtes directes révèlent quels serveurs répondent et avec quelle autorité. Ces preuves peuvent converger, mais aucune ne remplace les autres.

Une référence de mainteneur valide peut donc coexister avec un objet absent, des serveurs obsolètes, une délégation lame, un serveur inaccessible ou une zone sans PTR. À l’inverse, un DNS opérationnel ne transforme pas le champ en preuve complète des responsabilités contractuelles ou techniques.

Méthode de vérification

Conserver l’objet exact, l’heure de collecte et l’interface utilisée. Relever séparément la clé, nserver, mnt-by, mnt-domains et le parent pertinent. Interroger ensuite la délégation parente et chaque serveur faisant autorité, en notant nom demandé, type, adresse, code de réponse, indicateurs d’autorité et heure.

Pour le service inverse, tester des noms PTR représentatifs sans conclure qu’une seule absence invalide toute la zone. Utiliser le contrôle de lameness pour distinguer une délégation publiée d’un service réellement faisant autorité. La requête RDAP de type domain fournit une vue structurée de l’enregistrement ; elle reste une donnée de registre et non une mesure DNS en direct.

Sources