Les avantages d’une BDD pour la gestion du DNS
- Posted by LivingObjects
Les avantages d’une BDD pour la gestion du DN
Mettre 172.16.1.1 dans la barre du navigateur au lieu de « http://mon-intranet.local » donne un certain prestige à l’administrateur système lorsqu’un œil non expert regarde par-dessus son épaule. Mais, avec tout le respect que je dois à ma profession, notre mémoire n’est pas infaillible. Retenir des dizaines, voire beaucoup plus, d’adresses IP est impossible.
Les limites d’un serveur DNS implémenté avec BIND
Le serveur DNS (Domain Name System) est le dictionnaire qui permet de transformer les adresses IP en noms. L’implémentation classique d’un DNS sous GNU/Linux, utilise BIND (Berkeley Internet Name Domain) conçu au début d’Internet. L’administrateur réseau référence l’intégralité de son parc machines dans un fichier plat, en respectant une nomenclature précise imposé par BIND.
BIND est depuis longtemps le serveur DNS incontournable du monde Unix. Il est peu gourmand en ressource, performant, sécurisé…
Mais le format de fichier qu’il utilise n’est pas facilement manipulable par programmation (JSON, XML, YAML…). Il est donc complexe à exploiter en dehors des usages classiques d’un serveur DNS, et c’est de cela que nous parlons !
Prenons un exemple : Requêter un serveur DNS sous BIND, c’est comme appeler le 118 218 pour connaitre un numéro de téléphone : Il nous faut connaitre le nom, prénom, ville, ….de la personne recherchée. Or dans l’exploitation d’un nombre important d’équipements, il est impossible de connaitre toutes les caractéristiques de toutes les machines. Lorsqu’on réalise une requête, il nous faut en retour, une liste des serveurs « approchant » les caractéristiques qu’on a indiqué, pour reconnaitre celui qui nous convient. Comme si on feuilletait les pages jaunes à la rubrique « plombier ».
Implémentation du DNS sous PowerDNS
Notre approche se base sur PowerDNS avec un backend MySQL, une interface d’administration et une API maison développée en Python/Flask.
L’interface d’administration permet à toute personne ayant les droits, de consulter la liste complète des machines (écran de gauche ci-dessous) et aux administrateurs de réaliser les opérations de CRUD sur les machines (écran de droite ci-dessous).
Cette gestion de droits avec les logs associés permet de vérifier rapidement les modifications apportées et éventuellement de faire des retours arrière en cas d’erreur (l’Admin Sys. étant un être humain…. jusqu’à preuve du contraire.). Le versionning sous Git des fichiers BIND aurait été possible mais le suivi des historiques par ce procédé est plus laborieux.
Écrans de visualisation :
Une gestion simplifiée du parc machines
Voici quelques exemples basés sur notre API :
-
- Génération des fichiers “hosts” Ansible.
Quoi de plus fastidieux que de maintenir, malgré le versionning, un fichier hosts Ansible avec plusieurs centaines de lignes, alors qu’un simple script permet de le générer automatiquement à tout moment depuis les enregistrements actualisés du DNS.
- Génération des fichiers “hosts” Ansible.
-
- Ajout automatique des sauvegardes pour les nouveaux hôtes.
Nous utilisons BackupPC pour les serveurs GNU/Linux. Dès qu’un hôte est déployé et ajouté au DNS, BackupPC en a connaissance via une interrogation régulière de l’API. Aucune intervention de notre part n’est nécessaire, en dehors d’un contrôle de routine régulier.
- Ajout automatique des sauvegardes pour les nouveaux hôtes.
-
- Autocomplétion Bash/ZSH (client SSH, ping…).
Lorsqu’on cherche un élément, on utilise les capacité d’autocompletion de la base de données. Trois lettres à taper, un chiffre + TAB et le nom complet de l’hôte auquel je veux me connecter apparait. Très pratique pour les nouveaux arrivants, comme pour les plus anciens.
- Autocomplétion Bash/ZSH (client SSH, ping…).
-
- Mise à jour automatique de l’inventaire du parc.
Tout comme pour le fichier hosts Ansible, la connexion du système à Rudder permet une découverte automatique des éléments du parc, et la mise à jour associée. Il n’est plus nécessaire de mettre à jour manuellement des informations « réseaux » lors d’un changement de topologie.
- Mise à jour automatique de l’inventaire du parc.
Sauf si mémoriser le parc machine constitue pour vous le meilleur entrainement à l’exercice de votre mémoire, la solution que nous avons adoptée nous parait plus fiable pour exploiter sereinement un parc machines important.
Références :
#PowerDNS #MySQL #Ansible #Rudder #BackupPC
0 comments on Les avantages d’une BDD pour la gestion du DNS