Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Pages : 1
Hors ligne
selon les durées ton serveur va garder en cache la résolution de nom que tu a fait avant le coupure du DNS externe.
pendant la coupure du DNS externe comme tu a l IP du site tu n a pas besoin de DNS externe , juste de ton DNS local
je suppose que tu parle de ce wiki , => https://debian-facile.org/atelier:chant … sur-wheezy
l autre est vide et en chantier => https://debian-facile.org/:doc:reseau:serveur:bind9 [Tuto installé dans le wiki - Lien rafraîchi]
il serait intéressant de mettre le premier dans le second vu que il n y a que wheezy a remplacer par jessie , la version de bind est de 9 dans les 2 cas
juste a apporter les modifications a partir des retours des utilisateurs .
ps a voir avec mon matou chocolaté préféré 
(il se reconnaitra )
pour moi ce chantier est un doublon
Dernière modification par anonyme (15-01-2017 14:30:52)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
j'ai lu quelque part (impossible de me rappeler où)
Ce n'est pas une grande perte.
que bind9 ne créait pas de "table DNS" automatiquement enrichie au fil des requêtes et qu'il se contentait de pousser les requêtes DNS vers d'autres serveurs DNS.
Bien sûr que si, BIND garde en cache les réponses aux requêtes tant qu'elles sont valides.
Pour le reste, ce n'est pas si simple. BIND peut obtenir une réponse de deux façons différentes :
- en transmettant la requête à un autre serveur DNS récursif (appelé "forwarder") qui va se charger de faire la résolution récursive
- ou en faisant la résolution récursive lui-même, c'est-à-dire en interrogeant un à un les différents serveurs DNS faisant autorité pour la racine, le TLD, le domaine, le sous-domaine,etc. jusqu'au nom de domaine final à chaque fois que l'information dont il a besoin n'est pas dans son cache.
Si la liste des "forwarders" est vide, alors BIND fait systématiquement la résolution récursive.
Sinon, il interroge chaque forwarder jusqu'à obtenir une réponse. Si aucun forwarder ne répond et s'il a l'option "forward first", alors il fait la résolution récursive lui-même. S il a l'option "forward only" , alors il s'arrête et la résolution échoue.
Pour preuve, durant cette interruption, j'ai lancé à partir de ma machine principale un navigateur vers un site inutilisé jusque là (donc en principe inconnu de mon DNS)
Et là, durant cette panne chez Free, j'ai eu un retour me disant que la page était inaccessible. Donc un dysfonctionnement "attendu"
Ce dysfonctionnement n'est attendu que si tu as défini les serveurs DNS de Free comme forwarders et l'option "forward only". Dans les autres cas, BIND aurait dû être capable de répondre à la requête en faisant la résolution récursive lui-même (mais pas forcément dans le temps alloué par le poste client, donc pas à la première tentative).
Cette table DNS remplie au fil des requêtes existe-t-elle, oui ou non ? Et où se trouve-t-elle ?
Dans la mémoire de BIND. On peut demander un dump dans un fichier avec la commande
mais si ma mémoire est bonne et si ça n'a pas changé, ce fichier ne peut pas être utilisé pour préremplir le cache de BIND au démarrage.
Il vaut mieux montrer que raconter.
Hors ligne
Je suppose que leur présence est liée à la configuration du serveur. DHCP ne met pas Bind à jour sur ma machine. C'est peut-être pour cela.
@raleur
La commande
ne donne rien sur ma machine. Il semble que rndc soit un paquet supplémentaire qui n'est pas installé sur mon serveur. Comme je ne sais pas ce qu'il fait, je vais plutôt me renseigner avant de faire des bêtises.
Merci pour vos réponses.
Dernière modification par speedstream (15-01-2017 20:46:53)
Hors ligne
retour
a mon avis ta commande est pas bonne (voir avec rndc qui donne les commandes possible ) , teste rndc status , rndc fait partie de bind ou ton installation a un problème .
voila ce que me renvoie pour dumpdb (pas trouvé autre chose )
Dernière modification par anonyme (15-01-2017 21:06:56)
je parle des 2 fichiers de travail en .jnl mais pour le cache des résolutions de nom du DNS local j'ai pas la certitude que ce soit ceux la
Non, les fichiers .jnl n'ont aucun rapport avec le cache. Si ma mémoire est bonne, ce sont les "journaux" (au sens de liste des modifications, comme dans un système de fichiers journalisé) des zones "dynamiques" modifiables par dhcpd par exemple.
Dernière modification par raleur (15-01-2017 21:10:44)
Il vaut mieux montrer que raconter.
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Mis le lien vers ce post dans le tuto bind9 :
https://debian-facile.org/doc:reseau:serveur:bind9
... https://arpinux.org/images/gifs/character0015.gif
Merci
Hors ligne
Dernière modification par anonyme (15-01-2017 21:29:29)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
ceci me pose problème
je ne comprend pas ce que le rédacteur a voulu dire
il faut savoir que dans la configuration de bind il faut finir le nom de domaine par un point
exemple:
si quelqu un comprend le sens de cette phrase
ps: le reste me semble correct , sans rentrer trop dans le détail
Dernière modification par anonyme (16-01-2017 12:21:13)
Le point après com est sous-entendu pour l'utilisation du côté client, mais pas dans la configuration du DNS.
Et bien si l'on regarde le domaine www.toto.com. , on constate qu'il a mis un point après toto.com et que dans le cas des domaines secondaires, il y en a deux.
Mais on n'a jamais vu un client configuré de la sorte lorsque l'on cite un domaine.
Je suppose que la phrase se rapporte à ce détail qui semble avoir une grande importance dans le cadre de la config du serveur DNS. Même s'il aurait été bien d'expliquer ce qui peut découler de cet oubli. Bon, je suis exigeant...
Si l'on va sur la page suivante https://fr.wikipedia.org/wiki/Fully_qua … omain_name, la première phrase que l'on trouve dit ceci en parlant du FQDN :
Dans le DNS, un fully qualified domain name (FQDN, ou nom de domaine complètement qualifié) est un nom de domaine qui révèle la position absolue d'un nœud dans l'arborescence DNS en indiquant tous les domaines de niveau supérieur jusqu'à la racine. On parle également de domaine absolu, par opposition aux domaines relatifs. Par convention, le FQDN est ponctué par un point final.
Le reste de la page semble d'ailleurs répondre à ta question, anonyme.
En gros, un FQDN comporte forcément un point final, à l'image de l'exemple www.toto.com.
Un FQDN est un domaine absolu qui comporte ce point, par opposition aux domaines relatifs qui n'en comportent pas.
Par ailleurs, et en restant positif, je n'ai pas relevé les fautes d'orthographes ou d'accords dans ce tuto. Mais il y a quand même une petite correction qui me semble importante à faire :
FQDN n'est pas (Fool domain name) qui signifie littéralement "Nom de domaine imbécile" 
FQDN signifie Fully Qualified Domain Name pour "Nom de domaine Pleinement Qualifié". Je suppose qu'il y a ici une part implicite administrative vis-à-vis de l'ICANN.
Tout cela pour dire que l'on peut avoir un serveur DNS qui gère son propre domaine dans le LAN et ne sera pas enregistré sur le Net. Il sera pleinement fonctionnel et forcément FQDN du point de vue technique mais pas forcément FQDN d'un point de vue administratif puisqu'il n'aura peut-être pas besoin de traiter les requêtes qui viennent du WAN (ou ne sera pas dans le WAN) et ne sera donc pas enregistré à l'ICANN.
Et pour ne léser personne, je remercie aussi anonyme... et raleur, bien entendu
Dernière modification par speedstream (16-01-2017 14:35:03)
Hors ligne
(l'info en cache )) va répondre avec l ip du dit site 
faut pas jouer avec ça 
la valeur par défaut est "dnssec-validation auto" sur bind9 , ceci est utile pour nom de domaine FQDN
l' implémentation n'est pas complète sur tous les DNS , c'est une fonction de sécurité.
un complément d'information pour le tuto je pense que ce serait pas mal sur cette fonction
Dernière modification par anonyme (16-01-2017 18:09:42)
Pages : 1
