dns_records

Histoire de répliquer moins d'informations, on ne stocke, dans dns_records, que la partie du fqdn ajoutée à gauche du fqdn du domaine parent.

master / slave

On doit pouvoir être master, vu qu'on veut des serveurs DNS secondaires.

Pas besoin de la table supermasters (sert à être DNS secondaire aisément).

Si un jour on veut être nous-mêmes DNS secondaire, on fera une table supplémentaire, comme ça on ne mélange pas tout.

MX

franGiPane ne permet pas d'utiliser des serveurs MX secondaires.

Lorsque nous gérons le DNS et les mails, pas besoin de MX, donc il n'y a que 2 cas où l'on a un enregistrement de type MX dans la base :

domaine dont nous gérons les mails mais pas le DNS : 1 MX = nous
domaine dont nous gérons le DNS, mais pour lequel les mails sont gérés ailleurs : 1 ou plusieurs MX = nous (nous = fqdn gérés au niveau mail)

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

PowerDNS ne doit rien savoir d'un domaine s'il n'en est pas responsable. Sinon, on va au devant de problème de cohérence puisque notre machine n'aura plus les mêmes données que le reste du monde.

Pour autant, nous allons héberger, à l'occasion, des mails/sites/etc. de domains dont nous ne gérerons pas le DNS ; ces domains et enregistrements DNS doivent donc apparaître dans la base, tout en restant cachés aux yeux de PowerDNS. Nous indiquerons que le DNS d'un domaine n'est pas géré par nos soins en lui mettant domains.type='EXTERNAL'.

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 content, en version de base, a cette tronche :

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

Il n'est manifestement pas nécessaire de stocker ces enregistrements dans la table dns_records, vu qu'on peut aisément les générer dynamiquement.

Pour ce qui est des deux premiers champs, tout va bien :

serveur de nom primaire : on met 'boum.org'
hostmaster : on met 'hostmaster.' || domains.fqdn

Pour ce qui est du numéro de série (serial), c'est plus compliqué. Traditionellement, il a cette tronche :

          ____ année
         / ___ mois
        / / __ jour
       / / / _ version du jour (01, puis 02, ...)
      / / / /
   YYYYMMDDXX

Mais en vrai on peut mettre ce qu'on veut, du moment que la relation d'ordre classique sur les entiers marche, et du moment qu'il est composé de 10 chiffres maximum, vu que dans le cas contraire, pdns semble prendre des acides.

Dans la théorie (apt-get install pdns-doc ; /usr/share/doc/pdns-doc/html/types.html) :

If left at 0, the default, PDNS will perform an internal list of the domain to determine highest change_date field of all records within the zone, and use that as the zone serial number. This means that the serial number is always raised when changes are made to the zone, as long as the change_date field is being set.

Sauf que, étrangement... c'est faux : pour générer un serial, le backend gsql qu'on utilise ne regarde jamais ce champ change_date, et il met systématiquement l'EPOCH (nombres de secondes écoulées depuis début 1970, minuit UTC, càd date +%s).

Par conséquent, il nous faut générer des serial nous mêmes, et nous ne pouvons donc pas faire ce qu'on aurait aimé : laisser dns.records.content='' pour les enregistrements SOA, afin de laisser pdns fabriquer lui même ces données.

Donc, 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.

Il faut noter qu'un SOA complet comprend encore 4 autres champs ; nous ne les remplissons pas, et laissons PowerDNS y mettre ses valeurs par défaut :

refresh 10800 (3 heures)
retry 3600 (1 heure)
expire 604800 (1 semaine)
default_ttl 3600 (1 heure)

pnds-recursor

C'est pas spécialement une bonne idée que le serveur utilise son propre serveur DNS pour faire sa résolution. Pourquoi ?

Simplement parce que les utilisateurices ont tendance à pas prévenir quand illes s'en vont. Du coup, on se retrouve à continuer de gérer les mails, les DNS, tout ça, mais juste pour nous, vu que le reste du monde ira voir une autre machine !

Du coup, si on utilise un autre serveur DNS, le problème se pose pas, ou moins.