s-informer-sur-la-tech-www/articles/2026/Piloter dnsmasq avec une interface PHP & SQLite.md

title, description, tags, date, lastmod, type, category, status

title	description	tags	date	lastmod	type	category	status
IPAM Web : piloter dnsmasq avec une interface PHP et SQLite	Si dnsmasq est l'un des serveurs DNS/DHCP les plus légers et robustes pour les réseaux locaux, sa configuration passe traditionnellement par l'édition de fichiers textes via SSH. Pour simplifier l'exploitation quotidienne — sans pour autant sortir l'artillerie lourde — nous avons développé une suite de scripts PHP permettant de gérer son infrastructure réseau depuis un navigateur.	dnsmasq dns dhcp gui	2026-02-27 22:42	2026-02-27 23:56		Guide	brouillon

IPAM Web : piloter dnsmasq avec une interface PHP et SQLite

IPAM est l'acronyme de Internet Protocol Address Management (en français : Gestion des adresses IP). C'est une méthodologie, souvent accompagnée d'un logiciel qui permet de planifier, de suivre et de gérer l'espace d'adressage IP au sein d'un réseau. L'inventaire, la corrélation (DNS/DHCP) et la détection des conflits sont les 3 piliers qui définissent l'IPAM.

dnsmasq s’est imposé comme une référence pour fournir des services DNS et DHCP sur des réseaux locaux grâce à sa simplicité, sa faible empreinte et sa grande stabilité. En contrepartie, son administration reste historiquement centrée sur l’édition manuelle de fichiers de configuration, ce qui peut rapidement devenir chronophage et source d’erreurs lorsque l’infrastructure évolue.

L’interface IPAM Web répond à ce besoin : proposer une couche d’administration graphique légère, sans remettre en cause la philosophie minimaliste de dnsmasq. L’objectif n’est pas de remplacer l’outil, mais d’en améliorer l’ergonomie et la fiabilité opérationnelle.

Projet : https://git.abonnel.fr/cedricAbonnel/dnsmasq-gui

---

Une approche : conserver la simplicité, ajouter de l’intelligence

Le système transforme un serveur Linux standard en véritable solution d’IP Address Management.
La logique est volontairement simple :

• SQLite stocke l’état de référence (DNS, réservations, métadonnées).

• Des scripts PHP génèrent les fichiers de configuration.

• dnsmasq reste l’unique moteur d’exécution.

Cette séparation garantit que l’on conserve une infrastructure transparente, lisible et facilement réversible : les fichiers produits restent compatibles avec une exploitation classique en ligne de commande.

---

Gestion DNS : un référentiel unique et cohérent

Le module admin_dns.php introduit une gestion centralisée de la résolution locale.

Plutôt que de disperser l’information dans différents fichiers, chaque enregistrement est stocké en base. Cette approche permet d’assurer la cohérence des données, de limiter les doublons et de tracer les modifications.

Le système génère ensuite automatiquement un fichier dédié contenant les directives address=/nom/IP, directement exploitables par dnsmasq.
La gestion de la résolution inverse est intégrée : les enregistrements PTR sont créés automatiquement afin de garantir une correspondance bidirectionnelle entre noms et adresses, indispensable pour le diagnostic réseau et certains usages applicatifs.

---

DHCP : relier observation et configuration

Le module admin_dhcp.php se positionne comme un outil d’exploitation plutôt que de simple configuration.

Il analyse en continu le fichier dhcp.leases afin de refléter l’état réel du réseau : machines présentes, adresses attribuées, durées de bail.
À partir de cette observation, il devient possible de transformer un bail dynamique en réservation permanente en une seule action, ce qui simplifie fortement la stabilisation d’un parc.

Cette logique réduit les opérations manuelles et limite les risques d’erreur lors de la création de réservations, puisque les informations (MAC, IP, hostname) proviennent directement de la réalité du réseau.

---

Visibilité réseau : confronter le modèle et le réel

Le module free-ip.php apporte une dimension d’audit souvent absente des outils légers.

Plutôt que de se baser uniquement sur les fichiers de configuration, il confronte :

• le plan d’adressage théorique (DNS et DHCP) ;

• l’état observé via un scan ARP.

Cette corrélation permet d’identifier immédiatement :

• les équipements présents mais non déclarés ;

• les incohérences de configuration ;

• les plages réellement disponibles.

On obtient ainsi une vision fiable du réseau, utile pour préparer des déploiements ou diagnostiquer des conflits d’adresses.

---

Architecture et modules

La solution est structurée de manière modulaire afin de rester lisible et extensible.

Script	Fonction	Rôle opérationnel
index.php	Point d’entrée	Accès aux modules et vue synthétique
admin_dns.php	Gestion DNS	Création et export des enregistrements
admin_dhcp.php	DHCP	Visualisation des baux et réservations
free-ip.php	Audit IP	Détection des adresses utilisées/libres
ddns.php	DNS dynamique	Mise à jour via API sécurisée (pas encore implémenté)
migrate_to_sqlite.php	Initialisation	Import des configurations existantes
configurer-dnsmask.php	Paramétrage	Gestion des options globales

---

Modèle de sécurité : contrôle fin des privilèges

L’interface doit pouvoir écrire dans /etc/dnsmasq.d/ tout en évitant d’exposer des privilèges root complets au serveur web.

Le choix retenu repose sur l’utilisation ciblée de commandes autorisées via sudo, typiquement sudo tee pour l’écriture contrôlée de fichiers.
Cette approche limite la surface d’attaque tout en conservant une automatisation complète du cycle de configuration.

---

Positionnement de la solution

IPAM Web se situe volontairement entre deux mondes :

• plus ergonomique qu’une administration purement en ligne de commande ;

• plus léger et transparent qu’une solution IPAM d’entreprise.

Il permet de conserver la maîtrise totale de l’infrastructure tout en améliorant la fiabilité opérationnelle, la visibilité réseau et la rapidité d’intervention.

---

Pistes d’amélioration du projet

Le socle actuel remplit déjà efficacement son rôle d’interface d’exploitation. Les évolutions pertinentes consistent surtout à renforcer la fiabilité, la traçabilité et l’ouverture vers d’autres usages, tout en conservant la philosophie de simplicité.

Fiabilité et robustesse

La robustesse du système peut être accrue par l'introduction d'un mécanisme de validation "pre-flight". En isolant les modifications dans des fichiers éphémères avant déploiement, nous pouvons soumettre chaque itération à un test de cohérence applicatif. Ce garde-fou empêche toute corruption de la configuration active.

Parallèlement, la mise en place d'un archivage horodaté des états offre une capacité de restauration critique en cas de régression. Cette architecture gagne à être complétée par une abstraction des fichiers de configuration via Jinja2, séparant ainsi la "source de vérité" (données) de sa représentation technique (forme).

Journalisation et audit

L’ajout d’un journal applicatif structuré permettrait de tracer :

• qui a effectué une modification ;

• quand elle a été appliquée ;

• quelle était la valeur précédente.

Au-delà du diagnostic, cela transforme l’outil en véritable référentiel d’exploitation et facilite la conformité dans des environnements plus sensibles.

Modélisation réseau plus riche

Aujourd’hui centré sur les adresses IP et les noms, le modèle pourrait intégrer des notions supplémentaires :

• segments ou VLAN ;

• plages IP avec statut (réservé, dynamique, infrastructure, invités) ;

• métadonnées d’équipement (type, localisation, propriétaire).

Cette structuration rendrait la recherche et la visualisation beaucoup plus pertinentes, en rapprochant l’outil d’un IPAM complet tout en restant léger.

Visualisation et compréhension du réseau

Une représentation graphique simple (cartographie logique ou vue par plage IP) améliorerait la compréhension globale du réseau.
Sans aller vers une cartographie automatique complexe, une visualisation basée sur les données connues (réservations, baux, détection ARP) suffirait déjà à offrir une lecture immédiate de l’occupation.

API et automatisation

L’exposition d’une API REST documentée permettrait d’intégrer l’outil dans des workflows existants :

• scripts d’installation automatisés ;

• intégration avec un inventaire ou un outil de provisioning ;

• mise à jour dynamique depuis des équipements.

Le module DDNS existant constitue déjà une base naturelle pour cette ouverture mais n'est pas encore exploité. Il faudrait qu'il alimente une table machines dans notre base SQLite. Ainsi, notre tableau de bord index.php pourra afficher une liste complète de notre parc avec :

• Le nom de la machine.

• Sa dernière IP connue.

• Son système d'exploitation (extrait de hostnamectl).

• La date de sa dernière "vue" (Last Seen).

Sécurité applicative

Plusieurs axes peuvent renforcer la posture de sécurité :

• authentification forte (OIDC ou SSO) ;

• gestion de rôles (lecture seule, exploitation, administration) ;

• protection CSRF et durcissement des entrées utilisateur.

Ces éléments deviennent essentiels dès que l’outil dépasse un usage strictement personnel.

Expérience d’exploitation

Enfin, quelques améliorations ergonomiques ont un impact immédiat :

• recherche globale (IP, nom, MAC) ;

• actions rapides contextuelles ;

• indicateurs d’état (conflit IP, doublon DNS, incohérence PTR).

Ces fonctions réduisent le temps d’analyse et rapprochent l’outil d’une console d’exploitation quotidienne.

Gestion de l'Idempotence

Le script migrate_to_sqlite.php vide la table (DELETE FROM dns_records) à chaque lancement. C'est risqué.

Amélioration : Adoptez une logique de synchronisation :

1. Lire le fichier.

2. Comparer chaque ligne avec la base SQLite.

3. INSERT si nouveau, UPDATE si différent, et ne rien faire si identique. Cela évite de perdre des données si le script s'arrête en plein milieu.