Résumé

  • La RFC 3123 a créé le record APL pour une suite ordonnée de préfixes IPv4 ou IPv6, avec un bit de négation, tout en imposant à chaque application de définir le sens du vide, des RR multiples, des familles inconnues et du signe !.
  • Un APL valide, même protégé par DNSSEC ou TSIG dans leur domaine respectif, prouvait la publication d’une représentation. Il ne prouvait ni contrôle du préfixe, ni autorité, ni installation d’une ACL, ni résultat d’accès.

Un format commun, sans mandat commun

Au début des années 2000, le DNS transportait déjà bien davantage que des adresses d’hôtes. La mécanique des Resource Records associait aux noms des serveurs, des routes de courrier et diverses informations d’infrastructure. La RFC 1101 avait décrit la publication de réseaux d’une organisation. Certaines anciennes versions de BIND lisaient même des plages placées dans des records TXT pour limiter grossièrement l’accès aux données de zone.

Ces usages mélangeaient facilement deux questions : comment représenter une plage, et que doit en faire le système qui la lit ? Publiée en juin 2001 dans la catégorie Experimental, la RFC 3123 a séparé les réponses. Le type 42, APL, portait une famille d’adresses, une longueur de préfixe, un bit N, une longueur de données et les octets utiles de l’adresse. Les familles 1 et 2 désignaient IPv4 et IPv6 ; elles pouvaient cohabiter dans le même record.

Le texte ne fit pas de ce format une politique universelle. Il déclara que le record définissait un cadre, sans fixer la signification de la liste. Publication de blocs, description de zones inverses sans classe ou matériau pour un contrôle d’accès n’étaient que des scénarios possibles. Aucun n’était spécifié par la RFC, et les exemples ne prouvaient l’existence d’aucun déploiement.

Le DNS pouvait donc établir qu’une suite d’octets avait été publiée sous un nom. Il ne pouvait pas, par ce seul fait, désigner le principal habilité à engager un opérateur, la règle locale choisie ou la décision réellement exécutée.

Le point d’exclamation attendait son interprète

Dans le format texte, un élément pouvait commencer par !. Le format binaire conservait cette présence dans le bit N. Lire immédiatement « refus », « exception » ou « non autorisé » serait pourtant ajouter une règle. La RFC exigeait que la spécification de l’application définisse précisément la négation.

Le vide était tout aussi révélateur. Un RDATA vide formait une liste vide valide. Mais signifiait-il « aucune adresse autorisée », « aucune restriction », « pas d’avis » ou « hériter d’une autre source » ? Seule l’application pouvait répondre. Plusieurs records APL dans le même RRset étaient licites, et leur combinaison restait elle aussi extérieure au format.

Une application devait encore annoncer les familles attendues et le traitement des autres familles, y compris celles qui n’étaient pas définies en 2001. Rejeter le record, ignorer un élément ou le conserver pour un lecteur futur sont trois décisions différentes. Un parseur qui reconnaît les champs ne possède pas encore l’autorité de choisir.

Cette modestie rejoint un principe de couche commune minimale : les règles partagées doivent s’arrêter aux propriétés que chacun peut vérifier localement. Le futur ne doit pas être enfermé dans un caractère de ponctuation dont l’interprétation n’a pas été convenue.

L’ordre et les doublons devaient survivre

La RFC interdisait aux serveurs et résolveurs de « nettoyer » la liste. Deux éléments identiques pouvaient apparaître et ne devaient pas être fusionnés. Leur ordre devait rester intact ; ni tri, ni agrégation. Une telle discipline paraît inutile si l’on suppose un ensemble mathématique. Or le format refusait précisément cette hypothèse : une application future pouvait faire dépendre son calcul de la position ou de la répétition.

Le transporteur préservait donc la déclaration sans prétendre la comprendre. Si un intermédiaire regroupait deux préfixes voisins, il pouvait modifier une politique dont il ne connaissait ni la priorité ni la logique. La fidélité de la représentation protégeait l’autonomie de l’interprète.

Une normalisation restait toutefois obligatoire au niveau des octets. Les zéros finaux inutiles de la partie adresse ne devaient pas être transmis. Des préfixes équivalents recevaient ainsi une représentation canonique unique, condition utile au modèle DNSSEC cité à l’époque. Cette canonisation répondait à « quels octets compare-t-on ou signe-t-on ? », pas à « que faut-il autoriser ? ».

Une signature peut stabiliser l’objet d’une vérification. Elle ne transforme pas cet objet en décision.

Authentifier le record ne complétait pas la chaîne

La section sécurité demandait de considérer les informations DNS comme dangereuses sans les techniques DNSSEC ou TSIG référencées. Elle avertissait aussi qu’une publication pouvait révéler une topologie et que la construction d’ACL à partir d’APL pouvait compromettre la sécurité.

DNSSEC aide à vérifier l’origine et l’intégrité des données signées. TSIG authentifie un message ou une transaction entre parties configurées. Ces propriétés comptent : une liste altérée peut conduire une application à une autre décision. Mais elles ne disent pas si le gestionnaire de zone était autorisé à commander un pare-feu, si l’application a consulté la bonne version, si la compilation a réussi ou si le paquet a rencontré ce point d’exécution.

Il faut conserver des reçus distincts : nom interrogé, RRset et instant, état de validation, version du contrat applicatif, configuration locale, politique compilée, accusé d’installation, interface visée et observation du trafic. Passer directement du record DNS au résultat revient à attribuer au répertoire une puissance qu’il n’a jamais démontrée.

Le DNS distribuait efficacement une déclaration parce qu’il était délégué, caché et largement disponible. Mais distribuer une déclaration n’est pas distribuer un mandat. L’administrateur de zone publie ; l’opérateur du système consommateur décide encore.

Le numéro 42 n’était pas une statistique d’adoption

Les exemples de la RFC sont mémorables : plages d’une organisation, fragments de zone inverse, restriction de transfert AXFR, réseaux multicast. Ils illustrent la syntaxe sous des noms d’exemple. Le texte précise qu’ils ne spécifient aucune application et n’affirment pas qu’une application APL existe ou existera.

La catégorie Experimental ne prouve pas davantage un essai sur le terrain. Elle situe le document dans le processus de 2001. La RFC 3597 expliqua plus tard comment transporter des types DNS inconnus ; elle ne mesure pas l’usage d’APL. La RFC 4034 affina le traitement canonique de DNSSEC sans ajouter de sens général à une liste de préfixes.

L’histoire vérifiable s’arrête donc à la conception. RFC 3123 a défini un contenant extensible, compact et fidèle, qui préserve famille, préfixe, ordre, répétition et négation déclarée. Pour raconter une adoption, un incident ou un succès, il faudrait une preuve provenant d’une implémentation ou d’un réseau nommé.

La frontière était la contribution

La valeur durable d’APL tient à la place laissée vide. Le socle commun fixait juste assez de règles pour qu’un producteur et un lecteur échangent la même liste. Chaque application devait choisir sa convention de nom, le sens du vide, la combinaison des RR, les familles admises et la négation. Chaque opérateur restait libre d’adopter ou non cette application.

Cette séparation ne garantissait pas la sécurité. Elle rendait les erreurs attribuables. Un record authentique pouvait être ancien ; une spécification correcte pouvait être mal configurée ; une ACL compilée pouvait être appliquée à la mauvaise interface ; une installation confirmée pouvait ne jamais se trouver sur le chemin du paquet.

Le même préfixe pouvait apparaître dans la zone, le modèle applicatif, la politique compilée et le journal d’un paquet. L’identité textuelle n’en faisait pas un seul fait. Les acteurs, les temps et les autorités différaient.

La RFC 3123 n’a pas fait du DNS le gouverneur du réseau. Elle lui a permis de transporter une description précise, tout en gardant hors du record la décision de gouverner.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3123.txt
  2. https://www.rfc-editor.org/info/rfc3123
  3. https://datatracker.ietf.org/doc/rfc3123/
  4. https://www.rfc-editor.org/rfc/rfc1034.txt
  5. https://www.rfc-editor.org/rfc/rfc1035.txt
  6. https://www.rfc-editor.org/rfc/rfc1101.txt
  7. https://www.rfc-editor.org/rfc/rfc2317.txt
  8. https://www.rfc-editor.org/rfc/rfc2535.txt
  9. https://www.rfc-editor.org/rfc/rfc2845.txt
  10. https://www.rfc-editor.org/rfc/rfc2874.txt
  11. https://www.rfc-editor.org/rfc/rfc3597.txt
  12. https://www.rfc-editor.org/rfc/rfc4034.txt