Le 3 févr. 2012 à 10:57, Hugo Deprez a écrit : > Bonjour, > > j'utilise deux serveurs bind9, ce sont des resolver. Un est master et un > slave dans le sens où le slave récupère ses zones via le master. > Effectivement j'avais pensé à faire une VIP, mais d'après moi le > fonctionnement même de DNS intègre déjà cette haute disponibilité (dans > resolv.conf deux serveur dns sont spécifiés, dans windows aussi). Donc je > ne comprend pas pourquoi j'ai ce comportement. > > J'ai essayé de le reproduire sur un environnement de test en droppant le > flux vers le DNS primaire mais je n'ai pas le même comportement.
Bonjour, Si il y a des zones à répliquer alors ce ne sont pas des résolveurs, mais des serveurs faisant autorité sur des zones (authoritative servers *sigh traduction*). Ou alors ce sont des serveurs qui font les deux :o) Merci à Bind d'avoir permis ce genre de confusion :o( Je ne pense pas que les stub-resolveur fassent de la requête simultanée sur l'ensemble des résolveurs. Ils appellent l'un d'entre eux, si ca ne répond pas (timeout), ils appellent le suivant, et ainsi de suite. J'imagine qu'ils doivent en revanche changer la priorité des serveurs de récursion si l'un d'entre eux fait trop de timeout durant une période donnée... si ce n'est pas le cas, il faudrait y réfléchir :o) Le délai de timeout avant abandon d'un résolveur pour aller requérir l'avis du second (merci à Microsoft pour encore plus rendre cela confus avec la notion de "serveur de résolution primaire et secondaire"...) est assez probablement ce qui cause les lenteurs... Pour les app web qui plantent, ca ne m'étonne pas tellement... si la grande majorité des devs web savaient coder, ca se saurait (on est trolldi >:o) ) ! Une appli ne devrait pas planter (500) parce qu'un récurseur met du temps à répondre. Il y a un problème d'implémentation à revoir, même si tu trouves une solution pour ton problème de récurseur, m'est avis. La solution du heartbeat est effectivement possible. La solution de raccourcir le délai de timeout comme tu l'as fait avec des options du stub-resolver est possible également (mais il faut la maintenir... à voir si on ne peut pas distribuer ces options avec le DHCP). Peut être que ton essai en environnement de test a utilisé le cache local de ta machine et n'a pas interrogé les résolveurs : essaie de faire un ipconfig /flushdns / dscacheutil -flushcache / nscd -i hosts et de monitorer ton réseau pour vérifier que la requête est réellement faite (cible LOG sous iptables ou plus simplement tcpdump 'port 53') Bon courage. Cordialement, Florian Maury _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
