Statut AXFR (transfert de zone) et implications de sécurité

1. Qu’est-ce qu’AXFR ?

AXFR (Authoritative Transfer) est le mécanisme historique de transfert complet de zone en DNS. Un serveur secondaire se connecte au primaire et demande une copie intégrale de la zone.

Pourquoi AXFR existe

Avant les API modernes et les fournisseurs DNS managés, AXFR était la méthode standard pour répliquer les données DNS. Il reste très utilisé aujourd’hui entre serveurs de confiance, notamment dans les infrastructures auto-hébergées.

À quoi ressemble un AXFR en pratique

Si un AXFR est accepté, le client reçoit la liste complète des enregistrements de la zone : A, AAAA, MX, TXT, SRV, sous-domaines internes, etc. Pour un attaquant, c’est une source de renseignements extrêmement riche.

2. Comment DNSprobe teste AXFR

DNSprobe réalise un test AXFR léger depuis son IP publique afin d’observer le comportement de vos serveurs de noms autoritaires.

• Il découvre d’abord les enregistrements NS autoritaires de votre domaine.
• Il tente ensuite un transfert complet de zone (AXFR) vers chaque serveur, en TCP.
• Pour chaque serveur, DNSprobe indique si la requête est refusée, partiellement répondue ou pleinement acceptée, et liste les serveurs testés dans le rapport.

Le test ne stocke ni n’affiche le contenu détaillé de votre zone. Il a uniquement besoin de savoir si le transfert est accepté ou refusé.

3. Risques de sécurité d’un AXFR ouvert

Laisser AXFR ouvert au monde entier transforme votre zone DNS en inventaire téléchargeable de votre infrastructure.

• Les attaquants peuvent énumérer tous vos noms d’hôtes en une seule requête au lieu de les deviner par des scans lents et bruyants.
• Les systèmes internes ou discrets (portails d’administration, environnements de staging, MX de secours, passerelles VPN, imprimantes, etc.) sont révélés par leur nom, même s’ils ne sont jamais référencés publiquement.
• Les enregistrements d’e-mail, de VoIP ou d’annuaire (MX, SRV, TXT, _sip, _ldap, etc.) donnent des indices sur les logiciels et plateformes que vous utilisez.
• Combinée à d’autres sources, une copie complète de la zone accélère fortement la phase de reconnaissance et facilite les attaques ciblées.

Pour les zones publiques en production, la règle saine est simple : AXFR doit être refusé aux clients arbitraires et limité aux seuls serveurs secondaires de confiance.

4. Dans quels cas AXFR est-il utile ?

Malgré ses risques, AXFR reste un outil valable lorsqu’il est utilisé dans un environnement contrôlé.

• Synchronisation des enregistrements entre un serveur DNS primaire et un ou plusieurs secondaires.
• Migration d’une zone d’une plateforme DNS vers une autre dans un contexte privé ou administratif.
• Dépannage de problèmes de réplication dans un DNS auto-hébergé lorsque vous contrôlez explicitement les deux extrémités du transfert.

Dans tous ces cas, AXFR doit être limité à des adresses IP connues et idéalement protégé par des clés TSIG.

5. Comment sécuriser AXFR sur vos serveurs

Si vous avez besoin d’AXFR, l’objectif n’est pas de le supprimer, mais de faire en sorte que seuls vos serveurs secondaires autorisés puissent l’utiliser.

Restreindre AXFR avec des ACL IP

La plupart des logiciels DNS (BIND, Knot, PowerDNS, NSD, etc.) permettent de définir une ACL listant les adresses IP autorisées à effectuer des transferts de zone. Toute requête AXFR provenant d’une IP extérieure à cette liste doit être refusée.

Protéger les transferts avec TSIG

TSIG (Transaction SIGnature) utilise une clé secrète partagée pour authentifier les requêtes AXFR et IXFR. Combiné aux ACL IP, cela empêche un serveur non autorisé de se faire passer pour un secondaire.

Recommandations de configuration

• Désactiver AXFR par défaut pour les clients publics ; ne l’activer que sur les zones qui nécessitent des transferts.
• Limiter AXFR à un nombre restreint d’adresses IP de confiance (vos secondaires) et maintenir cette liste à jour.
• Utiliser TSIG dès que possible afin qu’une simple usurpation d’IP ne suffise pas à obtenir une copie de votre zone.

6. Interpréter les résultats AXFR de DNSprobe

Le tableau ci-dessous résume comment interpréter les résultats AXFR les plus fréquents dans DNSprobe.

Gardez à l’esprit que DNSprobe teste AXFR du point de vue d’un client externe. Un AXFR refusé ne signifie pas que votre réplication interne est cassée – cela indique simplement que les transferts de zone ne sont pas exposés au public, ce qui est généralement souhaitable.

7. Exemple de réponse AXFR non bloquée

Ci-dessous, un exemple simplifié de ce à quoi peut ressembler un transfert de zone AXFR complet lorsque un serveur de noms accepte à tort les requêtes AXFR depuis Internet pour example.com.

                $ dig AXFR example.com @ns1.example.com

                ; <<>> DiG 9.18.0 <<>> AXFR example.com @ns1.example.com
                ;; global options: +cmd
                example.com.          3600 IN SOA ns1.example.com. hostmaster.example.com. 2025010101 7200 3600 1209600 3600
                example.com.          3600 IN NS  ns1.example.com.
                example.com.          3600 IN NS  ns2.example.com.

                ; --- Public web & mail records ---
                example.com.          3600 IN MX 10 mail.example.com.
                www.example.com.      3600 IN A   192.0.2.10
                mail.example.com.     3600 IN A   192.0.2.20
                cdn.example.com.      3600 IN CNAME cdn.provider.example.net.

                ; --- TXT / SPF / DMARC / DKIM ---
                example.com.          3600 IN TXT "v=spf1 ip4:192.0.2.20 include:_spf.mailprovider.com ~all"
                _dmarc.example.com.   3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
                dkim._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

                ; --- Internal / sensitive hosts accidentally exposed ---
                intranet.example.com.                   3600 IN A   10.0.0.15
                vpn-gateway.example.com.                3600 IN A 10.0.0.20
                backup-nas.example.com.                 3600 IN A 10.0.0.30
                dev-app01.example.com.                  3600 IN A 192.0.2.50
                my-super-secret-service.example.com.    3600 IN A 192.0.2.100

                ; --- Service discovery (SRV) records ---
                _ldap._tcp.example.com.   3600 IN SRV 0 0 389 dc01.example.com.
                _sip._tcp.example.com.    3600 IN SRV 0 0 5060 sip01.example.com.

                ; ...
                example.com.          3600 IN SOA ns1.example.com. hostmaster.example.com. 2025010101 7200 3600 1209600 3600
                ;; Query time: 45 msec
                ;; X records transferred in Y seconds
        

En réalité, les zones sont généralement beaucoup plus longues et peuvent contenir des noms d’hôtes sensibles (passerelles VPN, intranet, environnements de test, etc.).
Si vous voyez un dump similaire pour votre propre domaine, considérez cela comme un risque élevé et restreignez immédiatement l’AXFR uniquement à vos serveurs secondaires de confiance.

8. Tester AXFR manuellement depuis votre terminal

Pour être totalement transparent, DNSprobe n’effectue que le même type de vérification AXFR que vous pouvez réaliser vous-même. Voici quelques exemples simples pour reproduire le test depuis votre propre poste.

Linux : avec dig (utilitaires BIND)

Sur la plupart des distributions Linux, la commande dig est fournie par le paquet d’utilitaires BIND (souvent nommé bind-utils, dnsutils ou similaire). La commande suivante tente un transfert complet de zone depuis ns1.example.com pour example.com :

                dig @ns1.example.com example.com AXFR
                dig @ns1.example.com example.com AXFR +nocmd +noall +answer
        

macOS : avec dig et les outils intégrés

macOS inclut également la commande dig dans ses outils en ligne de commande. Ouvrez le Terminal et lancez la même commande AXFR que sous Linux. Si AXFR est refusé, vous verrez une réponse REFUSED ou NOTAUTH au lieu de la liste complète d’enregistrements.

                dig @ns1.example.com example.com AXFR
        

Windows : avec le client interactif nslookup

Sous Windows, l’ancien outil nslookup permet encore de lancer un AXFR. Démarrez nslookup depuis une invite de commandes, changez de serveur pour votre serveur de noms autoritaire, définissez le type de requête sur AXFR, puis demandez le nom de la zone comme ci-dessous.

                nslookup
        

                > server ns1.example.com
                > set type=AXFR
                > example.com
        

Important : ne lancez des tests AXFR que sur des domaines et des serveurs que vous êtes autorisé à auditer. Certains opérateurs peuvent considérer des tentatives AXFR répétées comme une activité suspecte.