Avec la sortie de la version 1.0 d’AlternC, le logiciel libre, panneau de contrôle de serveur d’hébergement pour Debian GNU/Linux, le système de DNS a été complètement refondu et réécrit par Alan, aka Fufroma.
Voici donc quelques explications sur le fonctionnement du DNS dans AlternC 1.0 et ultérieur.
Nous partirons du principe que votre serveur est sous AlternC 1.0 ou ultérieur, et que vous avez installé les données dans /var/alternc/ valeur par défaut.
AlternC a toujours été basé sur 2 tables pour les domaines : alternc.domaines et alternc.sub_domaines.
Comme sont nom l’indique, la table domaines liste les domaines que nous hébergeons. Le champ gesdns dit si l’on gère les DNS de ce domaine sur le serveur. Aussi, une valeur à 0 indique que Bind ne gèrera pas cette zone.
Si la valeur est à 1, bind gèrera cette zone, dans /var/alternc/bind/zones/
Le fichier zone est, comme toutes les configurations dans AlternC, créé à partir d’un modèle dans
/etc/alternc/templates/bind/templates/zone.template
Une fois ce modèle rempli et les variables substituées (%%fqdn%% à l’installation, et @@SERIAL@@ à la création de la zone), AlternC liste les sous-domaines du domaine et crée les entrées DNS en conséquence.
Les entrées DNS de sub_domaines
Pour créer les entrées, on utilise les types de domaines. En effet, avec AlternC 1.0, il est possible de créer ses propres types de domaines.
Nous avions depuis toujours dans AlternC 4 types : hébergement (avec un pointeur vers un dossier de l’espace web du compte AlternC), webmail (pointer ce sous-domaine vers le webmail), IPv4 (pointer un sous-domaine vers une IPv4) et redirection http (pointe vers un dossier où un htaccess redirige l’internaute vers une autre page).
Dans AlternC 1.0, ces types sont paramétrables à travers plusieurs informations :
- une ligne dans la table domaines_types
- un éventuel fichier modèle pour apache2 dans /etc/alternc/templates/apache2/
- un éventuel shell-script dans /etc/alternc/functions_hosting
Ainsi chaque type de domaine peut définir de manière très précise son comportement. Nous ne rentrerons pas dans le détail ici, nous resterons attaché à décrire le fonctionnement des zones DNS dans AlternC.
Donc, pour chaque ligne dans sub_domaines, on a un type de domaine concerné, définit dans son champ « type ».
Enfin, dans domaines_types, le champ « entry » définit le texte à insérer (tel quel) dans la zone DNS.
Ce texte peut être constitué de variables qui seront substituées automatiquement ou au cas par cas.
Ainsi, %sub% sera le nom du sous-domaine, %TARGET% la valeur du champ « target » de la table sub_domaine, et les variables en @@ seront issues de /etc/alternc/local.sh (comme @@PUBLIC_IP@@ pour l’ip publique du site).
Il est donc possible, dans domaines_type, non seulement de définir n’importe quel type de domaine créeant des entrées DNS dans la zone, mais même de créer plusieurs entrées DNS en mettant dans le champ « entry » plusieurs lignes de texte !
Rechargement de la zone
Lorsqu’un utilisateur crée un sous-domaine, il faut qu’alternc (à travers son célèbre cron update_domaines.sh) soit informé qu’il doit modifier le fichier zone. Pour cela, on met à « UPDATE » le champ « dns_action » de la table « domaines » pour le domaine concerné.
Ainsi, si vous voulez juste régénérer complètement un fichier zone pour le domaine example.com, la requête SQL suivante suffit :
# mysql alternc
mysql> UPDATE domaines SET dns_action="UPDATE" WHERE domaine="example.com";
puis lancez la tâche cron tout de suite :
# /usr/lib/alternc/update_domaines.sh
Notez que la zone est entièrement recréée à chaque fois. Aussi, si vous souhaitez entrer des enregistrement manuellement dans la zone, cela n’est a priori pas possible … Que nenni ! Fufroma a tout prévu !
Modifier manuellement une zone DNS dans AlternC
Si vous souhaitez gérer manuellement une zone DNS dans AlternC, vous pouvez le faire de 2 façons :
* gérer entièrement vous-même la zone : dans ce cas, AlternC n’y touchera plus jamais (sauf désinstallation du domaine)
* gérer des enregistrements manuels qu’AlternC ne touchera pas, mais lui laisser la gestion habituelle du SOA et de ses sous-domaines.
Le cas numéro 1 est simple : dans chaque zone hébergée par AlternC, vous avez un prologue comme suit :
$TTL 1D
;
; BIND data file for domain @@DOMAINE@@
;
;; This file is automatically regenerate by Alternc
;; Please insert your manual entry after the last comment.
;; If you want to forbid automatic generation, change the LOCKED var
;; LOCKED:NO
;
Mettez tout simplement LOCKED:YES
AlternC ne touchera plus jamais à ce fichier zone
c’est aussi simple que cela
Attention : quand on dis qu’AlternC n’y touchera plus, c’est sérieux : si vous créez, modifiez ou supprimez des sous-domaines dans AlternC pour ce domaine, la zone ne sera pas modifiée ! Effectuez ceci à vos risques et périls.
Si vous souhaitez redonner le contrôle à AlternC, remettez NO et demandez à AlternC de régénérer la zone (voir plus haut)
Le cas numéro 2, lui aussi, est très simple 🙂 Si vous souhaitez juste gérer certains enregistrements DNS vous-même, il vous suffit de les mettre APRES le dernier commentaire tout en bas de la zone.
Ce commentaire, s’il n’est pas présent (notamment pour les serveur ayant été mis à jour depuis AlternC <1.0), peut tout simplement être ajouté, il s'agit de la ligne suivante :
;;; END ALTERNC AUTOGENERATE CONFIGURATION
La bonne nouvelle est donc que AlternC ne touchera à rien APRÈS cette ligne. Donc, si vous souhaitez créer des enregistrements manuellement, ajoutez juste ceux-ci après ce commentaire, modifiez le serial (+1) et lancez en tant que root « rndc reload example.com »
Voilà, c’est tout.
Comme vous pouvez le constater, AlternC 1.0 apporte un véritable plus aux administrateurs systèmes soucieux de profiter à la fois des automatismes fournis par AlternC, de la flexibilité de sa configuration, mais aussi de conserver le contrôle à divers endroits si besoin !
et IPv6 dans tout cela ?
Dernier point : j’ai récemment essayé de patcher AlternC pour un support étendu d’IPv6. La première chose à faire, qui marche à merveille, consiste juste à modifier les entrées DNS créées par les types de domaines standard : vhost url et webmail.
J’ai donc procédé ainsi (exemple sur un de mes serveurs) :
# mysql alternc
mysql> UPDATE domaines_type SET entry="%SUB% IN A @@PUBLIC_IP@@\n%SUB% IN AAAA 2001:67c:288::6" WHERE type IN ("vhost","url","webmail");
mysql> UPDATE domaines SET dns_action="UPDATE";
# /usr/lib/alternc/update_domaines.sh
Attention, cela est bien entendu non garanti 🙂 Cependant, je vous invite à procéder à ces modifications le 5 juin prochain au matin, afin que tous vos sites web soient en IPv6 le 6 juin prochain au matin !