Bonjour,
 
J'ai un souci DNS sous Bind.
J'ai une archi avec un DNS primaire planqué sur le réseau interne (ns1) et 4 DNS secondaires visibles d'Internet.
Nous venons d'ajouter deux nouveaux DNS secondaires (ns4 et ns5) aux deux qui existaient déjà (ns2 et ns3).
 
Chaque DNS secondaire à une IP privée en 10.0.0.0/8 et une IP publique avec du NAT.
Tout fonctionne bien. Les requêtes DNS sont bien résolues par les 2 nouveaux DNS et les 2 anciens.  
 
Toutefois, j'ai remarqué une incohérence et en creusant un peu, je me suis rendu compte que les deux nouveaux DNS répondaient mal à une requête sur leur nom et ce, uniquement si je les interroge à distance.  
Par exemple, si je me connecte sur ns5, et que je teste en direct la résolution de ns5.maboite.fr, il me retourne l'IP publique. Tout va bien. Par contre, si je vais sur un des autres DNS ou sur Internet et que je tente de résoudre ns5.maboite.fr @ns5, il me retourne l'IP privée...
Idem avec mon ns4.
 
J'ai beau chercher dans ma conf, il n'y a aucune trace des IP privées sur ns4 et ns5.
 
Je ne comprends pas d'où le problème peut venir et je n'aime pas voir mon IP Privée se balader sur le net.
Quelqu'un aurait-il une idée ?
 
Merci d'avance !
Bonne journée.

il doit rester sur ns4 et ns5 des entrées avec leurs ip privées.
 
est-ce que tu as le même résultat si tu interroges depuis ns4 ou ns5 ?  
ns5# dig @localhost ns5.maboite.fr
ns4# dig @localhost ns4.maboite.fr

Merci pour ta réponse.
 
Quand j'interroge ns5 sur son URL, il me répond correctement. Idem pour ns4.  
C'est uniquement quand la requête vient d'ailleurs (depuis le net ou depuis les autres DNS).  
 
J'ai également fait un grep de l'adresse IP privée dans tous les fichiers de conf de Bind, je n'ai rien trouvé.
 
Peut-être que c'est une incohérence dû au NAT... Même si je ne vois pas comment...

ça mériterait une trace réseau pour savoir qui répond quoi;  
 
bind peut aussi répondre des ip différentes en fonction de qui l'interroge, mais tu dois savoir ça.

Si tu pensais aux view, cela aurait pu, mais on n'en a qu'une seule sur ces DNS. ^^"
 
Je penche de plus en plus pour un NAT foireux qui modifierait l'adresse IP de l'en-tête et également dans les données.  
Effectivement, la trace réseau n'est pas inutile dans des cas comme ça. Je vais regarder ça.  
 
Merci.

Pour info, si ça peut servir un jour à quelqu'un, le problème venait d'un équipement entre le DNS et Interne (un SRX Juniper pour ne pas le citer), qui merdait le NAT.
Je n'en sais pas beaucoup, mais il semblerait que l'option DNS ALG est activée par défaut sur cet équipement. Cela fout un peu la merde, alors que désactiver cette option fait tout rentrer dans l'ordre.
 
Merci.
 
[EDIT] J'ai des détails :
Le SRX effectue la translation d'adresse du serveur DNS (static nat) non seulement au niveau 3 mais également, à tort,  au niveau 7.
Une solution de contournement consiste à désactiver l'alg DNS sur le SRX par la commande "set security alg dns disable" suivi d'un "commit".
Pour info, l'alg DNS a pour rôle de clore les sessions dès la réception d'une réponse et non pas au bout de 60 sec (timeout par défaut de l'udp).