Bonjour,

Le 14/04/2020 à 09:08, Pierrick CHOVELON a écrit :
-> 1 master avec plusieurs slaves qui partagerait une VIP histoire d'avoir de la redondances ?


Déjà dit par Phil Regnauld, une unique VIP sur un service DNS faisant autorité , c'est plutôt des contraintes inutiles à mon sens aussi.


-> 1 seul master avec 1 seul slave ?


oui par exemple (ou 1 master + n slaves sur n préfixes différents) ou un outil qui génère le contenu de la zone et le pousse directement sur tous les serveurs...

Si j'ai bien compris, ce serait une zone à visibilité purement interne de votre entité (pour modifier les entrées de celles proposées par le client).

Dans ce cas, la répartition multi-préfixes / AS parait moins critique mais ça reste nécessaire de cibler des infra différenciées pour avoir de la résilience...


-> Faut-il plutôt gérer une zone/*domaine.fr <http://domaine.fr>*/ ou plutôt à chaque fois gérer la zone spéfifique /*application.domaine.fr <http://application.domaine.fr>*/ ? J'aurai tendance à dire la première. C'est ce que j'ai fait sur mes tests : j'arrivais à résoudre /application.domaine.fr <http://application.domaine.fr>/ mais pas /domain.fr <http://domain.fr>/. Probablement une mauvaise conf.


Je dirai que ça dépend si tout le contenu de domaine.fr est à visibilité interne uniquement ou si des enregistrements restent publics.

ça peut devenir ingérable d'avoir à faire le tri entre les enregistrements gérés par le client et d'autres par votre instance. Il vaut mieux cibler au plus restreint possible selon le cas.

Comment ce sera géré sur les resolvers ? ils seront slaves ? ou utiliseront-ils un forward ?


-> Des outils pour gérer tous les fichiers de zones ? Des astuces pour rendre cette gestion le plus logique/simple possible ?

PowerAdmin (ou phpIPAM par exemple) + PowerDNS pour gérer le SOA et alimenter le master Bind ?

ou plus simple une gestion de fichiers plat de zones orchestrée via puppet ou ansible par exemple ?


Bon courage

--
Jérôme BERTHIER


---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à