Daniel Allaire
8f6de3ebe2
Registres (source unique): - docs/nomenclature.yml: domaines, VMID, plan d'adressage 10.1.0.0/16 segmente. - docs/bases-donnees.yml: bases applicatives (1 appli -> 1 base -> 1 owner -> 1 DSN). Roles de service: - Reseau/edge/PKI/mail: nginx, step_ca, sendmail. - Donnees/identite: postgresql (consommateur du registre BD), redis, openldap, keycloak. - Observabilite: prometheus, loki, grafana. - Supervision: icinga (coeur; Icinga Web 2 differe). Forge: forgejo. Integrations clientes: - clients_metriques, clients_journaux, clients_pki, clients_ldap, clients_smtp. Inventaire et outillage: - make inventaire-ui: refonte (cartes, theme sombre, onglets, vue Chaine VM->groupes-> playbooks->roles), saisie du provisioning, auto-proposition depuis la nomenclature, deploiement securise (verifier/deployer, jeton anti-CSRF, verrou, mot de passe vault), robustesse reseau (connexions fermees, favicon). - Makefile: cible verifier-deploiement; detection d'un group_vars de production chiffre. - Scission serveurs_web -> serveurs_web_frontaux/dorsaux; migration de l'adressage vers 10.1.x; retrait des hotes de test; planification des hotes; requirements.yml. Chaque role valide en --syntax-check et ansible-lint (profil production). Secrets references depuis Ansible Vault (jamais en clair); roles non testes live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
90 lines
2 KiB
Markdown
90 lines
2 KiB
Markdown
# DNS interne Chezlepro
|
|
|
|
Le service DNS interne est la premiere capacite de plateforme.
|
|
|
|
## Groupes
|
|
|
|
```text
|
|
serveurs_powerdns -> service DNS central PowerDNS Authoritative
|
|
clients_dns -> integration cliente DNS
|
|
```
|
|
|
|
`clients_dns` depend de `serveurs_powerdns` dans `docs/dependances-groupes.yml`.
|
|
|
|
## Zone initiale
|
|
|
|
La zone initiale est :
|
|
|
|
```text
|
|
chezlepro.internal
|
|
```
|
|
|
|
Elle est definie dans :
|
|
|
|
```text
|
|
inventories/production/group_vars/serveurs_powerdns.yml
|
|
```
|
|
|
|
## Enregistrement automatique
|
|
|
|
Le role `serveurs_powerdns` genere la zone a partir de l'inventaire.
|
|
|
|
Les hotes qui remplissent ces conditions sont ajoutes automatiquement :
|
|
|
|
```text
|
|
hote dans hotes_actifs
|
|
ansible_host defini
|
|
```
|
|
|
|
Exemple :
|
|
|
|
```text
|
|
web-frontal-01 ansible_host=10.1.15.31
|
|
-> web-frontal-01.chezlepro.internal A 10.1.15.31
|
|
```
|
|
|
|
Les enregistrements additionnels explicites sont dans `serveurs_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 `serveurs_postgresql` sera stable, il sera possible de migrer vers un backend SQL si le besoin operationnel le justifie.
|
|
|
|
## Clients DNS
|
|
|
|
Le role `clients_dns` valide :
|
|
|
|
- qu'un serveur `serveurs_powerdns` actif existe ;
|
|
- que la zone repond a une requete SOA ;
|
|
- que le nom de l'hote existe dans la zone.
|
|
|
|
La modification du resolver local est protegee :
|
|
|
|
```yaml
|
|
clients_dns_apply: true
|
|
clients_dns_confirm: true
|
|
```
|
|
|
|
Sans ces deux variables, le role valide les prerequis 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 `chezlepro.internal` resoluble ;
|
|
- enregistrement `ns1.chezlepro.internal` resoluble ;
|
|
- enregistrements des hotes actifs presents ;
|
|
- serial de zone attendu ;
|
|
- latence de resolution.
|