Résumé

  • La RFC 1183 proposait l’enregistrement RP pour associer à un nom DNS une boîte de contact différente du responsable de la zone ou du POSTMASTER de la machine.
  • RP désignait une boîte aux lettres et un nom où chercher des informations TXT. Une adresse publiée indiquait une piste d’escalade, pas la preuve qu’un message serait lu ni qu’une panne serait réparée.

La passerelle tombe. La zone DNS, elle, répond toujours. On y trouve le contact SOA, donc quelqu’un semble responsable. Mais responsable de quoi ? De la base des noms. L’auteur de la zone peut corriger une entrée DNS sans savoir ouvrir le capot de la passerelle. Quant au POSTMASTER de la machine, il sert aux problèmes de courrier ; une passerelle peut même ne recevoir aucun courrier. La RFC 1183, publiée en octobre 1990, part de cette scène embarrassante.

Les auteurs proposent un enregistrement « Responsible Person », RP, de type 17. Leur exemple traverse la frontière institutionnelle : une passerelle nommée sous ISI.EDU pourrait renvoyer à une permanence chez BBN.COM. Celui qui publie le nom et celui qui peut remettre le service en marche ne sont pas nécessairement le même employeur. L’enregistrement rend cette séparation consultable. Il ne donne pas au destinataire de l’alerte les clés de la zone.

Le format est court, mais chaque champ compte. Le premier nom désigne une boîte aux lettres selon la convention DNS déjà utilisée pour le contact SOA. Le second désigne un nom dont les enregistrements TXT peuvent fournir des indications lisibles par un humain. Il faut normalement interroger ce second nom à part. Plusieurs machines peuvent partager la même notice TXT, ce qui évite de recopier la consigne sur chacune. Cela crée aussi une dépendance commune : une notice périmée trompe plusieurs lecteurs à la fois.

La RFC accepte qu’un point racine, « . », signale l’absence de boîte ou l’absence de notice TXT. Elle permet plusieurs RP pour un seul nom et recommande alors des durées de cache identiques. Ses exemples placent plusieurs personnes autour d’une même machine. C’est moins élégant qu’un unique responsable dessiné sur un organigramme, et beaucoup plus proche d’une intervention réelle : maintenance, exploitation et messagerie peuvent avoir des interlocuteurs distincts.

L’enregistrement peut être attaché à n’importe quel nœud de la hiérarchie DNS, pas seulement au sommet d’une zone. Voilà l’intérêt de RP : le contact correspond à l’objet en panne. Voilà aussi sa fragilité. Si une permanence extérieure change d’adresse ou de mission, la réponse DNS peut rester correcte dans sa syntaxe et fausse dans ses effets. La RFC était expérimentale ; elle décrit un mécanisme, sans mesurer son déploiement ni les réparations qu’il aurait déclenchées.

La frontière que RP dessine mérite de rester visible. SOA dit à qui signaler un problème de base DNS. POSTMASTER vise le courrier. RP tente d’indiquer à qui parler de la machine. Confondre ces trois rôles faisait perdre du temps en 1990 ; une fiche de contact abandonnée en fait encore perdre davantage.

Source : RFC 1183, New DNS RR Definitions, sections 2 à 2.2 ; fiche du RFC Editor.