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 <webmaster@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 <benjamin@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-bounces@frsag.org [mailto:frsag-bounces@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 10000 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-frsag@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/