Set-OPS-Public/docs/dns-interne.md

2 KiB

DNS interne

Le service DNS interne est la premiere capacite de plateforme.

Groupes

serveur_powerdns -> service DNS central PowerDNS Authoritative
client_dns       -> integration cliente DNS

client_dns depend de serveur_powerdns dans docs/dependances-groupes.yml.

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.

Clients DNS

Le role client_dns valide :

  • qu'un serveur serveur_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 :

client_dns_apply: true
client_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 exemple.internal resoluble ;
  • enregistrement ns1.exemple.internal resoluble ;
  • enregistrements des hotes actifs presents ;
  • serial de zone attendu ;
  • latence de resolution.