Un transfert de zone copie les données de zone entre des serveurs DNS ou vers un client de gestion autorisé. AXFR est le protocole de transfert complet décrit dans RFC 5936 . Un transfert disponible de manière inattendue peut révéler un inventaire étendu d'enregistrements, mais son existence ne fait pas en soi que l'authentification du courrier électronique réussisse ou échoue. Évaluez ce qui a été divulgué, si le transfert était intentionnel et quels contrôles régissent l’accès.
Établir l’autorité et la permission
Références : RFC 5936 §5.
Identifiez la zone exacte et ses serveurs faisant autorité. Obtenez une autorisation avant de tester les transferts par rapport à un service de production. Utilisez d'abord les outils de configuration et d'audit pris en charge par le fournisseur, lorsqu'ils sont disponibles. N'analysez pas des domaines non liés et n'essayez pas de contourner un transfert refusé pour rendre un résultat plus dramatique.
Un serveur secondaire légitime peut nécessiter un accès au transfert. Le service DNS public faisant autorité et l’autorisation de transférer l’ensemble de la zone sont des décisions distinctes. Passez en revue les clients autorisés, le mécanisme d’authentification, les contrôles de transport et l’objectif opérationnel. Une liste blanche basée uniquement sur l'adresse n'est pas interchangeable avec l'authentification client cryptographique.
Interpréter correctement les données renvoyées
Références : RFC 5936 §2.2, RFC 5936 §3.
AXFR renvoie le contenu de la zone conformément au protocole, y compris le cadrage SOA de début et de fin. Une réponse réussie peut révéler des noms qui étaient déjà interrogeables individuellement mais qui ne pouvaient pas être facilement énumérés. Évaluez si l’inventaire révèle des noms internes sensibles, des services abandonnés ou des dépendances opérationnelles. DNS public ne doit pas être utilisé comme magasin secret en premier lieu.
N’assimilez pas refus à une zone parfaitement sécurisée. Les enregistrements individuels restent interrogeables et les inventaires peuvent être disponibles via des certificats, des fuites de configuration ou d'autres sources. A l’inverse, un transfert intentionnellement public n’est pas automatiquement une vulnérabilité ; évaluer la politique de l’organisation et l’exposition réelle.
Séparer l’impact du courrier de l’exposition des stocks
Références : RFC 6376 §3.1, RFC 5936 §1.
Un transfert ne modifie pas SPF autorisations, remplacer un DKIM clé ou changement DMARC politique. Découvrir un sélecteur le nom ne révèle pas sa clé de signature privée. Les clés publiques DKIM sont conçues pour être récupérées par les vérificateurs. Si une zone contient un identifiant ou une valeur confidentielle, il s’agit d’un incident de gestion de données distinct nécessitant sa propre réponse.
Utilisez l'inventaire pour vérifier la propriété et les dépendances obsolètes sans prétendre que l'énumération prouve l'exploitation. Un alias en suspens peut justifier une enquête, mais la contrôlabilité réelle dépend du service de destination et de la configuration. Ne vous inscrivez pas et ne réclamez pas les ressources de quelqu'un d'autre simplement pour renforcer un rapport.
Reproduire l’évaluation en toute sécurité
Le point de contrôle comprend un élément en forme de transfert hors ligne avec un SOA de départ, un marqueur TXT et un SOA de fin correspondant. Le contrôle local vérifie son cadrage simple et l'étiquete comme preuve d'inventaire, et non comme échec d'authentification. Un deuxième appareil contient une réponse REFUSÉE et est étiqueté transfert refusé, non zone sécurisée.
Exécutez le script fourni pour reproduire ces étiquettes. Il ne s'agit pas d'un analyseur AXFR complet ni d'un transfert réseau. Pour un laboratoire isolé autorisé, configurez un serveur principal et secondaire à l'aide de la documentation officielle du serveur choisi, testez un client autorisé et un client refusé, et conservez les réponses réelles et la configuration d'accès pertinente. Les tests complets de mise en œuvre primaire/secondaire et de contrôle d’accès n’ont toujours pas été effectués ; l'échange de bouclage scripté retenu plus étroit ci-dessous est distinct.
Corriger en gardant à l’esprit la continuité
Références : RFC 5936 §5, RFC 5936 §6.
Si l'accès dépasse la politique, limitez les transferts via les contrôles de serveur pris en charge tout en préservant les opérations secondaires légitimes. Passez en revue les restrictions d’accès et l’authentification plutôt que de supposer que l’une se substitue à l’autre. Après le changement, vérifiez l'accès non autorisé refusé et le transfert autorisé continu, la fraîcheur de la zone et la disponibilité faisant autorité.
Documentez la portée de l’enregistrement divulgué, les clients visés, les mesures correctives exactes et les limites des tests. Séparez le résultat de l'authentification du courrier électronique : des tests de messages représentatifs et des requêtes d'enregistrement efficaces sont toujours nécessaires pour évaluer le comportement du courrier. Un bon rapport résout l'exposition sans transformer une observation de l'administration DNS en une affirmation de sécurité de messagerie non prise en charge.
Preuves filaires historiques conservées
Ce qui suit décrit la capture de bouclage retenue du 7 novembre 2026, inspectée mais non réexécutée en tant qu'expérience réseau pour cet examen. Les nouvelles vérifications de modèles hors ligne sont enregistrées séparément.
Le point de contrôle conservé enregistre les requêtes DNS sur TCP réelles sur son propre serveur de bouclage minimal. Un exemple autorisé.test AXFR renvoie le cadrage SOA correspondant et la politique TXT apex v=spf1 -all ; une requête pour la zone other.test hors de portée renvoie REFUSED. Une requête UDP TXT distincte récupère cette même stratégie SPF . Cela désigne la dépendance spécifique : un évaluateur SPF a besoin de la politique TXT sélectionnée pour le domaine d'enveloppe, tandis qu'AXFR expose l'inventaire plus large sans le modifier. Les octets de fil de requête et de réponse, les points de terminaison et les heures UTC sont conservés. Le serveur utilise une liste blanche de zones volontairement simple, et non une authentification de production ou une implémentation AXFR complète.