Résumé

  • RFC 5158 est un document informatif de mars 2008 consacré à une délégation DNS inverse en libre-service pour 6to4.
  • Le préfixe 6to4 incorporait une adresse IPv4 externe sous 2002::/16 et produisait un /48 de site calculable.
  • La proposition installait une délégation DNS classique d'un seul niveau sous 2.0.0.2.ip6.arpa.
  • La source 6to4 d'une requête bornait la zone /48 que le client pouvait demander.
  • Le primaire et au moins un secondaire devaient être joignables, faire autorité et présenter des SOA et ensembles NS concordants.
  • Ces contrôles établissaient la préparation des serveurs, pas la véracité des futurs enregistrements PTR.
  • HTTPS protégeait l'échange, mais l'authentification fondée sur l'adresse restait rudimentaire et susceptible d'usurpation.
  • Un poste interne pouvait modifier la délégation à l'insu de l'administrateur si le site ne filtrait pas cet accès.
  • Une adresse IPv4 dynamique réattribuée pouvait transmettre à son nouveau détenteur un état inverse ancien.
  • Des TTL courts et des contrôles périodiques réduisaient la persistance d'un état périmé sans prouver la continuité de garde.
  • Le RFC refusait expressément de faire du DNS inverse une validation fiable du lien entre domaine et adresse.
  • L'audit doit distinguer préparation DNS, mandat administratif, garde de l'adresse, contenu PTR et résultat applicatif.

La cohérence répondait à une question limitée

Dans 6to4, les 32 bits d'une adresse IPv4 externe prenaient place après le préfixe 2002::/16. Le site obtenait ainsi un /48 et, par construction, une zone inverse déterminable. Cette régularité permettait à un service d'accepter une demande provenant de l'adresse correspondante tout en refusant qu'elle vise le /48 d'un tiers.

La délégation IPv4 traditionnelle ne fournissait pas forcément cette capacité. Le détenteur d'une seule adresse n'avait souvent aucune frontière propre dans l'arbre inverse IPv4, tandis que le mécanisme 6to4 séparait l'accès IPv6 du fournisseur capable de déléguer une zone IPv6. Le registre imaginé par RFC 5158 comblait cette lacune par une délégation DNS ordinaire, pas par un répertoire parallèle destiné aux lecteurs.

Le contrôle de source avait donc une vertu réelle : il limitait la portée d'une action. Mais limiter une action à une zone calculée n'identifie pas celui qui a le droit de représenter le site. L'adresse décrit un emplacement réseau observé ; le mandat décrit une décision institutionnelle.

Un serveur autoritaire peut publier une assertion fausse

Avant de modifier le parent, le service devait interroger les serveurs proposés. Le primaire et le secondaire devaient répondre, se déclarer autoritaires pour la zone, partager le même SOA et publier le même ensemble d'enregistrements NS. Une configuration bancale ou inachevée était ainsi détectée avant d'être exposée dans la délégation.

Mais le test ne portait pas sur chaque PTR. Il ne demandait pas si un nom correspondait réellement à l'opérateur d'une machine, si l'organisation l'avait approuvé ou si le nom resterait valide après une réaffectation. Des serveurs parfaitement synchronisés peuvent répéter avec une grande disponibilité la même information erronée.

La nuance est décisive pour les consommateurs. Une réponse autoritaire veut dire que le serveur parle au nom de la zone selon la chaîne DNS courante. Elle ne transforme pas le texte retourné en preuve d'identité, de propriété ou de responsabilité opérationnelle. La cohérence augmente la fiabilité de la distribution ; elle ne garantit pas la vérité externe de l'assertion distribuée.

Le canal sécurisé ne choisissait pas l'administrateur

L'interface devait utiliser HTTPS, ce qui réduisait interception, imitation du service et effets indésirables des caches mandataires. Associée à l'observation de la source 6to4, cette protection rendait une demande automatique raisonnablement contenue pour son époque.

Le RFC n'en faisait pourtant pas une identité forte. Il qualifiait l'authentification par adresse de rudimentaire et notait le risque d'usurpation. Plus banalement, une machine située derrière la même frontière pouvait posséder une source légitime et ne disposer d'aucun mandat pour administrer le DNS du site. Sans ACL locale ou pare-feu, elle pouvait changer la délégation sans que l'administrateur le sache.

Il faut donc conserver deux reçus. Le premier décrit le transport : serveur web authentifié, session protégée, source observée. Le second décrit l'autorité : principal, rôle, étendue du mandat, approbation et possibilité de révocation. Le premier ne doit jamais être promu silencieusement en second.

La rotation d'une IPv4 rompait le récit continu

Le nom de zone dérivé donne une impression de permanence parce que sa forme ne change pas. La garde sous-jacente peut pourtant changer rapidement. Lorsqu'une adresse IPv4 dynamique est rendue puis attribuée à un autre site, le même /48 6to4 réapparaît. La délégation ou les caches peuvent encore raconter l'histoire du détenteur précédent.

RFC 5158 proposait des TTL courts et une surveillance régulière. Tous les trente jours, le registre pouvait revalider les serveurs ; après un échec, il avertissait, attendait quatorze jours et retestait avant suppression. Le contrôleur de l'adresse IPv4 pouvait demander un blocage distinct du libre-service.

Ce calendrier réduit l'exposition mais n'atteste pas la continuité. Un ancien serveur encore sain réussit le test après le changement de garde. Inversement, une panne ne signifie pas que l'organisation a perdu son droit. Santé DNS et possession de l'adresse suivent des horloges différentes.

Le PTR devait rester un indice borné

Le texte prévient qu'une correspondance inverse ne valide pas de manière fiable la relation entre domaine et adresse. L'absence d'un PTR n'invalide pas davantage cette relation. Même une vérification aller-retour ne prouve ni l'identité juridique ni le contrôle administratif ; elle compare deux configurations DNS.

Cette retenue protège les journaux et les politiques d'accès contre une erreur courante. Un nom PTR est commode pour lire un événement, agréger des machines ou amorcer une enquête. Il devient dangereux lorsqu'un système le traite comme un certificat délivré par une autorité d'identité.

La preuve défendable est plus étroite : à une date donnée, un parent a délégué une zone calculée vers un ensemble de serveurs qui répondait aux contrôles annoncés. Pour aller plus loin, il faut joindre la garde actuelle de l'adresse, l'approbation de l'administrateur et des indices indépendants sur l'acteur nommé.

La disparition de 6to4 ne supprime pas la frontière

Les documents ultérieurs ont décrit les difficultés opérationnelles de 6to4 et déprécié son mécanisme de relais anycast. Les exigences TLS modernes ont aussi remplacé la dépendance ancienne citée par RFC 5158. Le nom historique du service dans le document ne démontre aucune disponibilité actuelle.

L'architecture conserve pourtant une leçon contemporaine. Les systèmes de déploiement testent encore qu'une cible répond, que deux répliques concordent et qu'une requête vient d'un réseau attendu. Ces observations justifient une action technique bornée. Elles ne nomment pas automatiquement le décideur légitime et ne certifient pas la vérité des données publiées après l'action.

Sources

  1. RFC 5158, HTML
  2. RFC 5158, texte
  3. Notice RFC Editor
  4. Notice IETF Datatracker
  5. Historique RFC 5158
  6. Références RFC 5158
  7. Errata RFC 5158
  8. RFC 3056
  9. RFC 3068
  10. RFC 3964
  11. RFC 6343
  12. RFC 7526
  13. RFC 2136
  14. RFC 3596
  15. RFC 2317
  16. RFC 1034
  17. RFC 1035
  18. RFC 4033
  19. RFC 8996
  20. RFC 8446
  21. Registre IANA des adresses IPv6 spéciales
  22. RFC 3172
  23. RFC 8020
  24. RFC 2308
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy