Picasoft possède deux noms de domaines :

• picasoft.net, pour ses activités principales ;
• picagraine.net, pour ses activités pédagogiques.

En d’autres termes, l’association a la possibilité de gérer complètement toutes les adresses se terminant en picasoft.net.

Ces noms de domaines sont enregistrés chez le registrar Gandi.

Ces noms de domaines sont attachés à l’organisation Picasoft. Ils peuvent être gérés par n’importe quelle personne ayant un compte Gandi faisant partie de l’organisation Picasoft.

Ensuite, il faut se rendre dans l’onglet « Nom de domaine ».

Le DNS (Domain Name System) est un système qui permet de traduire des noms de domaine (par exemple team.picasoft.net) en adresse IP. On peut le voir comme un système d’annuaire permettant d’associer le nom d’un système à son adresse.

Picasoft a fait le choix d’utiliser ses propres serveurs DNS plutôt que ceux de son registrar (Gandi). Le serveur DNS master est l’hyperviseur alice.picasoft.net. La zone DNS est aussi répliquée sur l’hyperviseur bob.picasoft.net et sur le VPS d’un membre. (voir la section de complément en fin de page pour une explication plus détaillée de ce fonctionnement)

Le nom de domaine picasoft.net a été réservé par Picasoft chez le registrar français Gandi. Généralement le registrar propose une interface pour configurer sa zone DNS et utiliser les serveurs DNS du registrar. Dans une logique d’auto-hébergement, Picasoft préfère utiliser ses propres serveurs DNS, il est donc nécessaire de déléguer la gestion de la zone DNS des serveurs Gandi vers les serveurs de Picasoft.

En pratique, il suffit de se rendre sur le manager Web de Gandu dans l’univers (menu du haut) Web sur la rubrique (menu de gauche) Domaines. On sélectionne picasoft.net dans la liste et on accède à la configuration de ce domaine. Dans les différents menus de configuration on va sur l’onglet Serveurs DNS sur lequel on voit la liste des serveurs DNS (masters et slaves) qui gèrent la zone picasoft.net.
Le fonctionnement est trivial, si nécessaire il suffit de modifier cette liste en ajoutant/retirant les serveurs DNS de la zone (un serveur se configure à l’aide d’un nom de domaine et d’une adresse IP). L’application des modifications peut prendre quelques minutes, mais un badge de statuts dans l’interface permet de suivre l’évolution de la modification.

Nous utilisons le logiciel BIND9 comme serveur DNS. Sa configuration se trouve dans le fichier /etc/bind/named.conf.local.
Par exemple sur alice, on a le fichier suivant:

zone "picasoft.net" {
        # Serveur maitre
        type master;

        # Chemin du fichier de zone
        file "/etc/bind/picasoft.net/db.picasoft.net";

        # On autorise le transfert aux serveurs slaves
        allow-transfer{91.224.148.85; 149.91.83.194;};

};

Cette configuration indique que le serveur est maître de la zone picasoft.net dont le fichier est /etc/bind/picasoft.net/db.picasoft.net. De plus il autorise des serveurs secondaires (slave) à récupérer la configuration de cette zone. Ceci est utile en cas de panne de alice, les serveurs secondaires continuent à répondre aux requêtes pendant un certain temps.

Le fichier de configuration d’un serveur slave lui est légèrement différent:

zone "picasoft.net" {
        type slave;
        file "/var/cache/bind/db.picasoft.net";
        masters{91.224.148.84;};
        allow-transfer{none;};
};

Le fichier de la zone picasoft.net se trouve donc sur alice dans /etc/bind/picasoft.net/db.picasoft.net. C’est un format un peu spécifique (et très laid), on retiendra surtout que les commentaires s’écrivent avec le caractère ;. Il est important de bien commenter ce fichier, un fichier de zone mal commenté c’est au mieux très désagréable à lire et au pire inutilisable.

En haut du fichier se trouve un morceau de configuration particulier, qui définit le fonctionnement des DNS pour la zone.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;; SOA record ;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
$TTL    7200                            ; TTL - 2H - Durée expiration cache DNS client
@       IN      SOA     ns01.picasoft.net. contact.picasoft.net. (
                        2017121901      ; Serial - Format AAAAMMJJXX où XX est incrémenté de 01 à 99
                        300             ; Refresh - 5 minutes - Fréquence d'actualisation des DNS secondaires
                        3600            ; Retry - 1 heure - Fréquence de nouvel essai quand actualisation DNS échoue
                        2419200         ; Expire - 28 Jours - Durée après laquelle les DNS secondaire non actualisés expirent
                        10800           ; Negative Cache TTL - 3 heures - TTL de l'information de non présence d'un enregistrement dans le domaine
)

La configuration est largement commentée, la ligne la plus importante étant celle du serial (ici 2017121901). Le serial est une sorte de version du fichier de zone. Il est primordial que ce numéro s’incrémente à chaque modification et ne se décrémente jamais. Pour cela son format reprend la date du jour (au format AAAAMMJJ) suivi de 2 chiffres que l’on incrémente en cas de multiples modifications dans la même journée.

Se suivent ensuite différentes parties de la configuration permettant de configurer nos serveurs DNS, les IPs de nos machines (par exemple la ligne alice IN A 91.224.148.84) et surtout les IPs de nos services.

Pour ajouter un nouveau sous-domaine il suffit d’ajouter une ligne pour celui-ci. Par exemple team.picasoft.net est un service qui tourne sur la machine pica01.picasoft.net ayant l’IP publique 91.224.148.57 (c’est d’ailleurs indiqué dans le fichier). On va donc dans la partie de la configuration qui correspond aux services sur pica01 (ce n’est pas obligatoire mais c’est important pour garder un fichier lisible) et on ajoute team IN A 91.224.148.57 ; Mattermost.
C’est à dire:

1. le sous-domaine (team)
2. le type d’enregistrement (IN A pour une adresse IP)
3. la valeur de l’enregistrement (l’IP de la machine, ici 91.224.148.57)
4. un petit commentaire pour expliquer à quoi correspond l’enregistrement

On prend soin d’ajouter une seconde ligne, quasiment identique, avec comme type d’enregistrement IN AAAA et comme valeur l’adresse IPv6 de la machine hébergeant le service (ici 2a03:7220:8080:3900::1). Ceci permet aux personnes disposant d’une connectivité IPv6 d’utiliser les services de Picasoft directement via ce protocole, plus récent.

Une fois le sous-domaine ajouté, il faut modifier le serial en entête du fichier. Comme vu au dessus, celui-ci a un format spécifique. On lui met la date du jour au format AAAAMMJJ suivi de 2 chiffres pour permettre plusieurs modifications dans une journée (on commence chaque nouvelle journée à 01). Il est très important de vérifier que le serial a le bon format, car celui-ci doit toujours s’incrémenter dans le temps. Une erreur (par exemple l’ajout d’un digit en trop) peu provoquer des soucis techniques assez ennuyeux à gérer.

Il faut aussi vérifier que le sous-domaine qu’on cherche à ajouter est valide, c’est à dire, qu’il ne contient que les lettres de ‘a’ à ‘z’ (majuscules ou minuscules), les chiffres de ‘0’ à ‘9’ et le signe moins '-'.

Une fois que c’est fait on enregistre le fichier et on redémarre le serveur avec systemctl restart bind9. On vérifie qu’il n’y a pas eu d’erreur avec un systemctl status bind9.

Le fichier de zone est un fichier de configuration important qui évolue dans le temps. Nous avons fait le choix de le versionner avec Git de manière à retracer son évolution et à avoir une sauvegarde.
Après une modification il convient donc de commit et push la modification, accompagnée d’un message de commit clair.

Cloner le dépôt Git sur votre machine, effectuer les modifications, puis les pousser (sur une nouvelle branche ou sur master, selon votre jugement).

Puis se rendre sur Alice et tirer les modifications sur /etc/bind/picasoft.net.

Il faut tout d’abord configurer notre utilisateur sur Git :

git config --local user.name "<prénom>"
git config --local user.email "<email@etu.utc.fr>"

puis:

cd /etc/bind/picasoft.net
git add db.picasoft.net
git commit -m "<message>"
git push origin master

Bien que le contenu fichier de zone ne soit pas confidentiel, le repository Gitlab distant est privé.

Le reverse DNS est un système, basé sur DNS, qui permet de traduire des adresses IP en noms de domaine à l’aide d’enregistrements PTR. Il fait donc l’opposé d’une résolution DNS (d’où son nom). Il est beaucoup moins utilisé que le DNS classique (en tout cas pas par les humains) mais est parfois utile pour certains mécanismes de sécurité (par exemple l’évaluation d’un mail comme étant légitime par un serveur mail).

Tetaneutral route plusieurs adresses IPv4 et IPv6 vers les serveurs de Picasoft. Comme ce sont des adresses IP qui appartiennent à Tetaneutral, ce n’est pas Picasoft qui a directement la main sur les enregistrements PTR correspondant. Cependant, comme cela est très bien expliqué dans la documentation de Tetaneutral, il est possible de déléguer à Picasoft la gestion de enregistrements correspondant aux IP que l’on utilise.

Nous utilisons toujours BIND9 comme serveur DNS, et l’on ajoute de la configuration dans le fichier /etc/bind/named.conf.local.
Par exemple sur alice, serveur master, on a la configuration suivante pour l’adresse IP 91.224.148.84 (à renouveler pour chaque IP):

zone "84/32.148.224.91.in-addr.arpa" IN {
        type  master;
        file  "/etc/bind/reverse/alice.v4";
        allow-transfer{91.224.148.85; 149.91.83.194;};
};

Cette configuration est similaire à la configuration pour picasoft.net. En réalité la seule chose qui change, hormis le fichier de zone, est le nom de la zone : 84/32.148.224.91.in-addr.arpa. C’est la zone que Tetaneutral nous délègue et qui qui va nous permettre de configurer l’enregistrement PTR pour 91.224.148.84 (via l’enregistrement 84.84/32.148.224.91.in-addr.arpa., cf la doc de Tetaneutral).

Exactement de la même façon que pour la zone picasoft.net, on configure nos serveurs slaves pour chaque zone reverse DNS.

Une fois notre serveur configuré pour le reverse de chaque IP, il ne reste plus que à créer un fichier de zone pour chaque délégation reverse que nous fait Tetaneutral. Comme il y en a un certain nombre, ils sont tous dans le dossier /etc/bind/reverse/. Par exemple le fichier /etc/bind/reverse/alice.v4 contient la configuration suivante

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;; SOA record ;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
$ORIGIN .
$TTL    7200                            ; TTL - 2H - Durée expiration cache DNS client
84/32.148.224.91.in-addr.arpa IN SOA ns01.picasoft.net. contact.picasoft.net. (
                        2018012801      ; Serial - Format AAAAMMJJXX où XX est incrémenté de 01 à 99
                        300             ; Refresh - 5 minutes - Fréquence d'actualisation des DNS secondaires
                        3600            ; Retry - 1 heure - Fréquence de nouvel essai quand actualisation DNS échoue
                        2419200         ; Expire - 28 Jours - Durée après laquelle les DNS secondaire non actualisés expirent
                        10800           ; Negative Cache TTL - 3 heures - TTL de l'information de non présence d'un enregistrement dans le domaine
)

; Set origin
$ORIGIN 84/32.148.224.91.in-addr.arpa.

; NS records
     IN NS   ns01.picasoft.net.
     IN NS   ns02.picasoft.net.
     IN NS   ns03.picasoft.net.

; PTR record
84   IN PTR  alice.picasoft.net.

La ligne la plus importante est la dernière. C’est elle qui enregistre l’IP 91.224.148.84 comme ayant le nom de alice.picasoft.net. (le dernier point est très important). Le reste du fichier est très similaire à celui d’un fichier de zone DNS “classique”.

Le serveur Bind sur alice est le maître (master). C’est sur lui que l’on modifie la configuration et c’est lui qui reçoit les requêtes DNS en priorité. Régulièrement (et à chaque changement de configuration) il envoie la zone DNS aux serveurs esclaves (slaves). Les serveurs esclaves sont ainsi capables de répondre aux requêtes DNS de la zone, par exemple si le maître (alice) tombe. Il n’y a rien à faire pour cela, c’est automatique.

Par contre la gestion de la configuration se fait toujours sur le serveur maître (ici alice). Si on devait perdre le maître pour une longue durée ¹⁾ il faudrait qu’on bascule un des esclaves en maître. La procédure serait approximativement :

• on restaure un fichier de configuration de la zone sur un esclave
• on le configure en maître
• on change la liste des serveurs DNS de la zone auprès de notre registrar
• on met à jour l’enregistrement SOA pour refléter l’IP du nouveau serveur maître