Transfert de zone DNS : récupérer tous les enregistrements d'un domaine

Un serveur DNS mal configuré peut livrer la totalité des enregistrements d’un domaine à n’importe quel client. Cette faiblesse, le transfert de zone non restreint, transforme une opération d’administration légitime en source de reconnaissance : sous-domaines, adresses internes, serveurs de messagerie, tout est exposé d’un coup.

Le mécanisme du transfert de zone

Un domaine est servi par plusieurs serveurs DNS pour la redondance : un serveur maître (primaire) détient la version de référence de la zone, et des serveurs esclaves (secondaires) en tiennent une copie. Pour synchroniser cette copie, un secondaire demande au primaire un transfert de zone, l’opération AXFR (Asynchronous Full Transfer Zone), qui renvoie l’ensemble des enregistrements.

Cette réplication est nécessaire entre serveurs autorisés. Le problème surgit quand le primaire accepte une requête AXFR de n’importe qui, et pas seulement de ses secondaires déclarés.

Exploiter avec dig

dig demande explicitement un transfert de zone avec le type de requête axfr :

dig axfr @ns1.exemple.fr exemple.fr

Quand le service DNS écoute sur un port non standard, on le précise avec -p :

dig axfr @ns1.exemple.fr -p 5353 exemple.fr

Décorticage des paramètres :

axfr : le type de requête, qui demande le transfert de zone complet.
@ns1.exemple.fr : le serveur DNS cible interrogé.
-p 5353 : le port à utiliser, ici non standard, au lieu du port DNS habituel (53).
exemple.fr : le nom de la zone à transférer.

Si le serveur autorise le transfert, la réponse liste tous les enregistrements de la zone :

exemple.fr.        3600  IN  SOA   ns1.exemple.fr. admin.exemple.fr. 2025011501 ...
exemple.fr.        3600  IN  NS    ns1.exemple.fr.
exemple.fr.        3600  IN  MX    10 mail.exemple.fr.
www.exemple.fr.    3600  IN  A     203.0.113.10
mail.exemple.fr.   3600  IN  A     203.0.113.20
vpn.exemple.fr.    3600  IN  A     10.0.0.5
dev.exemple.fr.    3600  IN  A     10.0.0.12

Ce que la zone révèle

Le contenu d’une zone est une carte de l’infrastructure : sous-domaines qu’aucune énumération publique n’aurait trouvés (dev, vpn, admin, backup), adresses IP internes exposées par mégarde, serveurs de messagerie, enregistrements TXT porteurs d’indices. Là où un attaquant devrait deviner les sous-domaines un à un, un transfert réussi lui remet l’annuaire complet.

D’autres outils exploitent la même faille :

# host, en une commande
host -l exemple.fr ns1.exemple.fr

# dnsrecon, avec détection automatique
dnsrecon -d exemple.fr -t axfr

Remédiation

Restreindre le transfert aux secondaires autorisés

Le transfert de zone ne doit être permis qu’aux serveurs secondaires déclarés. Sur BIND, la directive allow-transfer limite la liste des clients autorisés.

zone "exemple.fr" {
    type master;
    file "/etc/bind/db.exemple.fr";
    allow-transfer { 203.0.113.20; };   # uniquement le secondaire légitime
};

Par défaut, il est prudent de refuser tout transfert au niveau global, puis de n’ouvrir que là où c’est nécessaire :

options {
    allow-transfer { none; };
};

Authentifier les transferts avec TSIG

Une restriction par adresse IP se contourne par usurpation. TSIG (Transaction SIGnature) signe les échanges entre primaire et secondaire avec une clé partagée, ce qui authentifie le demandeur indépendamment de son adresse.

key "transfer-key" {
    algorithm hmac-sha256;
    secret "<clé_partagée_en_base64>";
};

zone "exemple.fr" {
    allow-transfer { key "transfer-key"; };
};

À retenir

Le transfert de zone AXFR est une fonction légitime de réplication entre serveurs DNS, mais laissée ouverte à tous, elle expose l’annuaire complet d’un domaine en une requête dig. La reconnaissance qu’elle offre, sous-domaines et adresses internes compris, en fait une des premières vérifications d’un audit. La parade est de restreindre allow-transfer aux seuls secondaires déclarés et d’authentifier ces transferts par TSIG.