Résumé

  • La RFC 8806 encadre une copie complète de la zone racine réservée au résolveur du même hôte, avec validation DNSSEC et données identiques à la racine publique.
  • Si la copie ne peut être actualisée avant l’expiration SOA, elle ne peut pas continuer à répondre : le résolveur doit immédiatement revenir aux racines non locales.

Le trajet devient local, pas l’autorité

Un résolveur interroge normalement une racine distante lorsqu’il ne possède pas en cache la délégation nécessaire. La RFC 8806 permet de récupérer toute la zone racine, d’exploiter un service faisant autorité sur la même machine et d’y diriger ces requêtes. Cela peut préserver les recherches lorsque le trajet externe est perturbé et empêcher un observateur intermédiaire de voir les questions adressées à la racine.

Le pouvoir transféré reste limité au chemin de service. La copie doit être identique aux données de la racine publique. Le système doit disposer de la partie publique actuelle de la clé de signature de la racine, récupérer les enregistrements DNSSEC et valider les données signées. Il ne reçoit aucun mandat pour modifier les délégations ou créer une racine concurrente.

La limite d’autorisation est également physique : le service local doit répondre uniquement au résolveur du même hôte. Il ne doit pas devenir un serveur faisant autorité pour d’autres machines. Cette restriction circonscrit les conséquences d’une mauvaise copie aux clients du résolveur concerné.

La fraîcheur décide du droit de répondre

La zone locale suit les temporisations du SOA. Elle peut donc être légèrement en retard sur les racines mondiales, qui peuvent recevoir une notification de changement. Ce retard prévu n’autorise jamais le service à dépasser l’expiration. En cas d’échec de l’actualisation, le système doit basculer immédiatement vers les racines non locales avant de servir des données périmées.

La télémétrie de fraîcheur est ainsi un contrôle d’autorisation. L’opérateur doit connaître le numéro de série SOA, la marge avant expiration, le résultat du dernier transfert complet et l’état du chemin de repli. Une alerte reçue après l’expiration arrive trop tard.

La RFC avertit qu’une copie ancienne peut conserver de mauvais serveurs de noms pour tout un domaine de premier niveau. Le bénéfice de continuité peut alors devenir une panne difficile à diagnostiquer. Le propriétaire de la plateforme doit donc tester le basculement, tandis que les responsables sécurité conservent la maîtrise de la validation DNSSEC.

Le bénéficiaire et le coût ne sont pas les mêmes

Les clients bénéficient d’un chemin racine plus court et moins observable. L’opérateur assume en revanche l’acquisition de la zone, la validation, la surveillance, les sources de transfert et la réponse aux échecs. Les services AXFR cités par la RFC ne sont pas garantis ; plusieurs sources et un retour aux racines publiques restent nécessaires.

Le contre-factuel éclaire le choix. Sans copie locale, le résolveur dépend du réseau pour joindre une racine lorsqu’il manque une donnée. Avec une copie saine, cette dépendance diminue. Avec une copie périmée sans repli, l’organisation remplace une dépendance externe distribuée par une erreur locale silencieuse.

Preuves et limites

Les faits proviennent de la RFC 8806, complétés par la RFC 4033 pour DNSSEC, la RFC 5936 pour AXFR et la publication IANA de la zone racine. L’interprétation sur la responsabilité opérationnelle est une analyse. Ces sources ne mesurent ni le nombre de déploiements, ni les gains de latence ou de confidentialité, ni la fiabilité réelle des mécanismes de repli ; ces points restent inconnus.

Sources