On Wednesday 31 December 2003 12:15, Marc SCHAEFER wrote: > Int�ressant. Je fais �galement cela, mais au niveau du DNS: tout pointe > sur une adresse unique (pas de CNAME, champs A). Avec des > timeouts/refresh de 4h tu peux d�j� faire pas mal de flexibilit� avec > �a.
L'objectif etant d'assurer un transition la plus rapide possible. En effet, les adresse IP peuvent rester dans les caches des serveurs/routers pendant quelques heures et il n'est pas raisonnable d'accelere les mises a jour. Le seul moyen que j'ai trouve et d'utiliser ces alias, car une machine peut reprendre la main de maniere automatique en rajoutant un alias sur son interface losrqu'elle voit que le serveur "primaire" du service n'est plus la. Reste ensuite le probleme du mapping des adresse MAC dans mon routeur local... resolu en effectuant un arp en mode brodcast avec l'adresse IP et a MAC address concernee. Ceci ne vas pas mettre a jour la table dans le routeur (securite !), mais l'obliger a refaire une requete ARP... et hop maintenant l'adresse est correctement routee. Je peux arriver a garantir un temps de commutation de service de quelques secondes (1-5 suivant le degre de nervosite). Ainsi, cette commutation passe totalement inapercue pour les clients des services. Ainsi, je ne touche plus mes "zones" DNS et je n'ai plus besoin de redemarrer le serveur losrque je transfere un service d'une machine a l'autre. Pour info, s'il est vrai que l'usage de CNAME peut apporter un peu de clarete dans un fichire de "zone", il introduit un niveau d'indirection et necessaite une requete suplementaire pour acceder a ce a quoi il se refere. DOnc chainer des CNAME peut s'averer couteux :-) > Une alternative est de mettre un firewall/NAT devant. Je fais souvent �a > pour les DMZ. Chaque service est alors `mappable' facilement. Les > serveurs dans le DMZ poss�dent une adresse priv�e. Cela simplifie > �galement les concepts `fail-over'. Tout a fait. Mais comme je veux aussi beneficier de cette souplesse a l'interieur de mon Intranet, j'ai trouvais plsu elegant de ne pas toucher, ni le DNS, ni le firewall. De plus, router le traffic interne peut s'averer couteux chez nous. Nous avons enormement de traffic entre trois niveaux d'application dont chacune peut se deplacer horizontalement entre trois machines (redondance). Obliger tout le traffic a passer par le firewall serait penalisant. > Regarde > netstat -an | grep LISTEN | grep 53 Ceci me donnera bien le port tcp sur lequel named ecoute, mais pas l'udp; car les requetes DNS font, en general, moins de 512 bytes... d'ou l'usage de l'udp par defaut. Le mode d'acces en tcp est recent et doit souvent etre explicitement specifie suivant les versions de serveur (defaut en 9) > Maintenant je rajoute un alias, je suppose que dans ce cas, BIND > ne va pas rajouter un socket. Non, en tout cas pas pour IPv6, mais il pourait avoir plusisures sockets pour IPv4 (j'ai oublie pourquoi mais j'ai vu ca dans le source). > Il va donc recevoir sur 0.0.0.0, voire > sur l'adresse IP principale de la carte et renverra par le chemin le > plus logique. CAD en utilisant l'adresse IP du socket ouvert. > (souvenirs lointains de programmation socket UNIX) :-) > Je me demande si tout simplement un listen-on adresse-ip-virtuelle; > ne va pas rajouter un socket de plus et donc r�soudre ton probl�me. > Essaie-voir �a et envoie le netstat -anp ... C'est en ragardant le souce se server.c que j'ai commence a me poser des questions. En effet, les choses sont faites proprement et tout me paraissait tres clair. Je vopyais donc bien que le code prenait bien l'option 'listen-on' en compte... J'ai donc commence a douter de quelque chose et voila ! > > ;; reply from unexpected source: 192.168.1.2#53, expected 192.168.1.30#5 > > Ca semble tr�s clair, effectivement. Oui, maintenant tout s'explique, mais j'avoue avoir etet induit en erreur car ce message d'erreur ne semble etre generer que lors d'une connection tcp (trouver dans le code source de dig). > [ je ne comprends pas trop ta magouille :52 dans la mesure o� tu ne dis > pas non plus au client qu'il doit faire du DNS sur le port 52] Le but etant de verifier que ma regle etait bien capable de traiter les requetes DNS uniquement et de prouver que je recrivais correctement l'adresse IP. En modifiant le 'sport', je devais continuer a avoir le message d'erreur mais je devais voir que, si le port etait faux, l'adresse par contre etait maintenant bien juste. cqfd. Lorsque je mettais l'adresse 53, mon paquet se perdait dans la suite de la queue POSROUTING. Je n'etais donc pas au bon endroit dans le script ! Merci pour tes explications qui m'ont un peu mis la puce a l'oreille :-) Daniel _______________________________________________ gull mailing list [EMAIL PROTECTED] http://lists.alphanet.ch/mailman/listinfo/gull
