Daniel Allaire ac85278366 preuve : P34 — chaque document declare son lecteur (D-74)

La refonte de ce matin posait une convention. Une convention qu'on n'outille
pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique
au corpus documentaire.

Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32
autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus
utile du depot au §6 de autorisation.md.

Les 38 le declarent desormais, lecteur determine document par document et non
colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie,
gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur
externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE).

Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la
premiere page ajoutee : un document qui s'annonce genere, et un fragment sans
titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main
n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche
frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation
dans leur corps — d'etre exemptes a tort.

Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en
nommant deux documents que mon inventaire avait manques (docs/audit/). Puis
test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la
nommant ; restauree -> OK.

Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en
revue ; elle garantit qu'on a du y penser.

P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md
annoncaient encore 30 preuves).

Verifie : prouver.py 0 (34 OK), plan-recette inchange.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-10 07:53:04 -04:00

2.7 KiB

Raw Blame History

DNS interne

Pour qui : le mainteneur du DNS interne.

Le service DNS interne est la premiere capacite de plateforme.

Plancher de resolution independant du DNS. Le socle (hosts_statiques, dans serveur_debian) genere /etc/hosts sur chaque VM depuis l'inventaire : tout l'ecosysteme se resout par nom meme serveur DNS eteint (et au bootstrap, avant que PowerDNS ne soit la). PowerDNS devient une commodite (zone, externe, dynamique), plus un point de defaillance. Le resolveur local client_unbound est optionnel (opt-in, avec bascule validee) : sans lui, le plancher /etc/hosts suffit.

Groupes

serveur_powerdns -> service DNS central PowerDNS Authoritative
client_unbound   -> resolveur local optionnel (opt-in, bascule validee)

client_unbound (résolveur local optionnel) peut viser PowerDNS en stub-zone + récursion.

Zone initiale

La zone initiale est :

exemple.internal

Elle est definie dans :

instance/inventories/production/group_vars/serveur_powerdns.yml

Enregistrement automatique

Le role serveur_powerdns genere la zone a partir de l'inventaire.

Les hotes qui remplissent ces conditions sont ajoutes automatiquement :

hote dans hotes_actifs
ansible_host defini

Exemple :

web-frontal-01 ansible_host=10.0.2.31
-> web-frontal-01.exemple.internal A 10.0.2.31

Les enregistrements additionnels explicites sont dans serveur_powerdns_records.

Backend PowerDNS

Le premier jalon utilise le backend BIND de PowerDNS.

Raison :

pas de dependance prematuree a PostgreSQL ;
zone lisible et generee par Ansible ;
idempotence simple ;
bon point de depart pour la supervision.

Quand serveur_postgresql sera stable, il sera possible de migrer vers un backend SQL si le besoin operationnel le justifie.

Résolveur local (optionnel)

Le role client_unbound (opt-in) installe un résolveur récursif local qui, en stub-zone, délègue les noms internes à PowerDNS et récurse le reste.

La bascule du resolver local est protegee (le role valide qu'Unbound répond AVANT de basculer /etc/resolv.conf) :

client_unbound_apply: true
client_unbound_confirm: true

Sans ces deux variables, le role prépare Unbound mais ne modifie pas /etc/resolv.conf.

Cette protection est volontaire : une mauvaise configuration DNS peut couper la resolution de noms.

Surveillance a prevoir

Les premiers checks utiles :

service pdns actif ;
port UDP/TCP 53 disponible ;
SOA de exemple.internal resoluble ;
enregistrement ns1.exemple.internal resoluble ;
enregistrements des hotes actifs presents ;
serial de zone attendu ;
latence de resolution.

2.7 KiB Raw Blame History