Bonjour à tous,
Petite question avant le pont du 15 août J
On a actuellement sur notre infra un couple de serveurs « autoritaires » gérant environ 15000 zones qui tourne sous BIND 9.7.3 avec en backend des fichiers à plat. Le tout géré de manière automatique par des scripts PERL
Ça marche bien mais on va prochainement changer les serveurs concernés et cest loccasion de remettre en cause le choix darchitecture.
Mon idée est de passer sur un backend MySQL.
Jai lu différentes choses sur le support MySQL de BIND (DLZ support) pas forcément positives, comme ici : http://serverfault.com/questions/365434/configure-bind-with-database-backend -and-dlz-support
Est-ce que certains utilisent ça ? un autre serveur DNS ?
Merci davance ;)
Benjamin
Bonjour,
Moi j'utilise PowerDNS avec Postgresql en backend sur deux serveurs (en maître/esclave). Que du bonheur. Mais je ne gère que 1500 domaines. Je n'ai pas d'idée sur une montée en charge vers les 15000.
Sylvain
De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Benjamin Schilz Envoyé : mercredi 14 août 2013 10:53 À : frsag@frsag.org Objet : [FRsAG] Backend SQL sur DNS autoritaires
Bonjour à tous,
Petite question avant le pont du 15 août :)
On a actuellement sur notre infra un couple de serveurs « autoritaires » gérant environ 15000 zones qui tourne sous BIND 9.7.3 avec en backend des fichiers à plat. Le tout géré de manière automatique par des scripts PERL ... Ça marche bien mais on va prochainement changer les serveurs concernés et c'est l'occasion de remettre en cause le choix d'architecture.
Mon idée est de passer sur un backend MySQL.
J'ai lu différentes choses sur le support MySQL de BIND (DLZ support) pas forcément positives, comme ici : http://serverfault.com/questions/365434/configure-bind-with-database-backend...
Est-ce que certains utilisent ça ? un autre serveur DNS ?
Merci d'avance ;)
Benjamin
Moi aussi PowerDNS mais avec le backend en MySQL sur 4 serveurs (réplication sql) + DNSSEC, Aucun problème depuis des années, avec les 6700 zones qui tourne.
On 14/08/2013 11:28, Sylvain Donnet wrote:
Bonjour,
Moi j'utilise PowerDNS avec Postgresql en backend sur deux serveurs (en maître/esclave). Que du bonheur. Mais je ne gère que 1500 domaines. Je n'ai pas d'idée sur une montée en charge vers les 15000.
Sylvain
*De :*frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] *De la part de* Benjamin Schilz *Envoyé :* mercredi 14 août 2013 10:53 *À :* frsag@frsag.org *Objet :* [FRsAG] Backend SQL sur DNS autoritaires
Bonjour à tous,
Petite question avant le pont du 15 août J
On a actuellement sur notre infra un couple de serveurs « autoritaires » gérant environ 15000 zones qui tourne sous BIND 9.7.3 avec en backend des fichiers à plat. Le tout géré de manière automatique par des scripts PERL ...
Ça marche bien mais on va prochainement changer les serveurs concernés et c'est l'occasion de remettre en cause le choix d'architecture.
Mon idée est de passer sur un backend MySQL.
J'ai lu différentes choses sur le support MySQL de BIND (DLZ support) pas forcément positives, comme ici : http://serverfault.com/questions/365434/configure-bind-with-database-backend...
Est-ce que certains utilisent ça ? un autre serveur DNS ?
Merci d'avance ;)
Benjamin
Liste de diffusion du FRsAG http://www.frsag.org/
Effectivement la gestion du cache est importante, et même si le cache SQL peut être efficace le DLZ de Bind risque de défoncer la base en cas de flood DNS (type requêtes « chinoises » de lannée dernière).
Je vais me faire un POC sur PowerDNS J
De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Jérémy SPIESSER
Moi aussi PowerDNS mais avec le backend en MySQL sur 4 serveurs (réplication sql) + DNSSEC, Aucun problème depuis des années, avec les 6700 zones qui tourne.
On 14/08/2013 11:28, Sylvain Donnet wrote:
Bonjour,
Moi jutilise PowerDNS avec Postgresql en backend sur deux serveurs (en maître/esclave). Que du bonheur. Mais je ne gère que 1500 domaines. Je nai pas didée sur une montée en charge vers les 15000.
Sylvain
De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Benjamin Schilz Envoyé : mercredi 14 août 2013 10:53 À : frsag@frsag.org Objet : [FRsAG] Backend SQL sur DNS autoritaires
Bonjour à tous,
Petite question avant le pont du 15 août J
On a actuellement sur notre infra un couple de serveurs « autoritaires » gérant environ 15000 zones qui tourne sous BIND 9.7.3 avec en backend des fichiers à plat. Le tout géré de manière automatique par des scripts PERL
Ça marche bien mais on va prochainement changer les serveurs concernés et cest loccasion de remettre en cause le choix darchitecture.
Mon idée est de passer sur un backend MySQL.
Jai lu différentes choses sur le support MySQL de BIND (DLZ support) pas forcément positives, comme ici : http://serverfault.com/questions/365434/configure-bind-with-database-backend -and-dlz-support
Est-ce que certains utilisent ça ? un autre serveur DNS ?
Merci davance ;)
Benjamin
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 14 août 2013 10:52, Benjamin Schilz benjamin@whd-rs.com a écrit :
Bonjour à tous,
Bonjour,
Mon idée est de passer sur un backend MySQL.
Aux dernières nouvelles, BIND ne dispose pas de cache des résultats des requêtes SQL. Donc une requête DNS = une (ou plus) requête SQL. D'ou les mauvaises performances du backend MySQL. En revanche, j'en entendu que du bien du couple PowerDNS + PostgreSQL, qui lui dispose bien d'un cache SQL.
Stéphane avait écrit un article à ce propos : http://www.bortzmeyer.org/registre-temps-reel.html L'article date de 2007, je ne sais pas si il y a eu beaucoup de changements depuis.
Intéressant merci ;)
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Jonathan Leroy Envoyé : mercredi 14 août 2013 11:36 À : French SysAdmin Group Objet : Re: [FRsAG] Backend SQL sur DNS autoritaires
Le 14 août 2013 10:52, Benjamin Schilz benjamin@whd-rs.com a écrit :
Bonjour à tous,
Bonjour,
Mon idée est de passer sur un backend MySQL.
Aux dernières nouvelles, BIND ne dispose pas de cache des résultats des requêtes SQL. Donc une requête DNS = une (ou plus) requête SQL. D'ou les mauvaises performances du backend MySQL. En revanche, j'en entendu que du bien du couple PowerDNS + PostgreSQL, qui lui dispose bien d'un cache SQL.
Stéphane avait écrit un article à ce propos : http://www.bortzmeyer.org/registre-temps-reel.html L'article date de 2007, je ne sais pas si il y a eu beaucoup de changements depuis.
-- Jonathan Leroy
Qu'est-ce que 15000 fichiers plats dans un OS ? Le buffer cache de Linux met tout ça en RAM, l'administration via les outils unix type grep, sed, awk, perl est parfaite pour ça.
Perso j'utilise MySQL pour gérer une partie des zones, principalement pour des méta-données comme la date d'expiration d'un domaine. Mais pour au final générer les fichiers plats...
Le 14 août 2013 11:54, Benjamin Schilz benjamin@whd-rs.com a écrit :
Intéressant merci ;)
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Jonathan Leroy Envoyé : mercredi 14 août 2013 11:36 À : French SysAdmin Group Objet : Re: [FRsAG] Backend SQL sur DNS autoritaires
Le 14 août 2013 10:52, Benjamin Schilz benjamin@whd-rs.com a écrit :
Bonjour à tous,
Bonjour,
Mon idée est de passer sur un backend MySQL.
Aux dernières nouvelles, BIND ne dispose pas de cache des résultats des requêtes SQL. Donc une requête DNS = une (ou plus) requête SQL. D'ou les mauvaises performances du backend MySQL. En revanche, j'en entendu que du bien du couple PowerDNS + PostgreSQL, qui lui dispose bien d'un cache SQL.
Stéphane avait écrit un article à ce propos : http://www.bortzmeyer.org/registre-temps-reel.html L'article date de 2007, je ne sais pas si il y a eu beaucoup de changements depuis.
-- Jonathan Leroy
Liste de diffusion du FRsAG http://www.frsag.org/
Oui, certes. Mais l'avantage d'une base de données, c'est que l'on fait des modifs en permanence dedans, voire, même, nos clients peuvent le faire via une interface Web, et on ne recharge/redémarre aucun process.
De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Greg Envoyé : mercredi 14 août 2013 12:10 À : French SysAdmin Group Objet : Re: [FRsAG] Backend SQL sur DNS autoritaires
Qu'est-ce que 15000 fichiers plats dans un OS ? Le buffer cache de Linux met tout ça en RAM, l'administration via les outils unix type grep, sed, awk, perl est parfaite pour ça.
Perso j'utilise MySQL pour gérer une partie des zones, principalement pour des méta-données comme la date d'expiration d'un domaine. Mais pour au final générer les fichiers plats...
Le 14 août 2013 11:54, Benjamin Schilz <benjamin@whd-rs.commailto:benjamin@whd-rs.com> a écrit : Intéressant merci ;)
-----Message d'origine----- De : frsag-bounces@frsag.orgmailto:frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.orgmailto:frsag-bounces@frsag.org] De la part de Jonathan Leroy Envoyé : mercredi 14 août 2013 11:36 À : French SysAdmin Group Objet : Re: [FRsAG] Backend SQL sur DNS autoritaires
Le 14 août 2013 10:52, Benjamin Schilz <benjamin@whd-rs.commailto:benjamin@whd-rs.com> a écrit :
Bonjour à tous,
Bonjour,
Mon idée est de passer sur un backend MySQL.
Aux dernières nouvelles, BIND ne dispose pas de cache des résultats des requêtes SQL. Donc une requête DNS = une (ou plus) requête SQL. D'ou les mauvaises performances du backend MySQL. En revanche, j'en entendu que du bien du couple PowerDNS + PostgreSQL, qui lui dispose bien d'un cache SQL.
Stéphane avait écrit un article à ce propos : http://www.bortzmeyer.org/registre-temps-reel.html L'article date de 2007, je ne sais pas si il y a eu beaucoup de changements depuis.
-- Jonathan Leroy
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
rndc reload zone ne recharge aucun process ;)
Alors qu'avec un backend SQL, on peut dire qu'il est "rechargé" à chaque requête !
Le 14 août 2013 12:16, Sylvain Donnet sylvain.donnet@ddo.net a écrit :
Oui, certes. Mais l’avantage d’une base de données, c’est que l’on fait des modifs en permanence dedans, voire, même, nos clients peuvent le faire via une interface Web, et on ne recharge/redémarre aucun process.****
*De :* frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] *De la part de* Greg *Envoyé :* mercredi 14 août 2013 12:10
*À :* French SysAdmin Group *Objet :* Re: [FRsAG] Backend SQL sur DNS autoritaires****
Qu'est-ce que 15000 fichiers plats dans un OS ? Le buffer cache de Linux met tout ça en RAM, l'administration via les outils unix type grep, sed, awk, perl est parfaite pour ça.****
Perso j'utilise MySQL pour gérer une partie des zones, principalement pour des méta-données comme la date d'expiration d'un domaine. Mais pour au final générer les fichiers plats...****
Le 14 août 2013 11:54, Benjamin Schilz benjamin@whd-rs.com a écrit :****
Intéressant merci ;)
-----Message d'origine-----****
De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de****
Jonathan Leroy Envoyé : mercredi 14 août 2013 11:36 À : French SysAdmin Group Objet : Re: [FRsAG] Backend SQL sur DNS autoritaires****
Le 14 août 2013 10:52, Benjamin Schilz benjamin@whd-rs.com a écrit :
Bonjour à tous,
Bonjour,
Mon idée est de passer sur un backend MySQL.
Aux dernières nouvelles, BIND ne dispose pas de cache des résultats des requêtes SQL. Donc une requête DNS = une (ou plus) requête SQL. D'ou les mauvaises performances du backend MySQL. En revanche, j'en entendu que du bien du couple PowerDNS + PostgreSQL, qui lui dispose bien d'un cache SQL.
Stéphane avait écrit un article à ce propos : http://www.bortzmeyer.org/registre-temps-reel.html L'article date de 2007, je ne sais pas si il y a eu beaucoup de changements depuis.
-- Jonathan Leroy
Liste de diffusion du FRsAG http://www.frsag.org/****
Liste de diffusion du FRsAG http://www.frsag.org/
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)
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)
+1 pour la solution replic master/slave
On 14/08/2013 15:51, Jean Weisbuch wrote:
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/
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/
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/
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/
hello,
j'utilise PowerDNS avec OpenLdap depuis pas mal d'année sans soucis mais je n'ai que ~500 zones
On 08/14/2013 10:52 AM, Benjamin Schilz wrote:
Bonjour à tous,
Petite question avant le pont du 15 août J
On a actuellement sur notre infra un couple de serveurs « autoritaires » gérant environ 15000 zones qui tourne sous BIND 9.7.3 avec en backend des fichiers à plat. Le tout géré de manière automatique par des scripts PERL …
Ça marche bien mais on va prochainement changer les serveurs concernés et c’est l’occasion de remettre en cause le choix d’architecture.
Mon idée est de passer sur un backend MySQL.
J’ai lu différentes choses sur le support MySQL de BIND (DLZ support) pas forcément positives, comme ici : http://serverfault.com/questions/365434/configure-bind-with-database-backend...
Est-ce que certains utilisent ça ? un autre serveur DNS ?
Merci d’avance ;)
Benjamin
Liste de diffusion du FRsAG http://www.frsag.org/
Quand je vois tous ceux qui foncent dans le sql en backend connecté je plains les clients en cas d'attaque ou d'isolation réseau.
Voilà ma petite expérience : - les dns ne devant pas tous se trouver sur le même AS, il faut logiquement en mettre un peu partout sur la toile pour la résilience de votre infra dns - il faut aussi les nommer avec des tld différents si vous mettez tout sur un seul tld ou plusieurs gérés par les mêmes entités administrative en cas de plantage de leurs côté tout tombe - en cas d'attaque dns, pouvoir isoler un serveur dns c'est utile - les backends mysql / psql sur bind on oublie, sur pdns c'est mieux mais la dépendance d'une architecture sql pleinement fonctionnelle est trop forte surtout en cas de réplication géographique - des pdns / sql j'en ai vu tomber plus d'un en cas de forte charge, vu des soucis de synchro sql vautrer des enregistrements avec des ttl d'une semaine, là on est content quand ça arrive
Avec tous ces points, on est parti sur du Bind avec fichiers à plat, c'est clairement ce qui tient le mieux la charge y compris en cas de ddos, ça claque bien plus haut que pdns / sql. Par contre on voulait pouvoir gérer avec une interface web principalement pour éviter les erreurs de syntaxe à 4h du mat un dimanche en astreinte, même avec plus de 10 ans d'xp on fait encore ces conneries de temps en temps. L'interface montre à la façon PdnsAdmin une vue synthétique de la zone mais où les modifications ne sont pas instantanées, pdnsadmin propage directement en base et si vous avez fait une boulette c'est immédiat. Là l'interface vérifie la zone, la prépare en fichier à plat dans un coin, la teste avec un bind local si le reload se fait correctement, si oui pousse les fichiers sur les différents serveurs dns, vérifie les numéros de série des zones plus le hash des fichiers. Si tous les serveurs sont bons reload des zones modifiées.
Ce qui nous permet d'avoir une solution entièrement décentralisée, de mettre des serveurs dns où l'on veut sur Internet, en cas de compromission d'un serveur dns les données maitre ne sont pas touchées puisque pas d'accès à la base, pas de dépendance de flux le bind est autonome et forcément maitre sur toutes ses zones (pas de réplication master / slave dns).
Juste pour ceux qui doutent encore de l'intérêt de mettre leurs dns en dehors de leur AS et infra, quand votre infra est inaccessible, les clients qui ont leurs zones chez vous ne peuvent plus bosser (pas de mail, pas de connexion aux services autres que chez vous, ...) et en 10 ans j'en ai vu des infras isolées par coupure réseau (plusieurs transitaire d'un coup, migration réseau qui déconne, pb bgp, ...), ddos rendant injoignable la plate-forme, piratage de serveur dns maitre en réplication ou du backend de gestion dns ou du serveur bdd, ...
Voilà ma petite expérience :
- les dns ne devant pas tous se trouver sur le même AS, il faut
logiquement en mettre un peu partout sur la toile pour la résilience de votre infra dns
Bonjour : remarque uniquement valable pour ceux qui disposent d'infrastructures elles même réparties sur plusieurs AS. Aucun intérêt pour les autres (si le réseau est HS, les dns ne répondront plus, pas plus que le reste de l'infrastructure).
- en cas d'attaque dns, pouvoir isoler un serveur dns c'est utile
- les backends mysql / psql sur bind on oublie, sur pdns c'est mieux
mais la dépendance d'une architecture sql pleinement fonctionnelle est trop forte surtout en cas de réplication géographique
Je ne vois de toute manière pas l'intérêt d'utiliser des services annexes comme du SQL pour faire tourner du DNS, qui est un protocole "primaire" qui fonctionne très bien sur la base de fichiers.
Juste pour ceux qui doutent encore de l'intérêt de mettre leurs dns en dehors de leur AS et infra, quand votre infra est inaccessible, les clients qui ont leurs zones chez vous ne peuvent plus bosser (pas de mail, pas de connexion aux services autres que chez vous, ...) et en 10 ans j'en ai vu des infras isolées par coupure réseau (plusieurs transitaire d'un coup, migration réseau qui déconne, pb bgp, ...), ddos rendant injoignable la plate-forme, piratage de serveur dns
Remarque valable lorsque les clients ont des pointages externes. En plus, le dns est ce qu'il y a de quasiment le plus facile à sauvegarder / répliquer, réinstaller. Je ne sais pas combien ici ont déjà eu une infra down à cause des DNS, mais c'est vraiment bien le seul soucis dont je n'entends jamais parler en interne.
Jusqu'à y a encore quelques années, le secondaire était d'ailleurs un vieux céleri avec 256 Mo de RAM et il gérait plus 40.000 domaines sans problèmes et sans charge.
Pour les risques de compromission : utilisez 2 distribs et versions différentes sur les primaire et secondaire + backup externe unique vérouillé à chaque modification : ça marche très bien également.
amicalement,
christophe.casalegno@digital-network.net a écrit :
Voilà ma petite expérience :
- les dns ne devant pas tous se trouver sur le même AS, il faut
logiquement en mettre un peu partout sur la toile pour la résilience
de
votre infra dns
Bonjour : remarque uniquement valable pour ceux qui disposent d'infrastructures elles même réparties sur plusieurs AS. Aucun intérêt pour les autres (si le réseau est HS, les dns ne répondront plus, pas plus que le reste de l'infrastructure).
Ça permet de ne pas avoir un NXDOMAIN à chaque mail par exemple.
- en cas d'attaque dns, pouvoir isoler un serveur dns c'est utile
- les backends mysql / psql sur bind on oublie, sur pdns c'est mieux
mais la dépendance d'une architecture sql pleinement fonctionnelle
est
trop forte surtout en cas de réplication géographique
Je ne vois de toute manière pas l'intérêt d'utiliser des services annexes comme du SQL pour faire tourner du DNS, qui est un protocole "primaire" qui fonctionne très bien sur la base de fichiers.
Juste pour ceux qui doutent encore de l'intérêt de mettre leurs dns
en
dehors de leur AS et infra, quand votre infra est inaccessible, les clients qui ont leurs zones chez vous ne peuvent plus bosser (pas de mail, pas de connexion aux services autres que chez vous, ...) et en
10
ans j'en ai vu des infras isolées par coupure réseau (plusieurs transitaire d'un coup, migration réseau qui déconne, pb bgp, ...),
ddos
rendant injoignable la plate-forme, piratage de serveur dns
Remarque valable lorsque les clients ont des pointages externes. En plus, le dns est ce qu'il y a de quasiment le plus facile à sauvegarder / répliquer, réinstaller. Je ne sais pas combien ici ont déjà eu une infra down à cause des DNS, mais c'est vraiment bien le seul soucis dont je n'entends jamais parler en interne.
Jusqu'à y a encore quelques années, le secondaire était d'ailleurs un vieux céleri avec 256 Mo de RAM et il gérait plus 40.000 domaines sans problèmes et sans charge.
Pour les risques de compromission : utilisez 2 distribs et versions différentes sur les primaire et secondaire + backup externe unique vérouillé à chaque modification : ça marche très bien également.
amicalement,
Yop,
On Tue, Aug 20, 2013 at 06:07:30PM +0200, Laurent Caron (Mobile) wrote:
christophe.casalegno@digital-network.net a écrit :
Bonjour : remarque uniquement valable pour ceux qui disposent d'infrastructures elles même réparties sur plusieurs AS. Aucun intérêt pour les autres (si le réseau est HS, les dns ne répondront plus, pas plus que le reste de l'infrastructure).
Ça permet de ne pas avoir un NXDOMAIN à chaque mail par exemple.
Ce n'est pas un NXDOMAIN si les serveurs DNS ne répondent pas, c'est juste une erreur temporaire vu du MTA.
Sylvain
Je viens de regarder les domaines qu'on héberge, j'ai moins de 10 domaines qui ont pas d'enregistrement hors de notre infrastructure, on ne peut pas envisager 1 sec de rendre un domaine inaccessible au risque de priver nos confrères de pouvoir faire fonctionner leurs services.
Cela me semble donc évident de n'avoir qu'un seul dns chez nous et en avoir pour le moment 2 en dehors de notre infra, tous connectés ipv4 et v6. Ça nous fait 3 dns bientôt 4 mais on peine à trouver des prestataires vps ou dédiés en dual stack ipv4/v6 où le v6 n'est pas juste un gadget...
Salut,
Le 20 août 2013 à 20:24, Wallace wallace@morkitu.org a écrit :
Je viens de regarder les domaines qu'on héberge, j'ai moins de 10 domaines qui ont pas d'enregistrement hors de notre infrastructure, on ne peut pas envisager 1 sec de rendre un domaine inaccessible au risque de priver nos confrères de pouvoir faire fonctionner leurs services.
Cela me semble donc évident de n'avoir qu'un seul dns chez nous et en avoir pour le moment 2 en dehors de notre infra, tous connectés ipv4 et v6. Ça nous fait 3 dns bientôt 4 mais on peine à trouver des prestataires vps ou dédiés en dual stack ipv4/v6 où le v6 n'est pas juste un gadget...
Ca se trouve, suffit de demander. Après si tu veux payer ton VPS a 1euros c'est sur... que l'ipv6 ils en on rien a foutre.
Je peux donner un exemple : mon asso fait du V6 depuis des années, et hetzner.de en font aussi. D'ailleurs c'est la qu'on peux voir des box "pas cher(tm)" pour fais un secondary mx + dns avec du V4 et V6...
Xavier
Hello,
Le 20 août 2013 à 18:07, Laurent Caron (Mobile) lcaron@unix-scripts.info a écrit :
christophe.casalegno@digital-network.net a écrit :
Voilà ma petite expérience :
- les dns ne devant pas tous se trouver sur le même AS, il faut
logiquement en mettre un peu partout sur la toile pour la résilience
de
votre infra dns
Bonjour : remarque uniquement valable pour ceux qui disposent d'infrastructures elles même réparties sur plusieurs AS. Aucun intérêt pour les autres (si le réseau est HS, les dns ne répondront plus, pas plus que le reste de l'infrastructure).
Ça permet de ne pas avoir un NXDOMAIN à chaque mail par exemple.
... et avoir un backup MX hors site, un pauvre celeron ou ATOM (cf autre mail) suffit largement pour avoir un backup MX propre qui permet accessoirement de rediriger le mail sur un <machin> en cas de grosse catastrophe.
Xavier
Hello,
Le 20 août 2013 à 12:33, Wallace wallace@morkitu.org a écrit :
(...)
- il faut aussi les nommer avec des tld différents si vous mettez tout
sur un seul tld ou plusieurs gérés par les mêmes entités administrative en cas de plantage de leurs côté tout tombe
Dans ce cas, voir aussi les dépendances de tld aux autres tld.
Exemple connu : .fr dépend à 100% du .net.
Donc si sur ton domaine tu met des NS sur du .net et du .fr et que tu crois que tu as une résilience -> #fail.
A noter aussi.... - avoir des OS différent (leap second error de Linux / pas sur FreeBSD) - avoir des version des logiciels DNS différents eg pas du bind 9 partout... pour éviter aussi les erreurs de code (cette partie est des fois difficile a mettre en place, plus que la partie OS, allez demander a un admin qui fait pas que du DNS de maitriser bind, pdns et nsd...).
(...)
Avec tous ces points, on est parti sur du Bind avec fichiers à plat, c'est clairement ce qui tient le mieux la charge y compris en cas de ddos, ça claque bien plus haut que pdns / sql. Par contre on voulait pouvoir gérer avec une interface web principalement pour éviter les erreurs de syntaxe à 4h du mat un dimanche en astreinte, même avec plus de 10 ans d'xp on fait encore ces conneries de temps en temps.
Perso j'aime bien aussi les fichiers a plat, dans l'interface web se viande ou que le serveur mysql est fracassé, on est content de vi thezone.com.file.
L'interface montre à la façon PdnsAdmin une vue synthétique de la zone mais où les modifications ne sont pas instantanées, pdnsadmin propage directement en base et si vous avez fait une boulette c'est immédiat. Là l'interface vérifie la zone, la prépare en fichier à plat dans un coin, la teste avec un bind local si le reload se fait correctement, si oui pousse les fichiers sur les différents serveurs dns, vérifie les numéros de série des zones plus le hash des fichiers. Si tous les serveurs sont bons reload des zones modifiées.
Elle est dispo qq part ton interface ?
/Xavier
Salut,
On Wed, 21 Aug 2013 12:51:52 +0200 Xavier Beaudouin kiwi@oav.net wrote:
| Le 20 août 2013 à 12:33, Wallace wallace@morkitu.org a écrit : | | (...) | | > - il faut aussi les nommer avec des tld différents si vous mettez tout | > sur un seul tld ou plusieurs gérés par les mêmes entités administrative | > en cas de plantage de leurs côté tout tombe | | Dans ce cas, voir aussi les dépendances de tld aux autres tld. | | Exemple connu : .fr dépend à 100% du .net. | | Donc si sur ton domaine tu met des NS sur du .net et du .fr et que tu crois que tu as une résilience -> #fail.
grep -i root-servers.net named.ca
. 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:BA3E::2:30 . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201 . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 . 3600000 NS D.ROOT-SERVERS.NET. ...
dig -t ns fr. @h.root-servers.net.
;; AUTHORITY SECTION: fr. 172800 IN NS d.ext.nic.fr. fr. 172800 IN NS d.nic.fr. fr. 172800 IN NS e.ext.nic.fr. fr. 172800 IN NS f.ext.nic.fr. fr. 172800 IN NS g.ext.nic.fr.
;; ADDITIONAL SECTION: d.ext.nic.fr. 172800 IN A 192.5.4.2 d.nic.fr. 172800 IN A 194.0.9.1 e.ext.nic.fr. 172800 IN A 193.176.144.22 f.ext.nic.fr. 172800 IN A 194.146.106.46 g.ext.nic.fr. 172800 IN A 194.0.36.1 d.ext.nic.fr. 172800 IN AAAA 2001:500:2e::2 d.nic.fr. 172800 IN AAAA 2001:678:c::1 e.ext.nic.fr. 172800 IN AAAA 2a00:d78:0:102:193:176:144:22 f.ext.nic.fr. 172800 IN AAAA 2001:67c:1010:11::53 g.ext.nic.fr. 172800 IN AAAA 2001:678:4c::1
Donc a 1ere vue je ne capte pas le pb...
Manuel
-- ______________________________________________________________________ Manuel Guesdon - OXYMIUM
Manuel Guesdon ml+frsag@oxymium.net : [...]
Donc a 1ere vue je ne capte pas le pb...
[...]
dig -t ns fr. @h.root-servers.net.
^^^^^^^^^^^^^^^^^^^
Si le .net ne répond plus pendant assez longtemps, là, forcément, ceux qui survivent risquent de constater un fonctionnement un tantinet dégradé.
+--On 22 août 2013 07:35:24 +0200 Francois Romieu romieu@fr.zoreil.com wrote: | Manuel Guesdon ml+frsag@oxymium.net : | [...] |> Donc a 1ere vue je ne capte pas le pb... | [...] |> > dig -t ns fr. @h.root-servers.net. | ^^^^^^^^^^^^^^^^^^^ | | Si le .net ne répond plus pendant assez longtemps, là, forcément, ceux | qui survivent risquent de constater un fonctionnement un tantinet | dégradé.
Pas vraiment, y'a des glues pour ça, sinon, ça serait compliqué.
Hello,
Le 22 août 2013 à 09:27, Mathieu Arnold mat@mat.cc a écrit :
+--On 22 août 2013 07:35:24 +0200 Francois Romieu romieu@fr.zoreil.com wrote: | Manuel Guesdon ml+frsag@oxymium.net : | [...] |> Donc a 1ere vue je ne capte pas le pb... | [...] |> > dig -t ns fr. @h.root-servers.net. | ^^^^^^^^^^^^^^^^^^^ | | Si le .net ne répond plus pendant assez longtemps, là, forcément, ceux | qui survivent risquent de constater un fonctionnement un tantinet | dégradé.
Pas vraiment, y'a des glues pour ça, sinon, ça serait compliqué.
Oui et non. S. Bortzmeyer m'avais parlé de ce problème lorsque je bossais à l'Afnic, bon j'avais pas creusé non plus (pas eu le temps, d'autres choses à faire), mais c'est "connu" en interne.
Je suis sûr qu'en lui demandant on aurais plus d'infos :)
Xavier
On Thu, 22 Aug 2013 10:44:22 +0200 Xavier Beaudouin kiwi@oav.net wrote:
| Le 22 août 2013 à 09:27, Mathieu Arnold mat@mat.cc a écrit : | | > +--On 22 août 2013 07:35:24 +0200 Francois Romieu romieu@fr.zoreil.com | > wrote: | > | Manuel Guesdon ml+frsag@oxymium.net : | > | [...] | > |> Donc a 1ere vue je ne capte pas le pb... | > | [...] | > |> > dig -t ns fr. @h.root-servers.net. | > | ^^^^^^^^^^^^^^^^^^^ | > | | > | Si le .net ne répond plus pendant assez longtemps, là, forcément, ceux | > | qui survivent risquent de constater un fonctionnement un tantinet | > | dégradé. | > | > Pas vraiment, y'a des glues pour ça, sinon, ça serait compliqué. | | Oui et non. S. Bortzmeyer m'avais parlé de ce problème lorsque je bossais à l'Afnic, bon j'avais pas creusé non plus (pas eu le temps, d'autres choses à faire), mais c'est "connu" en interne. | | Je suis sûr qu'en lui demandant on aurais plus d'infos :)
Il est en low bp mais il a répondu sur twitter: @mguesdon: @bortzmeyer Ch'tite question: sur FRSAG on parle de la dependence du .fr au .net. vrai ou faux ? Si oui comment ?
@bortzmeyer: @mguesdon Deux sous-questions : fiabilité et intégrité (détournement de .fr)
@bortzmeyer: @mguesdon Fiabilité : en raison de la colle envoyée par la racine, je pense que .fr ne dépend pas de .net
@bortzmeyer: @mguesdon Intégrité : c'est à ça que sert #DNSSEC.
@bortzmeyer: @mguesdon Sur cette notion de dépendance DNS, voir aussi la première étude citée en http://www.bortzmeyer.org/dns-vulnerabilites.html
Manuel
-- ______________________________________________________________________ Manuel Guesdon - OXYMIUM
On Thu, 22 Aug 2013 07:35:24 +0200 Francois Romieu romieu@fr.zoreil.com wrote:
| Manuel Guesdon ml+frsag@oxymium.net : | [...] | > Donc a 1ere vue je ne capte pas le pb... | [...] | > > dig -t ns fr. @h.root-servers.net. | ^^^^^^^^^^^^^^^^^^^ | | Si le .net ne répond plus pendant assez longtemps, là, forcément, ceux | qui survivent risquent de constater un fonctionnement un tantinet dégradé.
Certe mais les [a-h].root-servers.net. sont les serveurs de la racine ("."):
dig -t ns .
. 361720 IN NS k.root-servers.net. . 361720 IN NS g.root-servers.net. . 361720 IN NS l.root-servers.net. . 361720 IN NS e.root-servers.net. . 361720 IN NS h.root-servers.net. . 361720 IN NS m.root-servers.net. . 361720 IN NS a.root-servers.net. . 361720 IN NS b.root-servers.net. . 361720 IN NS i.root-servers.net. . 361720 IN NS d.root-servers.net. . 361720 IN NS f.root-servers.net. . 361720 IN NS c.root-servers.net. . 361720 IN NS j.root-servers.net. et leur IP est codé en dur dans les fichiers des résolveurs. Si plus aucun ne répond (ou si un grand nombre ne répondent plus) ben tous tld seront impactés. Après si c'est un problème de glue record spécifique sur le fr. on peut imaginer qu'il peut arriver la même chose sur d'autres tld.
Manuel
-- ______________________________________________________________________ Manuel Guesdon - OXYMIUM mguesdon@oxymium.net 4 rue Auguste Gillot - 93200 Saint-Denis - France Standard: 0 811 093 286 (Cout d'un appel local) Fax: +33 1 7473 3971 LD Support: +33 1 7473 3973 LD: +33 1 7473 3980
+--On 22 août 2013 11:59:52 +0200 Manuel Guesdon ml+frsag@oxymium.net wrote: | et leur IP est codé en dur dans les fichiers des résolveurs.
Elle l'est, et c'est uniquement dans le cas où le fichier hints n'est pas présent, et ce n'est de toutes façons utilisé qu'au lancement, les resolvers utilisent ces indices pour récupérer une version à jour. (Procédure appelée le priming.)
On Thu, 22 Aug 2013 12:06:02 +0200 Mathieu Arnold mat@mat.cc wrote:
| +--On 22 août 2013 11:59:52 +0200 Manuel Guesdon ml+frsag@oxymium.net | wrote: | | et leur IP est codé en dur dans les fichiers des résolveurs. | | Elle l'est, et c'est uniquement dans le cas où le fichier hints n'est pas | présent, et ce n'est de toutes façons utilisé qu'au lancement,
Par codé en dur, je voulais dire en dur dans le fichier hints :-) Celui ci devant (enfin, c'est conseillé) être mis à jour quand il y a des changements (rares heureusement). Exemple: http://marc.info/?l=nanog&m=107545493926210
| les resolvers utilisent ces indices pour récupérer une version à jour. | (Procédure appelée le priming.)
Tiens, je ne savais pas; tu as une ref la dessus ?
Manuel
-- ______________________________________________________________________ Manuel Guesdon - OXYMIUM
Le 21/08/2013 12:51, Xavier Beaudouin a écrit :
L'interface montre à la façon PdnsAdmin une vue synthétique de la zone mais où les modifications ne sont pas instantanées, pdnsadmin propage directement en base et si vous avez fait une boulette c'est immédiat. Là l'interface vérifie la zone, la prépare en fichier à plat dans un coin, la teste avec un bind local si le reload se fait correctement, si oui pousse les fichiers sur les différents serveurs dns, vérifie les numéros de série des zones plus le hash des fichiers. Si tous les serveurs sont bons reload des zones modifiées.
Elle est dispo qq part ton interface ?
Malheureusement non on n'a pas prévu de le distribuer pas qu'on est pas envie, juste que je trouve que c'est super spécifique à notre infra et aux circuits tortueux pour atteindre les serveurs dns pour faire les modifs.
Sur le principe on était parti sur le fait de forker ProBind http://probind.org/ qui ne semble plus maintenu mais on s'est vite rendu compte du côté archaïque du soft donc on s'est juste inspiré sur le fait d'avoir une édition en deux temps, en gros tu prépares ta zone, tu peux désactiver des enregistrements temporairement, on peut gérer les ttl par enregistrements, on check avant de pousser, on pousse et on reload les zones, si ko retour arrière auto.
On ajouté pas mal de chose pour être propre pour l'ipv6 y compris en reverse automatique si on coche la case qui va bien dans le AAAA, ProBind gère bien cela en A mais pas en AAAA.
Il nous faudrait implémenter dnssec pour que cela devienne vraiment intéressant mais malgré les bons papiers de Stéphane on a pas tout bien assimilé, faudrait qu'on monte une infra de test pour voir ce qu'on doit faire niveau sysadm.
-
Benjamin Schilz -
christophe.casalegno＠digital-network.net -
Dominique Rousseau -
Francois Romieu -
Greg -
Jean Weisbuch -
Jonathan Leroy -
Jérémy SPIESSER -
Laurent Caron (Mobile) -
Manuel Guesdon -
Mathieu Arnold -
Olivier Doucet -
Sebastien Caps -
Sylvain Donnet -
Sylvain Rochet -
Sébastien FOUTREL -
Wallace -
Xavier Beaudouin