Qu'est-ce que le transfert de zone DNS et en quoi constitue-t-il une faille de sécurité ?

La redondance est la pierre angulaire du système de noms de domaine (DNS). Si un serveur de noms de référence est hors ligne ou devient inaccessible, des serveurs de secours doivent être prêts à traiter les requêtes concernant votre domaine sans interruption. Pour assurer la synchronisation de ces serveurs secondaires, le DNS s'appuie sur les transferts de zone afin de répliquer automatiquement les enregistrements.

Lorsqu'ils sont correctement configurés, les transferts de zone s'effectuent en toute discrétion entre des serveurs de confiance. Cependant, un simple paramètre par défaut ou une négligence dans le contrôle d'accès peut exposer ce canal de réplication à l'ensemble d'Internet. Lorsque cela se produit, une simple mesure d'administration pratique se transforme en une fuite d'informations à ciel ouvert.

Ce guide explique en quoi consistent les transferts de zone DNS, présente les différences de fonctionnement entre les protocoles AXFR et IXFR, explique pourquoi les transferts ouverts constituent un risque de sécurité majeur et indique comment protéger vos serveurs de noms contre toute reconnaissance non autorisée.

Qu'est-ce qu'un transfert de zone DNS ?

Un transfert de zone DNS consiste à répliquer un fichier de zone depuis un serveur de noms principal faisant autorité vers un ou plusieurs serveurs de noms secondaires via le port TCP 53. Il garantit que les serveurs de noms secondaires disposent de copies identiques de tous les enregistrements de ressources nécessaires pour répondre de manière faisant autorité aux requêtes des clients.

Pour comprendre pourquoi cette réplication existe, il faut examiner le fonctionnement du DNS officiel. Une zone DNS représente un espace administratif distinct au sein de la hiérarchie mondiale des domaines. Le fichier de zone contient le catalogue complet des enregistrements de ressources qui définissent cet espace, notamment les mappages d'adresses (enregistrements A et AAAA), les serveurs de messagerie (enregistrements MX), les emplacements de services (enregistrements SRV) et les chaînes de validation (enregistrements TXT).

Le fait de s'appuyer sur un seul serveur de noms crée un point de défaillance unique inacceptable. Si ce serveur subit une panne matérielle, une congestion du réseau ou des perturbations liées à une attaque par déni de service distribué (DDoS), les visiteurs ne pourront pas accéder à votre nom de domaine.

Pour éviter les temps d'arrêt, les entreprises déploient des serveurs de noms secondaires. La gestion manuelle de ces serveurs serait inefficace et source d'erreurs, car les administrateurs devraient reproduire chaque modification d'enregistrement sur plusieurs hôtes. Les transferts de zone DNS automatisent ce processus, permettant aux serveurs secondaires de récupérer les données de zone mises à jour directement depuis l'hôte maître. Cela garantit une haute disponibilité et répartit le volume de requêtes entre des serveurs de noms dispersés géographiquement.

Fonctionnement des transferts de zones DNS

Les transferts de zone DNS reposent sur une architecture client-serveur dans laquelle le serveur de noms secondaire joue le rôle du client qui demande des données, tandis que le serveur de noms principal joue celui du serveur qui les fournit.

Les requêtes DNS standard émis par les navigateurs Web s'effectuent généralement via le port 53 du protocole UDP (User Datagram Protocol), ce qui garantit rapidité et faible surcharge. En revanche, les transferts de zone s'effectuent via le port 53 du protocole TCP (Transmission Control Protocol). Le protocole TCP offre la connexion fiable et avec état, ainsi que la vérification des erreurs, nécessaires pour transmettre de grands volumes de données structurées sans perte de paquets.

Le processus de synchronisation s'appuie sur l'enregistrement « Start of Authority » (SOA), et plus précisément sur son champ « numéro de série » :

1. Comparaison des numéros de série : Le serveur de noms secondaire interroge régulièrement le serveur principal pour obtenir son enregistrement SOA. Par ailleurs, lorsqu'un administrateur met à jour une zone, le serveur de noms principal peut envoyer un message DNS NOTIFY non sollicité (RFC 1996) pour signaler cette mise à jour aux serveurs secondaires.
2. Décision de transfert : Le serveur secondaire compare le numéro de série du serveur principal à celui de sa propre copie locale. Si le numéro de série du serveur principal est supérieur, le serveur secondaire détecte que les enregistrements ont été modifiés et lance une demande de transfert.
3. Transmission des données : Le serveur principal valide la requête et transmet les enregistrements mis à jour via la connexion TCP établie.

En fonction de la configuration et du volume des modifications, les serveurs effectuent cette synchronisation selon l'une des deux méthodes suivantes : AXFR ou IXFR.

AXFR (transfert de zone complet)

Le transfert faisant autorité (AXFR), défini dans la RFC 1035 et mis à jour dans la RFC 5936, constitue le mécanisme de transfert d'origine. Lorsqu'une requête AXFR est exécutée, le serveur de noms principal envoie l'intégralité du fichier de zone, du début à la fin, en commençant et en terminant par l'enregistrement SOA.

Bien que simple et fiable, le protocole AXFR s'avère inefficace pour les zones de grande taille. Si une entreprise gère une zone contenant 50 000 enregistrements de ressources et modifie une seule adresse IP, un transfert AXFR retransmet l'intégralité des 50 000 enregistrements. Pour les réseaux à fort trafic, ces transferts complets répétés consomment inutilement de la bande passante et des cycles de traitement.

IXFR (transfert incrémental par zone)

Afin d'éliminer la surcharge liée aux transferts complets, la RFC 1995 a introduit le transfert incrémental de zone (IXFR). Au lieu de copier l'intégralité de la base de données, l'IXFR n'envoie que les différences spécifiques entre la version actuelle du serveur secondaire et la version mise à jour du serveur principal.

Lors d'un échange IXFR, le serveur secondaire envoie le numéro de série SOA actuel dans sa requête. Le serveur principal analyse son journal des modifications, identifie les enregistrements qui ont été supprimés ou ajoutés entre les versions intermédiaires, puis ne transmet que ces différences. Cela réduit considérablement la consommation de bande passante et accélère la synchronisation au sein des architectures distribuées.

Comparaison entre AXFR et IXFR

Si un serveur secondaire est resté hors ligne pendant une période prolongée et que son numéro de série ne figure pas dans l'historique des transactions du serveur principal, IXFR ne peut pas combler ce vide. Dans ce cas de figure, le système bascule en douceur vers un transfert AXFR complet afin de reconstruire la zone.

Pourquoi les transferts en zone ouverte constituent une faille de sécurité

Les transferts de zone sont essentiels à la synchronisation administrative, mais ils ont été conçus dans un souci de disponibilité plutôt que de confidentialité. Par défaut, les configurations des serveurs de noms hérités considéraient souvent toute requête AXFR entrante comme légitime.

Un transfert de zone ouvert se produit lorsqu'un serveur de noms faisant autorité répond à des requêtes AXFR provenant d'adresses IP non autorisées. Lorsque cette erreur de configuration est présente, toute personne connectée à Internet peut interroger le serveur de noms et obtenir une copie complète du fichier de zone.

Cette faille constitue une vulnérabilité critique en matière de divulgation d’informations. Plutôt que de recourir à des attaques par force brute par essais et erreurs, un attaquant obtient un inventaire structuré et autorisé de l’empreinte numérique d’une organisation. Cela transforme une phase de reconnaissance manuelle en une découverte instantanée et exhaustive du système. Les transferts de zone ouverts restent l’une des vulnérabilités DNS les plus répertoriées vulnérabilités DNS les plus courantes car ils exposent les schémas opérationnels internes au regard du public.

Ce que les pirates apprennent grâce à un transfert de zone

Lorsqu'un acteur malveillant se procure un fichier de zone via une requête AXFR ouverte, il accède à des données qui sont rarement visibles via des requêtes DNS standard :

• Répertoires complets des sous-domaines : Les attaquants identifient tous les sous-domaines enregistrés, y compris les hôtes nommés d'après des fonctions internes, des services ou des technologies propriétaires.
• Serveurs de développement et de préproduction: Les sous-domaines tels que dev.example.com, test-api.example.com ou qa-vpn.example.com exécutent souvent des logiciels en préversion qui ne disposent pas de pare-feu de niveau production, de correctifs de sécurité à jour ou de contrôles d'accès stricts.
• Portails administratifs et à distance : Les liens vers l'intranet, les portails destinés aux employés, les points de terminaison VPN et les interfaces de gestion des bases de données apparaissent souvent directement dans la liste des enregistrements.
• Architecture de messagerie et de routage : Les enregistrements MX et les adresses IP des serveurs de messagerie correspondants révèlent la topologie de filtrage des e-mails d'une organisation, les étapes de routage et les services de distribution tiers.
• Données de vérification provenant de tiers : Les enregistrements TXT non audités contiennent souvent des jetons de vérification pour les plateformes cloud, les intégrations SaaS, les outils d'analyse, ainsi que des chaînes de vérification historiques qui fournissent des indications sur les dépendances de l'infrastructure interne.

Comment une fuite de transfert de zone favorise d'autres attaques

Les informations obtenues grâce à un transfert de zone ouvert servent de point de départ opérationnel à des attaques sophistiquées ultérieures :

• Prise de contrôle de sous-domaines : Les fichiers de zone contiennent souvent des enregistrements CNAME orphelins qui pointent vers des ressources cloud désaffectées, telles que des compartiments Amazon S3 abandonnés, des pages GitHub ou des instances Microsoft Azure. Disposant d’une liste complète de ces enregistrements CNAME, les attaquants peuvent s’emparer de la ressource orpheline chez le fournisseur tiers et diffuser du contenu non autorisé sous le domaine vérifié de la victime.
• Spear phishing et ingénierie sociale : La découverte des conventions de nommage des serveurs internes, des adresses des portails destinés aux employés et des relations avec les fournisseurs permet aux attaquants de créer des leurres d’ingénierie sociale extrêmement crédibles. Lorsque les acteurs malveillants mentionnent de véritables noms d’hôtes internes dans un e-mail ciblé, les destinataires sont nettement plus enclins à faire confiance à ce message. Pour découvrir comment les attaquants exploitent les renseignements sur l’infrastructure afin de collecter de manière ciblée des identifiants, consultez notre analyse détaillée de hameçonnage ciblé.
• Surfaces d'attaque élargies : Les transferts de zone exposent fréquemment les schémas d'adressage IP internes lorsque des réseaux privés sont accidentellement fusionnés avec des zones publiques. Cela fournit aux attaquants les informations de routage nécessaires pour sonder les pare-feu périmétriques et cibler les interfaces d'administration internes.

De plus, bien que les transferts de zone ne manipulent pas en eux-mêmes le trafic, la compréhension de la topologie de mise en cache et de routage d’une entreprise peut faciliter des attaques secondaires telles que l'empoisonnement du cache DNS.

Comment vérifier si votre nom de domaine autorise les transferts de zone

Les administrateurs de sécurité doivent vérifier si les serveurs de noms faisant autorité autorisent les transferts de zone non autorisés. L'objectif est de s'assurer que les requêtes externes demandant des copies complètes de la zone reçoivent un refus explicite plutôt que l'intégralité des enregistrements.

Les administrateurs évaluent cette configuration en lançant une requête AXFR depuis un emplacement réseau externe non fiable, adressée à chaque serveur de noms faisant autorité répertorié dans les enregistrements NS du domaine :

• Comportement sécurisé: Le serveur de noms rejette immédiatement la requête, en renvoyant un statut REFUSED ou SERVFAIL. Aucun enregistrement de zone n'est transmis.
• Comportement vulnérable : Le serveur de noms accepte la connexion, accuse réception de la requête AXFR et renvoie la liste complète des enregistrements de ressources du domaine.

Au-delà des contrôles ponctuels réguliers, les environnements d'entreprise tirent parti d'une surveillance automatisée. Les contrôles automatisés de configuration permettent de détecter les cas où les mises à jour des serveurs de noms suppriment par inadvertance les restrictions de transfert. 

PowerDMARC intègre des contrôles automatisés de l'exposition AXFR au sein de son suite de surveillance de la sécurité DNS , alertant les administrateurs dès qu'un serveur faisant autorité commence à répondre à des demandes publiques de transfert de zone.

Comment sécuriser les transferts de zones DNS

Pour protéger votre domaine contre les transferts de zone non autorisés, il est nécessaire de mettre en place des restrictions d'accès strictes et des contrôles cryptographiques modernes. Conformément aux directives officielles du NIST en matière de sécurité DNS permet d'établir une base de référence fiable pour l'intégrité du domaine.

Mettez en place les mesures de sécurité suivantes au sein de votre infrastructure DNS :

1. Limiter les transferts par adresse IP: n’autorisez jamais les requêtes AXFR ou IXFR sans restriction. Déclarez explicitement les adresses IP des serveurs de noms secondaires autorisés dans vos blocs de configuration de serveurs de noms (par exemple, via la directive « allow-transfer » de BIND), et rejetez toutes les requêtes provenant de sources ne figurant pas sur cette liste blanche.
2. Authentification via TSIG : La restriction d'accès basée uniquement sur l'adresse IP offre une protection de base, mais les adresses IP peuvent être usurpées dans certaines topologies de réseau. Mettez en œuvre les signatures de transaction (TSIG) pour authentifier les communications entre les serveurs de noms à l'aide de secrets cryptographiques partagés.
3. Désactiver les transferts sur les systèmes autonomes : Si votre domaine repose sur un seul serveur de noms ou utilise un fournisseur DNS géré moderne qui se synchronise via des interfaces API propriétaires, désactivez complètement les transferts de zone.
4. Mettre en place un DNS à horizon divisé : Gérez des fichiers de zone distincts pour les réseaux d'entreprise internes et les services publics externes. Les noms d'hôtes internes, les environnements de test et les sous-domaines de préproduction ne doivent jamais figurer dans un fichier de zone accessible au public.
5. Veillez à ce que les démons de serveurs de noms soient à jour : Les failles des logiciels DNS peuvent permettre à des attaquants de contourner les règles ACL ou de provoquer l'épuisement des ressources. Utilisez des versions mises à jour et corrigées des logiciels serveurs tels que BIND, PowerDNS, Knot DNS ou NSD afin de minimiser l'exposition aux vulnérabilités « zero-day » et aux aux attaques par amplification DNS.
6. Journalisation et alertes concernant les demandes de transfert : Surveillez les journaux de requêtes des serveurs de noms afin de détecter les requêtes AXFR ou IXFR non sollicitées. Des tentatives répétées de transfert provenant d'adresses IP inconnues indiquent souvent une opération de reconnaissance menée par un adversaire.
7. Vérifiez régulièrement vos fichiers de zone : Vérifiez régulièrement vos fichiers de zone afin d'identifier et de supprimer les enregistrements obsolètes, en particulier les entrées CNAME périmées pointant vers des ressources d'hébergement cloud tierces dont la validité a expiré.

Authentification des transferts avec TSIG et chiffrement avec XoT

Les signatures de transaction (TSIG), normalisées dans la RFC 2845 et révisées dans la RFC 8945, ajoutent une authentification cryptographique à la messagerie DNS. Le protocole TSIG repose sur des secrets partagés symétriques établis entre les serveurs de noms principal et secondaire.

Une fois configuré, le serveur de noms secondaire signe sa requête AXFR ou IXFR à l'aide d'un hachage cryptographique dérivé de la clé partagée et de l'horodatage actuel. Le serveur de noms principal valide la signature à l'aide de sa propre clé. Si la signature correspond et se situe dans une plage de temps acceptable, le transfert se poursuit ; si la clé est manquante ou non valide, le serveur principal rejette la connexion.

Si le protocole TSIG permet de vérifier l'identité et de garantir l'intégrité des données, il ne crypte toutefois pas le contenu de la zone lui-même pendant son transfert. Afin de pallier cette lacune en matière de confidentialité, l'Internet Engineering Task Force (IETF) a publié la RFC 9103, qui spécifie le transfert de zone DNS via TLS (XoT). Le protocole XoT encapsule les sessions AXFR et IXFR dans un tunnel TLS ( Transport Layer Security ) chiffré, empêchant ainsi l'écoute clandestine, l'inspection de type « homme du milieu » et la falsification sur les réseaux de transit.

Suivi de l'exposition au transfert de zone avec PowerDMARC

La sécurisation de l'infrastructure des serveurs de noms nécessite à la fois des configurations défensives des serveurs et une observabilité externe continue. Alors que les équipes chargées de l'infrastructure gèrent les listes d'accès aux zones, les analystes en sécurité ont besoin d'une visibilité continue pour s'assurer que des erreurs administratives ou des migrations vers le cloud n'exposent pas discrètement les enregistrements.

PowerDMARC intègre une fonctionnalité dédiée à la détection des vulnérabilités AXFR dans ses solutions de sécurité DNS de pointe .

Conçu comme une plateforme de surveillance des enregistrements DNS externes et de conformité en matière de sécurité, plutôt que comme un proxy de filtrage en ligne ou un pare-feu, le service « DNS Security Monitoring & Compliance » de PowerDMARC effectue des contrôles automatisés sur l’ensemble de vos serveurs de noms faisant autorité :

• Contrôles d'exposition AXFR : Teste en continu les serveurs de noms faisant autorité depuis des emplacements externes afin de vérifier que les transferts de zone non autorisés sont bien refusés.
• Journalisation des audits relatifs aux fuites de zone : Signale et consigne instantanément les cas où un serveur de noms secondaire ou principal autorise par erreur des transferts de données AXFR.
• Détection des modifications apportées aux enregistrements : Surveille les mouvements de numéros de série SOA et suit les ajouts, modifications ou suppressions dans les enregistrements de ressources publiques.
• Vérification de la synchronisation des serveurs de noms : Vérifie que les serveurs de noms secondaires contiennent des enregistrements identiques et synchronisés par rapport aux autorités principales.
• DNSSEC et négligence concernant les enregistrements CNAME orphelins : Alerte les administrateurs en cas de chaînes DNSSEC rompues et identifie les enregistrements CNAME obsolètes avant qu'ils ne puissent être exploités pour prendre le contrôle de sous-domaines.

En associant des contrôles d'accès stricts aux serveurs de noms à une surveillance automatisée et continue des enregistrements, vous garantissez que votre topologie DNS reste confidentielle, résiliente et conforme aux normes de sécurité de l'entreprise.

Foire aux questions

À quoi sert un transfert de zone DNS ?

Un transfert de zone DNS permet de répliquer les données de zone depuis un serveur de noms faisant autorité (primaire) vers des serveurs de noms secondaires via le port TCP 53. Cette réplication garantit une haute disponibilité, un équilibrage de charge et une tolérance aux pannes sur les réseaux distribués, évitant ainsi les échecs de résolution de domaine si le serveur primaire venait à être indisponible.

Quelle est la différence entre l'AXFR et l'IXFR ?

AXFR effectue un transfert complet de zone, en transmettant l'intégralité du fichier de zone et tous les enregistrements de ressources associés, qu'il y ait eu ou non des modifications. IXFR effectue un transfert incrémental, en transmettant uniquement les ajouts et suppressions d'enregistrements spécifiques survenus depuis le dernier numéro de série synchronisé du serveur secondaire.

Un transfert de zone DNS constitue-t-il une attaque ?

Non, un transfert de zone est un mécanisme administratif standard défini par les normes Internet. Cela ne constitue un incident de sécurité que lorsqu’un serveur de noms faisant autorité est mal configuré, de sorte qu’il autorise des transferts AXFR ouverts et sans restriction vers des clients publics non autorisés, permettant ainsi à des attaquants de télécharger la carte complète de l’infrastructure de domaine d’une organisation.

Quel port est utilisé pour un transfert de zone ?

Les transferts de zone utilisent le port TCP 53. Alors que les requêtes DNS récursives standard s'appuient sur le port UDP 53 pour des raisons de rapidité, les transferts de zone nécessitent le protocole TCP afin d'établir une connexion fiable, capable de transmettre des enregistrements de zone volumineux, composés de plusieurs paquets, sans troncature des données ni perte de paquets.

Qu'est-ce que le TSIG et comment assure-t-il la sécurité des transferts de zone ?

Le TSIG (Transaction Signatures) est un mécanisme d'authentification DNS défini dans la RFC 8945. Il utilise des clés cryptographiques symétriques partagées pour signer les requêtes et les réponses de transfert de zone, garantissant ainsi que les serveurs de noms principaux et secondaires s'authentifient mutuellement et vérifient l'intégrité des données avant de transmettre les enregistrements de zone.

Les fournisseurs de services DNS gérés autorisent-ils les transferts de zone ?

La plupart des fournisseurs modernes de services DNS gérés dans le cloud désactivent par défaut les transferts AXFR publics traditionnels, et utilisent des API propriétaires ainsi que des réseaux anycast internes pour répliquer les enregistrements. Cependant, certains fournisseurs de services cloud proposent des configurations AXFR sécurisées et optionnelles afin de prendre en charge les environnements hybrides lors de la connexion de serveurs de noms secondaires externes personnalisés.

En conclusion

Les transferts de zone DNS sont essentiels pour garantir la disponibilité continue du réseau et la fiabilité de la résolution des noms de domaine. Cependant, s'ils ne font l'objet d'aucune restriction, ils constituent une porte ouverte sur votre réseau d'entreprise, offrant aux acteurs malveillants un inventaire détaillé des sous-domaines, des portails d'administration et des environnements de test oubliés.

La sécurisation des transferts de zone ne nécessite pas de renoncer à la redondance. En limitant les transferts aux adresses IP secondaires autorisées, en authentifiant les échanges à l'aide de clés TSIG, en chiffrant les sessions avec XoT et en veillant au respect d'une hygiène rigoureuse des zones, vous pouvez protéger vos ressources de nommage sans compromettre leur disponibilité.

Faites dès aujourd'hui le premier pas vers la sécurisation de votre infrastructure de domaine : utilisez notre analyseur de domaine gratuit pour vérifier l'état de votre DNS public, ou mettez en place la surveillance de sécurité DNS PowerDMARC afin de protéger votre infrastructure contre toute exposition non autorisée.