PowerDNS

Grâce aux vues dns.domains et dns.records, on lui donne à voir exactement ce qu'il veut, il n'y a donc rien à configurer d'autres que les infos de connexion à la base, c'est le bonheur.

On accepte & propage les modifications de certains champs des vues que PowerDNS met à jour à l'occasion, grâce à des RULEs : domains.last_check, domains.notified_serial. Et c'est tout, a priori.

master / slave

Il est possible de configurer des serveurs de nom secondaires, pour les zones DNS hébergées, grâce au champ secondaire de la table domains.

Héberger des sites/mails/etc. sans en héberger le DNS

Un domaine dont nous hébergeons des sites et/ou mails sans pour autant en héberger le DNS est stocké dans la table domains, et a type = 'EXTERNAL'. Ensuite :

s'il s'agit d'héberger des sites dessus (càd quand un A pointe vers notre IP), on a besoin d'un enregistrement DNS "bidon", de type A, dans la table dns_records ;
s'il s'agit d'héberger seulement le mail, pas besoin d'enregistrement DNS "bidon" ;
la vue dns.records cache à PowerDNS les enregistrements dont le domaine parent a pour type EXTERNAL.

Champs et enregistrements générés dynamiquement

SOA

On doit donner à manger à PowerDNS un enregistrement de type SOA (Start of Authority) pour chaque domaine dont nous sommes maîtres au niveau DNS. Son champ content, en version de base, a cette tronche :

<serveur de nom primaire> <hostmaster> <numéro de serie>
    = FQDN                 = e-mail

franGiPane les génère dynamiquement, dans la vue dns.records.

Pour le serial :

on prend le domains.last_changed de la zone
Quand on insère/modifie/supprime un enregistrement DNS, un trigger (maj_domains_last_changed) met à jour le champ last_changed du domaine parent.
En interne, on utilise le type SQL timestamp pour domains.last_changed, c'est fait pour ; à partir de ça, on lui donne, dans la vue dns.records, l'EPOCH de ce timestamp.

NS

Ces noms indiquent quels sont les serveurs responsables d'un nom de domaine.

Pour chaque domaine hébergé au niveau DNS (càd sur lequel nous sommes maîtres), on remplit un champ secondary qui peut être NULL ou contenir un FQDN.

Ensuite, la vue dns.records (qu'on donne à manger à PowerDNS) se charge, à partir des champs susmentionnés, de fabriquer de toute pièce les enregistrements de type NS correspondants :

On génère un NS par serveur maître/secondaire sur la zone (i.e. domaine, ds notre cas), y compris boum.org, sans oublier le secondaire de boum.org (gandi).
On ne génère pas de NS pour les domaines de type EXTERNAL.

prio

Lorsqu'un MX est inséré dans la table dns_records sans qu'une prio soit spécifiée, un trigger lui assigne la plus petite prio (10, 20, 30...) disponible.

MX

Pour que notre DNS soit propre, on génère un enregistrement de type MX pour les domaines :

qu'on gère au niveau DNS ;
pour lesquels aucun MX n'est entré dans dns_records.

Traduction : lorsqu'on n'entre pas explicitement d'enregistrement MX pour un domaine, par défaut, on gère son MX.

Limitations du modèle

franGiPane ne permet pas d'utiliser des serveurs MX secondaires.
franGiPane ne permet pas de gérer les PTR (reverse) des IPs du serveur : c'est censé être fait en amont, par les gens qui gèrent notre bloc d'IP