Hello a tous,
La ou je bosse nous avons mis en place un groupe de serveur pdns/mysql avec
une réplication master/slave également.
Tres pratique a mettre a jour, ajouter un slave, etc.
Agréablement surpris aussi des performances pdns/mysql avec les caches
versus un bind avec fichier plat.
un test fait sur 4 records A les plus demandés.
Ensuite 1 million de A randoms...
Les résultats sont plutôt surprenants.
pdns/mysql a bien mieux répondus que bind dans tous les cas.
(Je ne donne pas les résultats, mes vms de tests et mes hyperviseurs
n’étant surement pas les mêmes que les vôtres)
Cordialement
Le 14 août 2013 16:37, Olivier Doucet webmas...@ajeux.com a écrit :
Bonjour,
Pour la partie interface graphique de gestion des DNS (combo
PowerDNS+SQL), j'ai repris il y a quelques mois le projet 'pdns-gui'
qui était à l'abandon depuis quelques années. L'interface est plutôt
jolie, mais je suis toujours à la recherche de bonnes âmes qui
auraient un peu de temps à passer dessus pour corriger les éventuels
bugs + améliorer l'outil.
Projet d'origine :
https://code.google.com/p/pdns-gui/
Le code forké avec pleins de correctifs est dispo ici :
https://github.com/odoucet/pdns-gui
N'hésitez pas à contribuer à l'outil ;)
Olivier
Le 14 août 2013 16:31, Benjamin Schilz benja...@whd-rs.com a écrit :
Je vois ça comme ça également, et la réplication SQL prend tout son sens
ici.
Merci des réponses ;)
-Message d'origine-
De : frsag-boun...@frsag.org [mailto:frsag-boun...@frsag.org] De la
part de
Jean Weisbuch
Envoyé : mercredi 14 août 2013 15:51
À : frsag@frsag.org
Objet : Re: [FRsAG] Backend SQL sur DNS autoritaires
J'ai connu ça (avoir plus de 1 zones générées dans des fichiers à
plat
depuis des données présentes dans une base SQL) et c'est quand même
sacrément plus simple/souple (et rapide) d'avoir PowerDNS avec un backend
SQL répliqué en master-slave (avec idéalement les slaves en read-only
pour
éviter des surprises et plus de sécurité).
On fais les UPDATE/INSERT/DELETE sur le master et les DNS esclaves qui ne
font que du SELECT n'ont pas de soucis. En plus, en cas de coupure réseau
entre le maitre et l'esclave, la réplication reprends la ou elle s'était
coupée dès que le lien est de retour.
Cela permet aussi de facilement faire des modifs sur certaines zones ou
entrées avec le langage SQL, par exemple si l'on veut modif tout les SPF
ou
rajouter une entrée donnée sur un ensemble de domaines sans avoir à
coder un
bout de script qui ne sera utilisé qu'une fois.
Sachant que PowerDNS possède plusieurs mécanismes de caches et qu'il est
ensuite possible d'activer le query cache coté SQL (dans le cas d'un
backend
MariaDB/MySQL en tout cas) qui est adapté à ce type d'utilisation et
qu'il
est possible de créér un nouveau slave en quelques secondes si l'on
utilise
des conteneurs (LXC/VServer/OpenVZ) en modifiant seulement le hostname,
l'IP
et créant un nouvel utilisateur SQL pour la réplication sur le master.
Le 14/08/2013 14:59, Dominique Rousseau a écrit :
Le Wed, Aug 14, 2013 at 12:24:04PM +0200, Greg [
greg-fr...@duchatelet.net]
a écrit:
rndc reload zone ne recharge aucun process ;)
Et croné, lancé en conditionnel (ie un truc a changé) toutes les
minutes, ça fait suffisament temps-réel, mis en face des TTL courant
du DNS :)
Sinon, bind intègre depuis longtemps un mécanisme d'update via
nsupdate (ou l'API correspondante)
___
Liste de diffusion du FRsAG
http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/
