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-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/
