BIND9 : Transferts de zones hors de contrôle — Verrouillez sans casser les DNS secondaires

Comment les transferts de zone cassent en conditions réelles

Les transferts de zone (AXFR pour complet, IXFR pour incrémental) sont censés être une réplication en arrière-plan ennuyeuse. Vous publiez une zone sur un ou plusieurs maîtres, vos secondaires tirent les mises à jour, les résolveurs interrogent le serveur faisant autorité qu’ils atteignent, et tout le monde respecte les TTL comme des adultes.

Puis vous introduisez l’un des accélérateurs classiques :

• ACL d’autorisation de transfert trop permissives (« allow-transfer { any; }; » l’équivalent DNS de laisser votre lecteur de badges en « mode démo »).
• NAT ou pare-feu avec des politiques asymétriques (NOTIFY passe, le transfert TCP ne passe pas ; ou inversement).
• Négligence sur le numéro de série (modifications manuelles sans incrémenter le serial ; ou DNS dynamique avec des maîtres cachés qui ne correspondent pas à vos hypothèses).
• Tempêtes de transfert (beaucoup de secondaires, rafraîchissement agressif, maîtres instables, ou une modification de config qui force un retraitement complet).
• Incohérences de vue (zones split-horizon, mais les identifiants/ACL de transfert ne concordent pas, donc les secondaires répliquent la mauvaise vue ou aucune).
• Dérive TSIG (mauvaise clé, mauvais algorithme, association « server » incorrecte, ou horloges suffisamment faussées pour invalider les messages signés).

Quand les transferts partent en vrille, vous n’avez pas seulement des « problèmes DNS ». Vous avez :

• Risque de disponibilité : des secondaires qui servent des données périmées pendant des incidents, provoquant des pannes partielles difficiles à déboguer.
• Risque de confidentialité : un AXFR divulgue des noms d’hôtes internes, la topologie des services et les conventions de nommage. Les attaquants adorent ça.
• Risque de capacité : les retries de transfert peuvent être un DDoS auto-infligé, surtout si vous avez beaucoup de zones ou des zones volumineuses (pensez aux enregistrements générés automatiquement).
• Risque de contrôle des changements : une modification « inoffensive » d’une ACL peut casser silencieusement la réplication et n’apparaître qu’après l’expiration des TTL et des caches.

Blague n°1 : DNS est le seul système où « gestion du numéro de série » est à la fois une stratégie de fiabilité et un élément d’intrigue.

Faits et contexte intéressants (pourquoi on en est arrivé là)

Un contexte court et concret importe parce que les comportements de BIND sont façonnés par des décennies de cicatrices opérationnelles.

1. AXFR précède la pensée moderne du « moindre privilège ». Les premières conceptions du DNS supposaient des serveurs coopérants ; l’idée du scan hostile pour récupérer des transferts est venue plus tard.
2. Les transferts de zone utilisent TCP. Les requêtes DNS régulières sont habituellement UDP, mais AXFR/IXFR utilisent TCP par conception pour déplacer beaucoup de données de façon fiable.
3. NOTIFY a été un ajout. À l’origine, les secondaires attendaient les timers de refresh ; NOTIFY (RFC 1996) a accéléré la propagation mais a introduit de nouveaux modes d’échec quand UDP 53 est filtré différemment de TCP 53.
4. IXFR existe pour éviter les transferts complets. Les transferts incrémentaux (RFC 1995) réduisent la bande passante et la charge, mais ils reposent sur des journaux/diff disponibles et une progression série correctement ordonnée.
5. TSIG est plus ancien que beaucoup ne le pensent. Transaction SIGnature (RFC 2845) est devenu l’outil pour authentifier des transferts sans la complexité de DNSSEC.
6. Les « views » de BIND ont été conçues pour le split-horizon. Puissantes, faciles à mal utiliser : votre ACL de transfert doit s’aligner sur la vue correcte, sinon vous répliquerez le mauvais jeu de réponses.
7. Les architectures à « master caché » sont devenues courantes pour réduire la surface d’attaque. Exposer seulement les secondaires sur Internet est une bonne chose — jusqu’à ce que vous oubliez que les secondaires doivent toujours atteindre le master sur TCP/53.
8. Le format des transferts et la sémantique SOA restent centraux. Malgré l’automatisation moderne, le serial SOA, refresh, retry, expire et le TTL négatif demeurent les réglages qui pilotent le comportement.

Un modèle mental utile : AXFR/IXFR/NOTIFY et qui initie quoi

Primaire vs secondaire : la direction du flux

Dans le DNS classique primaire/secondaire, le secondaire initie le transfert. Il se connecte au primaire (TCP 53), demande IXFR ou AXFR, et stocke une copie locale. Cela signifie que votre posture de sécurité devrait être : le primaire n’autorise les transferts qu’aux secondaires connus, et les secondaires ne parlent qu’aux primaires connus.

NOTIFY est la « sonnette », pas le camion de livraison

NOTIFY est un signal rapide du primaire au secondaire : « mon serial a changé ; allez vérifier. » Il est généralement UDP. Le transfert réel est le travail lourd et se fait sur TCP. Ainsi votre pare-feu doit autoriser les deux directions de façon appropriée, et votre configuration BIND doit éviter d’accepter des NOTIFY de n’importe qui.

IXFR n’est pas magique

IXFR ne fonctionne que quand le primaire peut fournir les changements incrémentaux. Dans BIND, cela dépend généralement d’un journal de zone. Perdez le journal (ou le désactivez), et le secondaire reviendra souvent à AXFR. Si votre zone est volumineuse, ce fallback est coûteux.

Une citation pour rester honnête

L’espoir n’est pas une stratégie. — Gene Kranz

Modèle de menace : contre quoi vous vous défendez

Verrouiller les transferts n’est pas de la paranoïa ; c’est de l’hygiène. Voici l’ensemble réaliste des problèmes :

• Tentatives non autorisées d’AXFR/IXFR pour énumérer des noms et services internes.
• Hôtes internes mal configurés qui se comportent accidentellement comme des secondaires et martèlent le primaire de retries.
• Secondaire compromis utilisé comme pivot de confiance — toujours autorisé par l’ACL du primaire.
• Réflection des erreurs opérationnelles : quelqu’un a ouvert les transferts « temporairement » pour réparer un secondaire, puis l’a oublié.
• Épuisement des ressources : concurrence de transferts, sockets TCP, I/O disque pour écritures de zone, churn de journaux et inondation des logs.

Le but n’est pas « pas de transferts ». Le but est seulement les bons transferts, au bon moment, depuis les bons hôtes, avec authentification et limites raisonnables.

Mode opératoire de diagnostic rapide

Quand les secondaires ne se mettent pas à jour ou que les transferts fondent vos serveurs, vous avez besoin d’un ordre d’opérations impitoyable. Ne commencez pas par éditer named.conf en panique. Commencez par trouver le goulet d’étranglement.

Premier point : prouver la connectivité de base et le protocole (TCP vs UDP)

• Le secondaire peut-il atteindre le primaire sur TCP 53 ?
• Les NOTIFY arrivent-ils (UDP 53) ?
• Y a-t-il un middlebox qui fait de « l’inspection DNS utile » ?

Second point : prouver l’autorisation et l’identité

• Le primaire autorise-t-il le transfert vers l(es) IP(s) du secondaire ?
• TSIG est-il configuré des deux côtés, et l’utilisez-vous réellement pour les transferts ?
• Traitez-vous la bonne vue ?

Troisième point : prouver l’état et le mouvement du serial

• Le serial SOA du primaire correspond-il à ce que vous attendez ?
• Le secondaire est-il bloqué parce qu’il ne peut pas IXFR et enchaîne les échecs AXFR ?
• Le secondaire sert-il des données périmées parce qu’il n’a jamais terminé un transfert ?

Quatrième point : isoler les contraintes de capacité

• CPU au maximum ? Probablement signature DNSSEC, tempêtes de logs, ou trop de transferts concurrents.
• I/O disque saturé ? Écritures de fichiers de zone/journaux, ou un nombre pathologique de petites mises à jour.
• Réseau saturé ? Transferts complets, retries et trop de secondaires se rafraîchissant en même temps.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici de vrais coups d’opérateur : commandes à exécuter, ce que la sortie vous indique, et la décision suivante. Adaptez noms d’hôtes et chemins à votre environnement, mais gardez la logique.

Task 1: Confirm which server is primary for a zone (from anywhere)

cr0x@server:~$ dig +norecurse SOA example.com @ns1.example.net
;; ANSWER SECTION:
example.com.     3600  IN  SOA  ns1.example.net. hostmaster.example.com. 2026020401 1200 300 1209600 300

Ce que cela signifie : Le MNAME du SOA est ns1.example.net. Le serial est 2026020401.

Décision : C’est l’autorité depuis laquelle vous devriez transférer (sauf si vous utilisez des masters cachés). Si votre « primaire » n’apparaît pas, vous êtes dans un design multi-master ou master-caché — confirmez la liste de masters prévue.

Task 2: Check if AXFR is (accidentally) open to the world

cr0x@server:~$ dig AXFR example.com @ns1.example.net
; Transfer failed.

Ce que cela signifie : Bon signe. Le serveur a refusé ou vous n’êtes pas autorisé.

Décision : Si AXFR réussit depuis un hôte non fiable, considérez cela comme un incident de sécurité : resserrez allow-transfer, ajoutez TSIG, et réfléchissez si le contenu de la zone est sensible.

Task 3: Test transfer from a known secondary and verify TSIG works

cr0x@server:~$ dig AXFR example.com @ns1.example.net -y transfer-key:7b3Nq9hR7oR6Zp3kVvQb8w==
; (1 server found)
example.com.     3600 IN SOA ns1.example.net. hostmaster.example.com. 2026020401 1200 300 1209600 300
example.com.     3600 IN NS  ns1.example.net.
example.com.     3600 IN NS  ns2.example.net.
www.example.com. 300  IN A   203.0.113.10
example.com.     3600 IN SOA ns1.example.net. hostmaster.example.com. 2026020401 1200 300 1209600 300
;; Query time: 45 msec
;; XFR size: 28 records (messages 1, bytes 2150)

Ce que cela signifie : Le transfert a réussi avec la clé TSIG. Vous avez vu le SOA de début et de fin, et le nombre d’enregistrements.

Décision : Si vous ne pouvez transférer qu’avec TSIG, vous êtes sur la bonne voie. Si cela réussit sans TSIG aussi, vous avez encore un problème d’ACL.

Task 4: Verify TCP 53 is reachable (because AXFR/IXFR are TCP)

cr0x@server:~$ nc -vz ns1.example.net 53
Connection to ns1.example.net 53 port [tcp/domain] succeeded!

Ce que cela signifie : Le chemin TCP existe.

Décision : Si cela échoue mais que les requêtes UDP fonctionnent, corrigez le pare-feu/groupes de sécurité. NOTIFY peut vous induire en erreur en vous faisant croire que « DNS est ouvert » alors que les transferts ne le sont pas.

Task 5: On the primary, check what BIND thinks is happening with the zone

cr0x@server:~$ sudo rndc zonestatus example.com
name: example.com
type: master
files: /var/cache/bind/db.example.com
serial: 2026020401
nodes: 1421
last loaded: Tue, 04 Feb 2026 08:12:22 GMT
secure: no
dynamic: no

Ce que cela signifie : Le maître a le serial 2026020401 chargé depuis un fichier spécifique. Ce n’est pas dynamique.

Décision : Si vous attendiez des mises à jour dynamiques, votre modèle de déploiement vous trompe. Si le serial ne correspond pas à votre fichier, vous éditez peut-être le mauvais fichier ou utilisez inline-signing ou un master caché.

Task 6: On the secondary, verify whether it’s actually slaving the right master

cr0x@server:~$ sudo rndc zonestatus example.com
name: example.com
type: slave
masters: 203.0.113.11 port 53
serial: 2026020309
last loaded: Mon, 03 Feb 2026 19:41:03 GMT
next refresh: Tue, 04 Feb 2026 08:01:03 GMT

Ce que cela signifie : Le secondaire est en retard (serial 2026020309 vs primaire 2026020401). Il croit que le master est 203.0.113.11.

Décision : Confirmez que cette IP est correcte (les schémas de master caché piègent souvent). Si elle est incorrecte, corrigez la liste masters. Si elle est correcte, vous dépannez un problème d’auth/reachabilité/transfert.

Task 7: Force the secondary to re-check and pull (controlled nudge)

cr0x@server:~$ sudo rndc refresh example.com
zone refresh queued

Ce que cela signifie : BIND va tenter de rafraîchir ; ce n’est pas une garantie de succès.

Décision : Surveillez immédiatement les logs pour les tentatives de transfert. Si le refresh ne fait rien, vous avez peut-être une incohérence de vue ou la zone n’est pas chargée dans cette instance.

Task 8: Tail logs specifically for transfer messages

cr0x@server:~$ sudo journalctl -u bind9 -n 50 --no-pager
Feb 04 08:22:10 ns2 named[2143]: zone example.com/IN: refresh: retry limit reached
Feb 04 08:22:10 ns2 named[2143]: zone example.com/IN: Transfer started.
Feb 04 08:22:10 ns2 named[2143]: transfer of 'example.com/IN' from 203.0.113.11#53: connected using 203.0.113.22#47922
Feb 04 08:22:10 ns2 named[2143]: transfer of 'example.com/IN' from 203.0.113.11#53: failed while receiving responses: REFUSED

Ce que cela signifie : Le primaire refuse le transfert. C’est presque toujours allow-transfer, un mismatch TSIG, ou une mismatch de vue sur le master.

Décision : Corrigez l’autorisation sur le primaire (et soyez explicite). Ne « permettez temporairement any; » puis oubliez.

Task 9: Confirm the master’s allow-transfer posture by inspecting config

cr0x@server:~$ sudo named-checkconf -p | sed -n '/zone "example.com"/,/};/p'
zone "example.com" {
	type master;
	file "/var/cache/bind/db.example.com";
	allow-transfer { key transfer-key; 203.0.113.22; };
	also-notify { 203.0.113.22; };
};

Ce que cela signifie : Cette zone autorise les transferts soit depuis un client authentifié TSIG utilisant transfer-key, soit depuis l’IP 203.0.113.22.

Décision : Préférez « key-only » pour les transferts sauf raison spécifique d’autoriser les IP seules. Si vous conservez des IP, gardez l’ACL serrée et auditable.

Task 10: Validate zone file integrity before blaming networking

cr0x@server:~$ sudo named-checkzone example.com /var/cache/bind/db.example.com
zone example.com/IN: loaded serial 2026020401
OK

Ce que cela signifie : La zone se parse correctement et le serial est bien celui attendu.

Décision : Si cela échoue, corrigez d’abord le fichier de zone. Une zone cassée peut empêcher les chargements, empêcher les transferts, ou faire boucler les retries des secondaires indéfiniment.

Task 11: Check for transfer concurrency and whether you’re choking yourself

cr0x@server:~$ sudo rndc status
version: BIND 9.18.24-1ubuntu1.4-Ubuntu (Extended Support Version) <id:...>
running on ns1: Linux x86_64 5.15.0-97-generic
boot time: Tue, 04 Feb 2026 07:45:10 GMT
last configured: Tue, 04 Feb 2026 08:10:03 GMT
current serial: 2026020401
xfrouts running: 12
xfers running: 0

Ce que cela signifie : xfrouts running montre les transferts sortants (maître envoyant). Si ce nombre est élevé, vous pourriez être en tempête de transferts ou en train d’être sondé.

Décision : Si les transferts sortants sont anormalement élevés, vérifiez qui se connecte et si vos ACL sont trop ouvertes. Envisagez aussi d’ajuster transfers-out et consorts (avec prudence).

Task 12: Identify who is connecting to TCP/53 on the primary

cr0x@server:~$ sudo ss -tnp 'sport = :53' | head
State  Recv-Q Send-Q Local Address:Port Peer Address:Port  Process
ESTAB  0      0      203.0.113.11:53  203.0.113.22:47922 users:(("named",pid=2143,fd=42))
ESTAB  0      0      203.0.113.11:53  198.51.100.77:51244 users:(("named",pid=2143,fd=51))
ESTAB  0      0      203.0.113.11:53  198.51.100.88:51310 users:(("named",pid=2143,fd=63))

Ce que cela signifie : Vous avez des connexions TCP établies vers le port 53 depuis plusieurs pairs. Un seul d’entre eux est votre secondaire connu.

Décision : Si vous voyez des IP Internet aléatoires, vous êtes scanné ou vous avez laissé les transferts ouverts. Verrouillez allow-transfer et envisagez de filtrer TCP/53 vers les secondaires de confiance seulement (si l’architecture le permet).

Task 13: Prove NOTIFY is accepted only from the right hosts

cr0x@server:~$ sudo named-checkconf -p | sed -n '/options {/,/};/p' | sed -n '1,80p'
options {
	directory "/var/cache/bind";
	allow-notify { 203.0.113.11; };
	notify yes;
};

Ce que cela signifie : Le serveur restreint les sources pouvant envoyer des NOTIFY.

Décision : Si allow-notify manque sur un secondaire, envisagez de l’ajouter. Sinon, n’importe qui peut sonner à la porte et vous faire gaspiller du CPU et des logs.

Task 14: Confirm the secondary is serving the updated serial (client-side reality check)

cr0x@server:~$ dig +norecurse SOA example.com @ns2.example.net
;; ANSWER SECTION:
example.com.     3600  IN  SOA  ns1.example.net. hostmaster.example.com. 2026020401 1200 300 1209600 300

Ce que cela signifie : Le secondaire sert maintenant le nouveau serial.

Décision : S’il sert toujours un vieux serial, le transfert n’a pas abouti ou n’a pas été chargé. Revenez aux logs et au statut de la zone.

Durcir les transferts BIND9 sans casser les secondaires

Règle 1 : Définissez explicitement qui peut transférer, par zone

Commencez avec la posture que les transferts sont refusés par défaut. Puis ouvrez des trous précis. Dans BIND, c’est typiquement allow-transfer sur chaque zone maître (ou via une ACL partagée). Si vous le faites globalement dans options, vous oublierez tôt ou tard une zone qui devrait être traitée différemment.

Règle 2 : Préférez TSIG pour les transferts (et faites tourner les clés sérieusement)

Les ACL IP sont nécessaires mais pas suffisantes. Les IP changent. Le NAT ment. Et « c’est sur un réseau privé » est souvent la façon dont vous finissez par exporter une zone à une machine compromise dans votre périmètre.

Avec TSIG, vous obtenez l’authentification des messages. Vous avez toujours besoin de la politique d’IP, mais TSIG vous donne une identité au niveau DNS. Utilisez des algorithmes modernes (comme hmac-sha256) et gardez la distribution des clés contrôlée.

Règle 3 : N’oubliez pas la politique NOTIFY (c’est un levier de charge)

NOTIFY n’est pas une fuite de données, mais c’est un déclencheur de charge. Si n’importe qui peut l’envoyer, n’importe qui peut provoquer chez vos secondaires une logique de refresh et des tentatives de transfert. C’est un joli moyen de gaspiller CPU et espace de logs.

Règle 4 : Concevez pour des domaines de panne, pas juste « ça marche »

Deux architectures pratiques :

• Master caché : master(s) internes, secondaires publics seulement. Excellente posture de sécurité, mais nécessite une connectivité TCP/53 propre des secondaires vers les masters et des ACL soignées.
• Primaire public : un de vos serveurs publics est master. Routage plus simple, plus grande surface d’attaque, donc d’autant plus de raisons d’être strict sur les transferts.

Règle 5 : Surveillez le volume de transferts comme un SLO à part entière

Si vous ne mettez jamais en graphique les taux et les échecs de transferts, vous découvrirez un problème de transferts seulement après que les clients l’aient fait. Comptez :

• ratio IXFR vs AXFR réussis (une montée soudaine d’AXFR est une alarme)
• échecs de transfert (REFUSED, NOTAUTH, erreurs TSIG, timeouts)
• temps de chargement des zones et I/O wait

Règle 6 : Utilisez des limites — mais comme un chirurgien, pas comme un joueur

BIND dispose de paramètres comme transfers-out, transfers-in et serial-query-rate. Ils peuvent prévenir une débâcle, ou ils peuvent lentement affamer vos secondaires et vous faire servir des données périmées pendant des heures. Appliquez des limites après avoir compris le comportement normal des transferts et avoir de la visibilité.

Blague n°2 : Une limite de transfert trop basse, c’est comme un planning de salle de réunion — techniquement organisé, fonctionnellement une déni de service.

Trois mini-récits d’entreprise tirés des mines de transferts de zone

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait un master caché : master interne, deux secondaires publics. L’équipe réseau a supposé que « DNS c’est UDP 53 », parce que la plupart des gens vivent DNS comme des requêtes UDP rapides. Leurs règles de pare-feu autorisaient UDP/53 entrant vers les secondaires et autorisaient les secondaires à interroger le master via UDP/53 pour le « DNS ».

NOTIFY fonctionnait. Enfin, en partie. Le master envoyait NOTIFY, les secondaires le recevaient, et essayaient immédiatement de tirer un IXFR. Par TCP. Qui était bloqué. BIND a logué des timeouts de transfert, puis des retries, puis encore des retries. Rien ne s’est mis à jour.

La situation est restée invisible un moment parce que les TTL étaient longs et que les réponses en cache masquaient l’obsolescence. Finalement, une rotation de certificat a ajouté un nouvel enregistrement de validation. Certains résolveurs ont obtenu le nouvel enregistrement depuis la vue interne du master lors du dépannage, mais les secondaires publics ne le servaient jamais. Les validations externes échouaient de façon intermittente. L’équipe d’incident a connu la misère spéciale du « ça marche pour moi » avec le DNS.

Ils ont corrigé en autorisant TCP/53 des secondaires vers le master et en surveillant explicitement la dérive des serial SOA des secondaires. La conclusion du postmortem était douloureusement simple : ils avaient supposé que DNS signifiait UDP, et cette hypothèse a gouverné la production — jusqu’à ce qu’elle ne le fasse plus.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une plus grande organisation avait des centaines de zones. Les transferts faisaient du bruit, donc un ingénieur a tenté « d’optimiser » la charge en allongeant les timers de refresh et en réduisant le bruit des NOTIFY. L’idée : moins de refreshes, moins de transferts, moins de charge.

En régime stable, ça a marché. Les graphiques étaient plus calmes. Puis un bug de déploiement a poussé un mauvais fichier de zone sur le master : un enregistrement NS manquant dont certains résolveurs dépendaient. Ils ont rollbacké rapidement. Mais voici la morsure : beaucoup de secondaires n’avaient pas encore rafraîchi parce que les intervalles étaient maintenant longs. Une partie de la flotte servait la version cassée beaucoup plus longtemps que prévu.

Les clients subissaient une roulette d’informations selon le serveur faisant autorité qu’ils touchaient. Le support voyait des « échecs DNS sporadiques ». L’ingénierie voyait « c’est corrigé ». Les deux disaient vrai. C’est le genre de vérité qui ruine des après-midis.

La remédiation a été de remettre refresh/retry à des valeurs sensées, garder NOTIFY activé, et réduire la charge de transfert en corrigeant la vraie cause : trop d’AXFR complets dus à des IXFR manquants et des patterns de reload négligents. Ils ont aussi introduit un playbook de rollback forçant les secondaires à rafraîchir immédiatement après des corrections DNS critiques.

Mini-récit 3 : La pratique ennuyeuse et correcte qui a sauvé la situation

Une société de services financiers avait un contrôle de changement strict et beaucoup de DNS split-horizon utilisant des views BIND. Pas excitant. L’intérêt était leur discipline : chaque zone avait une ACL de transfert par zone, TSIG était obligatoire, et chaque changement passait par named-checkconf et named-checkzone avant déploiement. Ils avaient aussi un tableau de bord pour la « dérive de serial » entre le master et chaque secondaire.

Un jour, une VM secondaire a été restaurée depuis un snapshot ancien après une panne d’hyperviseur. Elle est revenue avec un fichier de clé TSIG obsolète (secret ancien) et une horloge légèrement fausse à cause d’un NTP HS. Les transferts échouaient. Le secondaire servait des données périmées.

La surveillance l’a détecté rapidement : alerte de dérive de serial plus messages d’échec de transfert. L’on-call n’a pas eu à deviner. Il a remplacé la clé TSIG, corrigé le NTP, et forcé un refresh. L’incident a été court, contenu et — plus important — ennuyeux à expliquer.

C’est le standard que vous voulez. Pas des exploits. Juste des contrôles stricts, des vérifications préalables et une visibilité qui vous dit exactement quel secondaire ment.

Erreurs fréquentes (symptômes → cause → correctif)

1) Symptom: Secondary never updates; logs show REFUSED

Cause racine : Le allow-transfer du primaire n’inclut pas l’IP du secondaire ou la clé TSIG, ou le secondaire frappe la mauvaise vue sur le primaire.

Correctif : Sur le primaire, définissez explicitement allow-transfer pour cette zone (préférez TSIG). Confirmez l’appariement des vues en vérifiant quelle adresse source/vue est utilisée.

2) Symptom: Transfers succeed sometimes, fail other times

Cause racine : Le secondaire a plusieurs masters listés ; l’un est joignable mais pas autorisé, ou le NAT change l’IP source de façon imprévisible, ou vous avez des complications anycast.

Correctif : Utilisez TSIG pour que l’auth ne dépende pas de l’IP source. Épurez les listes de masters vers l’ensemble prévu. Si anycast est impliqué, assurez-vous que les cibles de transfert sont stables et non une roulette du nœud le plus proche.

3) Symptom: Sudden spike in AXFR volume; network utilization climbs

Cause racine : IXFR indisponible (journal perdu, inline-signing modifié, reloads fréquents), ou secondaires forcés en transferts complets après des échecs.

Correctif : Investiguer pourquoi IXFR échoue. Confirmez que les journaux sont activés/retardés. Évitez les patterns de reload inutiles. Envisagez des limites de transfert seulement après avoir réduit les transferts complets.

4) Symptom: Secondaries serve old data after a rollback

Cause racine : Intervalles de refresh trop allongés, NOTIFY désactivé, ou rollback n’a pas déclenché de refresh forcé.

Correctif : Gardez NOTIFY activé pour les secondaires gérés. Pour les rollbacks, utilisez rndc notify sur le master et rndc refresh sur les secondaires pour converger rapidement.

5) Symptom: TSIG errors like “bad key” or “clock skew”

Cause racine : Mauvais secret, mauvais algorithme, mauvais nom de clé, ou dérive horaire qui cause le rejet des messages signés.

Correctif : Vérifiez que la définition de la clé correspond exactement des deux côtés. Assurez-vous que NTP est sain. Faites la rotation des clés soigneusement et conservez ancien/nouveau pendant la migration si nécessaire.

6) Symptom: Transfers work for one view but not another

Cause racine : La zone existe dans plusieurs views ; allow-transfer est défini seulement dans l’une d’elles, ou l’adresse source du secondaire correspond à une autre vue que prévu.

Correctif : Rendez l’intention des views explicite. Utilisez match-clients et/ou des interfaces de transfert dédiées. Configurez les transferts par vue et testez depuis l’IP source réelle du secondaire.

7) Symptom: “connection reset” or timeouts mid-transfer

Cause racine : Middlebox tuant les TCP longue durée, problèmes MTU, ou pression sur les ressources serveur (I/O fichier, backlog TCP).

Correctif : Capturez avec tcpdump des deux côtés, vérifiez le path MTU, augmentez les limites TCP système si nécessaire, et réduisez la fréquence des AXFR complets en réparant IXFR/journaux.

8) Symptom: Unauthorized parties can AXFR your zone

Cause racine : allow-transfer { any; }; ou aucune restriction sur le master, combiné à un TCP/53 exposé.

Correctif : Verrouillez par zone avec ACL/TSIG serrées. Envisagez de firewaller TCP/53 vers les secondaires connus. Auditez périodiquement avec des tests externes.

Listes de vérification / plan pas à pas

Étape par étape : verrouiller les transferts sans casser la réplication

1. Inventairez vos zones et secondaires prévus. Faites une liste : zone → master(s) → IP des secondaires → si TSIG est requis.
2. Décidez de votre politique de base : TSIG requis pour tous les transferts sauf exception documentée.
3. Créez des ACL dédiées par environnement. Gardez-les lisibles. « acl secondaries-prod { … } » vaut mieux qu’un cimetière d’IPs dans chaque stanza de zone.
4. Implémentez allow-transfer par zone. Préférez key-only. Si vous devez inclure des IPs, n’incluez que les secondaires.
5. Restreignez le traitement des NOTIFY sur les secondaires. Configurez allow-notify pour n’accepter que les master(s).
6. Assurez-vous que les règles de pare-feu reflètent la réalité du transport. Autorisez secondary → master TCP/53. Autorisez master → secondary UDP/53 pour NOTIFY (ou accepte le comportement refresh-only si vous désactivez NOTIFY).
7. Activez des logs qui peuvent prouver ce qui s’est passé. Vous voulez que les succès et échecs de transfert apparaissent clairement, sans noyer tout le reste.
8. Déployez progressivement. Commencez par une zone et un secondaire. Vérifiez, puis étendez.
9. Validez la convergence. Comparez le serial SOA sur tous les serveurs après un changement.
10. Ajoutez de la surveillance : dérive de serial, échecs de transfert et volume de transfert. Alertez sur la dérive au-delà d’un seuil et sur les échecs soutenus.
11. Testez depuis l’extérieur. Tentez un AXFR depuis un réseau non fiable et confirmez que cela échoue.
12. Rédigez le processus d’exception. Si quelqu’un a besoin d’un accès temporaire, il a une expiration et un ticket, pas une mémoire.

Checklist opérationnelle : lors de l’ajout d’un nouveau secondaire

• Confirmez l(es) IP(s) source du secondaire (surtout avec NAT/conteneurs).
• Générez et distribuez la clé TSIG de façon sécurisée.
• Ajoutez la clé et l’association serveur sur les deux côtés.
• Mettez à jour allow-transfer sur les zones du master.
• Mettez à jour also-notify sur le master (optionnel mais recommandé).
• Mettez à jour allow-notify sur le secondaire.
• Testez la connectivité TCP/53 dans les deux sens selon besoin.
• Forcez le transfert initial et confirmez que le serial SOA correspond.

Checklist opérationnelle : quand les transferts montent en flèche

• Identifiez qui se connecte à TCP/53.
• Vérifiez les logs pour REFUSED vs TSIG vs patterns de timeout.
• Mesurez le ratio AXFR vs IXFR.
• Vérifiez les boucles de reload de zone (automatisation poussant des zones inchangées en boucle).
• Envisagez des limites temporaires de rythme/transfert seulement après avoir confirmé que l’autorisation n’est pas trop large.

FAQ

1) Dois-je désactiver complètement les transferts de zone ?

Seulement si vous n’utilisez pas de DNS secondaire. Si vous avez des secondaires, vous avez besoin de transferts (ou d’un autre mécanisme de réplication). Le bon choix est une autorisation stricte + TSIG.

2) TSIG suffit-il, ou ai-je encore besoin d’ACL basées sur l’IP ?

Utilisez les deux quand vous le pouvez. TSIG authentifie au niveau DNS ; les ACL IP réduisent le bruit et l’exposition. Défense en profondeur, pas en dogme.

3) Pourquoi mes secondaires se mettent-ils lentement à jour alors que NOTIFY est activé ?

Parce que NOTIFY ne fait que déclencher une vérification. Si TCP/53 est bloqué, TSIG échoue, ou le master refuse les transferts, le secondaire attendra et réessaiera. Consultez les logs pour le premier échec après NOTIFY.

4) Quel est le moyen le plus rapide de savoir si je fuis des données de zone ?

Depuis un hôte externe non fiable, tentez dig AXFR zone @auth. Cela devrait échouer. Si ce n’est pas le cas, corrigez-le aujourd’hui, pas après le déjeuner.

5) AXFR fonctionne depuis un secondaire mais pas depuis un autre. Pourquoi ?

Causes les plus communes : l’IP de ce secondaire manque dans allow-transfer, mauvaise configuration TSIG sur ce nœud, ou le trafic du secondaire est émis depuis une IP différente de celle attendue (conteneurs/NAT).

6) Puis-je exécuter les transferts sur un port non standard ?

Vous le pouvez, mais c’est généralement s’auto-infliger des problèmes. Standardiser sur TCP/53 réduit les politiques de pare-feu étranges et la « connaissance tribale ». Si vous changez de port, documentez et testez sans relâche.

7) Les views BIND affectent-elles les transferts de zone ?

Oui. Les transferts se produisent dans le contexte d’une vue. Si le secondaire correspond à une vue différente de celle attendue, il peut obtenir REFUSED ou transférer le mauvais jeu de données. Soyez explicite avec match-clients et testez depuis l’IP source réelle du secondaire.

8) Quelle est la méthode sûre pour faire tourner les clés TSIG sans indisponibilité ?

Faites tourner les clés en parallèle pendant la transition : autorisez l’ancienne et la nouvelle clé pour les transferts, déployez la nouvelle clé partout, vérifiez le succès, puis retirez l’ancienne clé. Assurez-vous aussi que les horloges sont correctes.

9) Est-ce acceptable de compter sur « allow-transfer { none; } » globalement et d’outrepasser par zone ?

Oui. C’est une valeur par défaut sensée. Assurez-vous juste de l’outrepasser effectivement pour les zones qui nécessitent des secondaires, et surveillez les dérives pour remarquer quand vous oubliez.

10) Si je pare-feu TCP/53 uniquement vers les secondaires, ai-je encore besoin de allow-transfer ?

Oui. Les pare-feu dérivent, les règles sont clonées, et les réseaux internes ne sont pas intrinsèquement dignes de confiance. Gardez le contrôle au niveau application.

Prochaines étapes

Faites-les dans l’ordre si vous voulez dormir :

1. Auditez l’exposition : tentez un AXFR depuis un réseau non fiable contre chaque serveur faisant autorité que vous exploitez.
2. Rendez les transferts explicites : allow-transfer par zone et TSIG par secondaire.
3. Corrigez la réalité du transport : assurez-vous que secondary → master TCP/53 est permis ; assurez-vous que les chemins NOTIFY sont cohérents avec votre politique de pare-feu.
4. Ajoutez la surveillance de dérive de serial : si un secondaire prend du retard, vous devez le savoir avant les utilisateurs.
5. Répétez une panne contrôlée : cassez volontairement TSIG sur un secondaire de staging et confirmez que vos alertes, logs et runbook vous mènent à la bonne correction.

Les transferts de zone n’ont pas besoin d’être excitants. Si vos transferts sont excitants, votre configuration essaie de vous dire quelque chose. Écoutez-la.