Résumé

  • Le Homenet Naming Authority crée et signe la Public Homenet Zone, sans remettre ses clés privées DNSSEC au prestataire chargé de la publication.
  • Le Distribution Manager authentifie les canaux de contrôle et de synchronisation, mais une session TLS réussie ne prouve ni la propriété du domaine, ni la présence du bon DS dans la zone parente, ni la diffusion du dernier numéro de série.
  • L'exploitation doit conserver une chaîne de preuves distinctes : droit sur le domaine, génération signée, transfert, service public, délégation, validation externe et retrait effectif.

Le jour où deux versions vraies se sont contredites

Lors d'un changement de prestataire, l'ancien service continue de répondre avec une zone signée dont la période de validité n'est pas terminée. Le nouveau Distribution Manager a déjà reçu un numéro de série plus récent. Deux points d'autorité répondent, chacun avec des données cryptographiquement correctes, mais ils ne décrivent plus le même domicile.

Cet exemple ne relate pas un incident documenté par le RFC. Il met en évidence la difficulté que le texte organise : une signature établit l'origine d'un contenu sous une clé, pas l'exclusivité du canal qui le publie. Un transfert réussi établit qu'une version a franchi une frontière, pas que toutes les instances publiques la servent. Un DS accepté par un intermédiaire n'établit pas encore ce que la zone parente publie.

Le RFC 9526 rend possible une architecture où le foyer demeure l'auteur cryptographique tout en étant absent du chemin public des requêtes. Cette dissociation est saine, car elle protège le routeur domestique et évite de remettre la clé de signature au prestataire. Elle impose toutefois une discipline : ne jamais transformer un succès local en verdict global.

Le domaine public ne copie pas home.arpa

La zone concernée est une Public Homenet Zone sous un domaine enregistré. Elle est distincte de la Homenet Zone en home.arpa, réservée à l'usage interne. Le protocole ne propose pas de publier automatiquement l'inventaire nominatif du réseau local.

Le HNA peut obtenir des noms et des adresses auprès de DHCP, mDNS, UPnP, PCP ou d'une configuration manuelle. Il doit ensuite décider lesquels méritent une exposition publique. Une adresse link-local doit être écartée. Une adresse privée ou ULA peut être utile à un utilisateur passant par un VPN, mais la résolution du nom ne garantit pas l'accès au service.

La première pièce du dossier est donc la politique de sélection. Elle doit identifier les enregistrements admis, les exclusions, la version de la règle et la personne ou fonction qui a autorisé la publication. Sans cette mémoire, une zone finale ne permet pas de savoir si le nom révélateur d'un appareil était voulu, découvert mécaniquement ou simplement oublié après son retrait.

La confidentialité dépend de cette sélection. Un nom est souvent plus stable et plus parlant qu'une adresse. Il peut révéler la présence d'une caméra, d'une imprimante ou d'un service familial longtemps après un renumérotage. NSEC3 et le blocage des transferts réduisent certaines possibilités d'énumération, sans rendre les noms publics invisibles aux requêtes et à l'analyse du trafic.

L'auteur caché et l'éditeur public

Le HNA construit tout le contenu de la zone publique et la signe avec DNSSEC. Il gère les opérations et les éléments de clé. L'architecture ne prévoit aucun transfert des clés privées DNSSEC vers le Distribution Manager.

Le HNA agit comme primaire caché. Son adresse ne devrait pas figurer dans les enregistrements NS publics sans protections supplémentaires, et il n'est pas censé répondre aux requêtes ordinaires venues d'Internet. Les serveurs faisant face au public appartiennent à la DNS Outsourcing Infrastructure.

Cette répartition limite chaque acteur. Le prestataire ne peut pas fabriquer une nouvelle affirmation authentique sans la clé du HNA. En revanche, il peut ne pas récupérer une génération, retarder sa diffusion ou maintenir une ancienne génération encore valablement signée. Le domicile conserve l'autorité de rédaction ; le prestataire détient une part décisive de l'autorité de visibilité.

Un tableau de bord devrait montrer cette dualité. « Zone signée » doit nommer le numéro de série, le condensat, le DNSKEY et les périodes RRSIG. « Zone publique » doit nommer les instances observées, la version qu'elles servent et l'heure de l'observation. Le premier état ne peut pas certifier le second.

Deux canaux protégés, deux affirmations

Le canal de contrôle sert à échanger les paramètres de délégation, les informations nécessaires à la chaîne DNSSEC et l'adresse du canal de synchronisation. Le HNA initie la connexion au DM ; les deux parties s'authentifient mutuellement sous TLS.

Sur le canal de synchronisation, les rôles de connexion sont inversés. Le DM devient client TLS, le HNA serveur et primaire caché. AXFR ou IXFR transporte la zone. DNS NOTIFY peut accélérer la détection d'une modification, tandis que les temporisations SOA permettent au secondaire de vérifier périodiquement l'existence d'une nouvelle version.

Même si les mêmes adresses et ports participent aux échanges, les canaux restent distincts. La réussite du contrôle prouve l'identité des interlocuteurs selon une règle de confiance. Elle ne prouve pas que le HNA dispose du droit sur le domaine enregistré. La réussite du transfert ne prouve la bonne génération que si le reçu conserve le numéro de série et le condensat. Aucune des deux ne décrit ce que les serveurs publics ont ensuite distribué.

L'erreur classique consiste à étendre la portée du mot « authentifié ». Un pair authentifié n'est pas automatiquement autorisé pour tout domaine. Une commande autorisée n'est pas automatiquement exécutée sur tous les systèmes. Une exécution interne n'est pas automatiquement un résultat observable. Les preuves doivent s'arrêter à leur frontière réelle.

La distribution décisive reste propre au fournisseur

Après avoir reçu la zone en tant que secondaire caché, le DM la transmet aux serveurs publics. Le RFC nomme ce segment Distribution Channel, mais ne lui impose pas un protocole unique. AXFR, une copie de base de données, une API REST ou d'autres mécanismes peuvent convenir.

Cette liberté évite de remplacer les plateformes existantes. Elle ouvre aussi le plus grand angle mort du dispositif. Un reçu HNA–DM ne constitue pas un reçu de chaque serveur exposé. Une infrastructure anycast peut masquer plusieurs versions logicielles, régions et files de déploiement derrière une même adresse.

Le prestataire doit fournir une preuve adaptée à son architecture : génération acceptée par le DM, diffusion vers les cibles, lecture du SOA et du DNSKEY sur les instances attendues, anomalies ou quorum explicite. Des sondes externes réparties géographiquement améliorent l'observation, mais elles ne doivent pas être présentées comme un inventaire exhaustif des nœuds internes.

La formulation opérationnelle peut rester précise : « le DM a reçu la génération 108 ; quatre perspectives ont servi 108 ; une perspective a encore servi 107 pendant douze minutes ». Cette phrase permet l'action. « Publication réussie » masque au contraire le lieu et la durée de l'écart.

NOERROR engage le DM, pas la zone parente

Pour établir une délégation sécurisée, le HNA remet le condensat de sa KSK sous forme de DS. Si le DOI possède la relation nécessaire avec le bureau d'enregistrement ou le registre, il peut faire inscrire ce DS dans la zone parente. Le DM répond NOERROR lorsqu'il accepte la demande et s'engage à mettre à jour le parent.

Cet engagement est une preuve utile mais bornée. Il ne constitue pas une lecture de la zone parente. Une procédure de registre peut échouer, un ancien DS peut subsister, un autre compte peut disposer du véritable pouvoir ou les caches peuvent encore exposer l'état précédent.

La délégation sécurisée exige trois réalités simultanées : une zone enfant signée, le DS correspondant dans le parent et un validateur capable de construire la chaîne. Le RFC exige même que le HNA signe lorsqu'il ne parvient pas à organiser la délégation sécurisée. Une zone peut donc être correctement signée tout en restant cryptographiquement orpheline du parent.

Le dossier doit conserver le DS soumis, la réponse du DM, la lecture indépendante du parent et un résultat de validation externe. Les réduire à un booléen « DNSSEC actif » condamne l'équipe à chercher à l'aveugle pendant une rotation de clé.

La propriété du domaine vient d'un autre système

Le DOI ne doit pas servir la zone s'il n'est pas convaincu que le HNA possède le Registered Homenet Domain. Le RFC place cependant la preuve de cette propriété hors de son champ. L'autorité commence donc avant le premier message du protocole.

Quand le DOI est également bureau d'enregistrement, le compte client et la relation contractuelle peuvent produire cette confiance. Avec un fournisseur DNS distinct, une autre vérification est nécessaire. Dans les deux cas, le droit sur le domaine, le certificat du canal de contrôle et la clé DNSSEC peuvent appartenir à des cycles de vie différents.

Une migration doit cartographier ces pouvoirs : qui peut modifier le parent, quelle identité HNA peut commander le DM, quelle clé signe la zone active et quel ancien prestataire doit cesser de répondre. Une sauvegarde de zone sans sauvegarde de l'identité de contrôle ne garantit pas la capacité de retrait. Une nouvelle clé DNSSEC ne rétablit pas automatiquement le droit sur le domaine.

Le retrait mesure la réalité du contrôle

Le RFC exige que le HNA puisse demander la suppression de la délégation auprès d'un DM précis. Après réception de la commande, le DM doit cesser de servir la zone et peut répondre NOERROR pour indiquer la suppression.

Là encore, la réponse ne couvre qu'une frontière. Les serveurs publics doivent retirer la zone, les données NS ou DS du parent peuvent nécessiter une action distincte et les caches récursifs restent soumis aux TTL. Lors d'une migration, l'ancienne et la nouvelle autorité peuvent coexister plus longtemps que prévu.

Une preuve de retrait observe l'absence. Elle vérifie chaque extrémité publique connue, les enregistrements du parent, l'horizon des caches et la période de validité des signatures. Elle distingue arrêt définitif et transfert vers un nouveau fournisseur. Tant que l'ancien système répond, l'autorité historique n'a pas entièrement disparu.

Le RFC confie par ailleurs la suppression d'un HNA inactif à l'accord commercial. Le droit technique du client à demander un retrait et le droit contractuel du fournisseur à nettoyer un service abandonné ne sont pas identiques. Ils doivent avoir des délais, responsables et procédures de recours explicites.

Le renumérotage révèle les horloges cachées

Lorsqu'un préfixe résidentiel change, le HNA actualise les adresses, informe le DM de son nouvel emplacement de synchronisation et déclenche un nouveau transfert. Dans une transition make-before-break, les anciens et nouveaux préfixes coexistent. Dans un renumérotage brutal, l'ancien devient inutilisable avant que le nouveau soit prêt.

Le texte recommande au HNA de signaler son emplacement à chaque démarrage, car il ignore combien de temps il est resté hors ligne et si sa zone signée a expiré. L'adresse souhaitée, le numéro de série du HNA, la version reçue par le DM, la version servie, le parent et les caches n'avancent donc pas dans une transaction atomique.

Il faut comparer ces horloges. Une ancienne adresse peut rester légitimement en cache tout en étant déjà inaccessible. Une nouvelle adresse peut apparaître dans le DNS avant la politique de pare-feu. Le service peut fonctionner localement pendant une panne WAN alors que le chemin public est périmé. « Le DNS fonctionne » n'est pas une question assez précise.

Sources

Sources