Résumé

  • RFC 5395 répartissait les paramètres DNS entre plusieurs espaces: bits d’en-tête, OpCodes, RCODE, TYPE de données, QTYPE, Meta-TYPE et CLASS; la même largeur numérique ne créait pas une autorité commune.
  • Unassigned, Reserved et Private Use sont trois états différents. L’usage privé permet une convention locale, mais ne garantit ni unicité ni interopérabilité au-delà de son périmètre.
  • La preuve complète associe champ et contexte filaire, nombre, procédure d’attribution, instantané du registre, comportement du logiciel, interprétation du pair et résultat pour l’utilisateur.

Seize n’était pas une identité suffisante

Le DNS transporte les codes d’erreur à plusieurs endroits. Le RCODE de base figure dans l’en-tête; OPT étend sa largeur; TSIG et TKEY portent aussi des champs d’erreur. RFC 5395 recensait 16 comme BADVERS dans OPT et comme BADSIG dans TSIG. RFC 6895 a conservé cette exception et a précisé celle du code 9, qui peut signifier « non autoritaire » ou « non autorisé » selon le contexte TSIG.

Enregistrer uniquement rcode=16 revient donc à jeter la donnée qui décide du sens. Le problème n’est pas un détail de présentation. Une équipe peut chercher une incompatibilité de version alors qu’elle observe un échec cryptographique. Une statistique agrégée peut additionner des événements qui appellent des propriétaires et des remèdes différents.

La clé d’audit doit contenir le registre exact, le champ, le RR éventuel, la largeur effective et la référence normative. Une colonne universelle nommée code encourage des jointures qui n’ont aucun sens. Deux valeurs numériquement égales ne sont identiques que si leur espace sémantique l’est aussi.

RFC 6895 impose d’ailleurs, sauf pour les exceptions historiques 9 et 16, de ne pas réutiliser un numéro pour des erreurs différentes sous prétexte qu’elles vivent dans des RR différents. La règle protège l’interopérabilité en empêchant la multiplication silencieuse des contextes nécessaires au décodage.

Un bit vide sur le dessin pouvait revenir du passé

Le schéma de l’en-tête DNS semble offrir des cases simples. Pourtant RFC 5395 note que certaines implémentations copiaient l’en-tête de la requête pour initialiser la réponse sans effacer les bits. Donner à un bit de requête un autre sens dans une réponse pouvait donc transformer une valeur héritée en signal volontaire.

Le bit Z portait un précédent plus ancien encore. Des logiciels l’avaient interprété dans une requête comme l’exigence d’une réponse du serveur primaire. Le RFC estimait que les implémentations contemporaines ignoraient probablement ce comportement, mais exigeait tout de même une action de normalisation pour lui attribuer un sens.

Ce passage ne prouve pas le comportement de tous les serveurs actuels. Il prouve que le diagramme ne contient pas toute la réalité installée. Un espace apparemment libre peut être occupé par une habitude de copie, un parseur ancien ou une convention locale invisible au concepteur. L’autorité publique et les essais d’interopérabilité restent donc nécessaires.

La vitesse de livraison ne confère aucune propriété. Le premier produit à utiliser le bit ne peut pas décider que les autres interprétations ont disparu. Il doit montrer le chemin de décision et le comportement observé chez les pairs, pas seulement une capture réussie dans son laboratoire.

Privé signifie local, pas petit registre mondial

Pour les RRTYPE, la plage 65280–65534 est réservée à l’usage privé. Selon RFC 8126, IANA n’y enregistre pas d’attributions et n’empêche pas deux sites de choisir la même valeur pour des usages incompatibles. Les participants doivent eux-mêmes éviter les conflits dans le périmètre qu’ils annoncent.

Deux entreprises peuvent donc employer 65300 sans erreur tant qu’elles restent séparées. L’une y place un état de santé, l’autre une consigne de politique. Leur fusion révèle le coût différé: même numéro, deux formats et deux actions. Aucun registre global ne tranche, car l’absence de coordination globale faisait partie du contrat initial.

L’usage privé n’est pas interdit. Il faut le gouverner comme une délégation limitée: liste des systèmes participants, durée, contrôle des sorties, domaine de collision, propriétaire et procédure de retrait. Si le besoin devient public, le projet doit demander une attribution adéquate au lieu de transformer l’antériorité d’un déploiement en droit acquis.

Une valeur non attribuée est encore autre chose. Elle attend une attribution selon la politique du registre. La choisir publiquement peut entrer en collision avec une décision ultérieure légitime. « Non attribué » ne signifie pas « premier arrivé propriétaire ».

L’examen a attribué un identifiant, pas installé une fonction

RFC 5395 a organisé une procédure d’Expert Review pour certains RRTYPE. RFC 6895 l’a rendue plus directe: modèle complet, demande adressée à la liste dédiée, expert nommé par IANA, décision explicite et archivage public des modèles approuvés.

Le seuil technique vise l’extensibilité sûre. Un TYPE de données doit pouvoir traverser un serveur qui l’ignore selon RFC 3597; un Meta-TYPE doit être facultatif et pouvoir être éliminé sans danger. L’expert doit normalement refuser une description insuffisante, une hypothèse DNS incorrecte, un traitement qui viole ces conditions ou une demande excessive de valeurs.

Cette décision est importante, mais son objet reste limité. Elle ne démontre pas qu’un serveur autoritaire accepte la syntaxe, qu’un secondaire transfère les octets, qu’un outil de zone les conserve, qu’un résolveur les expose, ni qu’une application réalise le service voulu. Le registre crée une identité coordonnée; l’exécution vient ensuite.

Une organisation doit donc conserver deux dossiers. Le premier prouve l’autorité: demande, critères, décision, entrée IANA, date. Le second prouve le fonctionnement: versions, configurations, captures, résultats négatifs, comportement du pair et résultat utilisateur. Mélanger les deux permet de déclarer « supporté » un identifiant qui n’a jamais quitté le registre.

Les octets inconnus pouvaient voyager sans agir

RFC 3597 a défini une notation générique pour les RR inconnus: TYPE suivi du nombre décimal, puis \#, une longueur et les octets RDATA en hexadécimal. Il a aussi fixé des règles de compression et de comparaison afin qu’un serveur puisse préserver un RR qu’il ne comprend pas.

Cette propriété réduit le coût d’extension. Un secondaire n’a pas besoin de connaître toute nouvelle sémantique pour conserver et retransmettre les données. Mais la conservation n’est pas l’exécution. Un transfert intact prouve la garde des octets. Une réponse intacte prouve la récupération. Aucune ne prouve qu’une application a vérifié le contenu ou pris la bonne décision.

Le test doit suivre chaque étape: saisie dans le provisionnement, représentation textuelle, encodage filaire, transfert, cache, API, parseur applicatif et effet final. Une seule boucle aller-retour ne suffit pas. Le chemin peut perdre le sens après avoir préservé les bits, ou reconnaître un nom tout en sérialisant mal le RDATA.

RFC 3597 ajoute une nuance utile: un type connu écrit sous forme générique reste un type connu après lecture et doit recevoir ses règles spécifiques. Changer la représentation ne permet pas de neutraliser les obligations sémantiques.

Le RFC historique et le registre vivant répondaient à des dates différentes

RFC 5395 date de 2008. RFC 6195 l’a remplacé en 2011; RFC 6895 a remplacé RFC 6195 en 2013, modifié le processus et fermé le registre des sous-types AFSDB. L’instantané IANA gelé pour cette enquête indique une mise à jour au 28 août 2026 et contient de nombreuses entrées postérieures au RFC initial.

Il n’y a aucune contradiction nécessaire. Le RFC prouve la règle et l’état publiés à son époque. Le registre prouve l’état maintenu à la date de capture. Un rapport qui présente la table de 2008 comme inventaire actuel efface dix-huit ans d’actions. Un rapport qui cite « IANA » sans date rend sa propre preuve impossible à reproduire.

Il faut aussi surveiller les projections locales. CSV, XML, page HTML, module YANG et table intégrée dans un produit peuvent recevoir les mises à jour à des moments différents. L’accord doit être vérifié par hash, génération et date, non présumé parce que tous portent le même nom.

Limite de preuve

Les sources gelées établissent les textes, les statuts et la succession des RFC, les règles génériques pour RR inconnus, le vocabulaire des politiques IANA et l’état de la table capturée. Elles ne prouvent aucun taux d’adoption actuel, aucun défaut de fournisseur, aucune collision réelle ni aucun incident d’exploitation.

La conclusion défendable est plus utile qu’une généralisation. Un nombre DNS passe par plusieurs autorités: choix local, attribution, enregistrement, conservation par l’infrastructure, compréhension par l’application et résultat observé. Chaque passage produit une preuve différente. Un entier visible n’abolit pas ces frontières.