Bonjour à tous, J'ai voulu faire une maintenance d'un serveur où se trouvait le serveur DNS primaire. En arrêtant ce serveur primaire j'ai crée pas mal d'effet indésirable : - Lenteur, - certaines applications web renvoyaient des erreurs 500. Logiquement mon serveur secondaire devrait suffire pour répondre à toutes les requêtes DNS. Après quelques recherches sur le net j'ai modifié la configuration du resolv.conf (mes serveurs sont sous Linux et les clients sous windows XP) : options rotate options timeout:1 options attempts:1 J'ai refait un test cela a grandement amélioré les choses. Cependant j'ai quand même une application que je n'ai pas réussi à joindre. Avez-vous déjà rencontré ce genre de problème ? Merci,
Bonjour, J'ai en effet eu de grosse lenteurs car mon DNS primaire etait aussi mon unique dns de reverse sur la zone concerné (le secondaire étant dans un autre datacenter pour de la sécurité). Tristan. Le 01/02/2012 16:34, Hugo Deprez a écrit :
Bonjour à tous,
J'ai voulu faire une maintenance d'un serveur où se trouvait le serveur DNS primaire. En arrêtant ce serveur primaire j'ai crée pas mal d'effet indésirable : - Lenteur, - certaines applications web renvoyaient des erreurs 500.
Logiquement mon serveur secondaire devrait suffire pour répondre à toutes les requêtes DNS.
Après quelques recherches sur le net j'ai modifié la configuration du resolv.conf (mes serveurs sont sous Linux et les clients sous windows XP) :
options rotate options timeout:1 options attempts:1
J'ai refait un test cela a grandement amélioré les choses. Cependant j'ai quand même une application que je n'ai pas réussi à joindre.
Avez-vous déjà rencontré ce genre de problème ?
Merci,
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 01/02/2012 16:34, Hugo Deprez wrote:
Bonjour à tous,
J'ai voulu faire une maintenance d'un serveur où se trouvait le serveur DNS primaire. En arrêtant ce serveur primaire j'ai crée pas mal d'effet indésirable : - Lenteur, - certaines applications web renvoyaient des erreurs 500.
Logiquement mon serveur secondaire devrait suffire pour répondre à toutes les requêtes DNS.
Après quelques recherches sur le net j'ai modifié la configuration du resolv.conf (mes serveurs sont sous Linux et les clients sous windows XP) :
options rotate options timeout:1 options attempts:1
J'ai refait un test cela a grandement amélioré les choses. Cependant j'ai quand même une application que je n'ai pas réussi à joindre.
Avez-vous déjà rencontré ce genre de problème ?
Merci,
Salut, Il faudrait d'abord qu'on sache un peu mieux de quoi tu parles :). Je suppose que tu parles de resolveur DNS ? Auquel cas pas, il n'y a pas de notion de primaire/secondaire, et contrairement aux serveur autoritaires c'est "normal" que ça mette du temps si ça failback. Dans ce cas, pas de magie, le mieux c'est d'utiliser du heartbeat ou équivalent pour gérer la transition et avoir toujours une ip qui réponde. A+ -- Mathieu Goessens IT consultant. gebura@poolp.org + 33 6 07 91 54 87 http://gebura.eu.org
Bonjour, Les entrées dns pour la résolution sont testé dans l'ordre, les clients essayent donc le premier serveur, attendent le timeout, puis le second qui répond. Pour les erreurs 500, je dirais soit : - timeout trop court dans l'applicatif qui échoue donc à répondre avant d'avoir eu sa résolution dns pour je ne sais quel composant autre - le secondaire n'avait pas la bonne réplique du master, donc pas d'information valide à donner - des couches applicatives qui ne savent pas appeler le serveur dns secondaire, mais je pense que ça n'existe plus enfin j'espère Le souci de modifier les clients avec ces options, c'est qu'il faut le faire sur tous les clients et que toute nouvelle machine sur le réseau n'aura sans doute pas cette configuration (serveur déplacé, client guest externe, consultant, ...). La seule vraie solution reste d'attribuer temporairement l'adresse ip du primaire à un secondaire ayant toutes les zones en cache. Pour ma part je ne marche qu'avec des masters pour mes dns sur lesquels je pousse la configuration qu'ils doivent utiliser ca limite considérablement les risques de la réplications. Ca permet de déplacer l'ip d'un serveur vers un autre pour une durée longue sans prendre le risque d'arriver à la fin du ttl des zones. Voilà à peu près les pistes. Bien cordialement -- Pierre-Henry Muller Le 01/02/12 16:34, Hugo Deprez a écrit :
Bonjour à tous,
J'ai voulu faire une maintenance d'un serveur où se trouvait le serveur DNS primaire. En arrêtant ce serveur primaire j'ai crée pas mal d'effet indésirable : - Lenteur, - certaines applications web renvoyaient des erreurs 500.
Logiquement mon serveur secondaire devrait suffire pour répondre à toutes les requêtes DNS.
Après quelques recherches sur le net j'ai modifié la configuration du resolv.conf (mes serveurs sont sous Linux et les clients sous windows XP) :
options rotate options timeout:1 options attempts:1
J'ai refait un test cela a grandement amélioré les choses. Cependant j'ai quand même une application que je n'ai pas réussi à joindre.
Avez-vous déjà rencontré ce genre de problème ?
Merci,
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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. 2012/2/1 Wallace <wallace@morkitu.org>
Bonjour,
Les entrées dns pour la résolution sont testé dans l'ordre, les clients essayent donc le premier serveur, attendent le timeout, puis le second qui répond.
Pour les erreurs 500, je dirais soit : - timeout trop court dans l'applicatif qui échoue donc à répondre avant d'avoir eu sa résolution dns pour je ne sais quel composant autre
- le secondaire n'avait pas la bonne réplique du master, donc pas d'information valide à donner
- des couches applicatives qui ne savent pas appeler le serveur dns secondaire, mais je pense que ça n'existe plus enfin j'espère
Le souci de modifier les clients avec ces options, c'est qu'il faut le faire sur tous les clients et que toute nouvelle machine sur le réseau n'aura sans doute pas cette configuration (serveur déplacé, client guest externe, consultant, ...). La seule vraie solution reste d'attribuer temporairement l'adresse ip du primaire à un secondaire ayant toutes les zones en cache.
Pour ma part je ne marche qu'avec des masters pour mes dns sur lesquels je pousse la configuration qu'ils doivent utiliser ca limite considérablement les risques de la réplications. Ca permet de déplacer l'ip d'un serveur vers un autre pour une durée longue sans prendre le risque d'arriver à la fin du ttl des zones.
Voilà à peu près les pistes.
Bien cordialement -- Pierre-Henry Muller
Le 01/02/12 16:34, Hugo Deprez a écrit :
Bonjour à tous,
J'ai voulu faire une maintenance d'un serveur où se trouvait le serveur DNS primaire. En arrêtant ce serveur primaire j'ai crée pas mal d'effet indésirable : - Lenteur, - certaines applications web renvoyaient des erreurs 500.
Logiquement mon serveur secondaire devrait suffire pour répondre à toutes les requêtes DNS.
Après quelques recherches sur le net j'ai modifié la configuration du resolv.conf (mes serveurs sont sous Linux et les clients sous windows XP) :
options rotate options timeout:1 options attempts:1
J'ai refait un test cela a grandement amélioré les choses. Cependant j'ai quand même une application que je n'ai pas réussi à joindre.
Avez-vous déjà rencontré ce genre de problème ?
Merci,
_______________________________________________ Liste de diffusion du FRsAGhttp://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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
Le 01/02/2012 19:18, Wallace a écrit :
Bonjour,
Les entrées dns pour la résolution sont testé dans l'ordre, les clients essayent donc le premier serveur, attendent le timeout, puis le second qui répond.
Bonjour, j'ai aussi été confronté à ce problème. Le seul moyen qu'on a trouvé de combattre des spammeurs sans blacklister des pays entiers, c'était de faire une résolution inverse sur l'IP du client. Comme ils sont malin, ils peuvent utiliser une IP whitelisté pour se logger, puis une autre IP une fois loggé. On doit donc faire cette résolution inverse à chaque appel PHP. Ce qui représente 400 requêtes PTR par seconde sur les resolvers Bind. Pour ça j'ai mis en place cette archi : chaque frontal PHP a son PowerDNS recursor pour le cache local, qui interroge 2 serveurs resolvers sous Bind9 avec chacun une VIP et ucarp pour répartir les VIP. Le resolv.conf ressemble à ça : nameserver 127.0.0.1 nameserver 10.0.10.1 nameserver 10.0.10.2 depuis, je n'ai plus aucun problème, et les résolutions sont plus rapides qu'avec Bind9. -- Greg
participants (6)
-
Florian Maury -
Gregory Duchatelet -
Hugo Deprez -
Mathieu Goessens -
Tristan Larouanne -
Wallace