Décomposer le parcours d’une requête
J’ai séparé quatre fonctions dans mon architecture : la résolution de noms par BIND, la publication de la page par Apache, le code PHP et le stockage MySQL. J’ai représenté le parcours du navigateur dans un schéma : interrogation DNS en UDP 53, accès au site en TCP 80, puis requête du serveur web vers MySQL en TCP 3306 avant la réponse au client. Cette vue m’a servi à relier les paramètres de chaque service aux flux à autoriser entre les machines.
Configurer les noms et l’hôte virtuel
Dans BIND, j’ai déclaré une zone directe et une zone inverse comme zones maîtres, chacune associée à son fichier. J’ai renseigné le SOA, le NS et les enregistrements A du nom racine, de www, du serveur de noms et du serveur SQL. La racine et www désignent le même hôte web ; SQL et DNS utilisent des adresses distinctes. J’ai ajouté les PTR dans la zone inverse, avec deux noms pour l’adresse web : cette configuration ne garantit donc pas un nom inverse unique. Côté Apache, j’ai associé le nom www à un VirtualHost *:80 et au répertoire de l’application avec DocumentRoot.
Définir l’accès de PHP à MySQL
J’ai renseigné dans le fichier PHP le nom du serveur SQL, la base et le port 3306. Mon script SQL crée le compte applicatif en limitant son origine à l’hôte web, puis lui attribue des droits sur cette seule base. J’ai ainsi encadré l’origine des connexions, mais les opérations restent larges : le script utilise GRANT ALL PRIVILEGES. Les droits seraient à réduire aux besoins réels de l’application avant un usage en production. La création de la base elle-même n’est pas incluse dans ce script.
Préparer les contrôles de fonctionnement
J’ai produit les configurations et le schéma de flux. Pour valider leur fonctionnement ensemble, je suivrais le même parcours : résolution du nom public, sélection du bon hôte virtuel, connexion du PHP au serveur SQL, puis contrôle des droits du compte. Je n’ai pas de résultats DNS, HTTP ou SQL joints à ce travail pour confirmer ce parcours de bout en bout.