{{indexmenu_n>1}}
====== Gestion du nom de domaine de Picasoft ======
## Noms de domaines
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](https://gandi.net).
Un registraire de nom de domaine ou bureau d'enregistrement est une société ou une association gérant la réservation de noms de domaine Internet, dans les domaines de premier niveau où il n'y a pas de vente directe pour le registre de noms de domaine ([source](https://fr.wikipedia.org/wiki/Registraire_de_nom_de_domaine)).
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.
Il suffit de demander sur [le canal Asso](https://team.picasoft.net/picasoft/channels/asso) avec ton pseudo pour que quelqu'un t'ajoute à l'organisation Picasoft.
Côté asso, voici la procédure :
{{:technique:adminsys:dns:gandi_registrar_1.png|}}
{{:technique:adminsys:dns:gandi_registrar_2.png|}}
Il suffit ensuite d'ajouter le membre.
Ensuite, il faut se rendre dans l'onglet « Nom de domaine ».
Par défaut, la plupart des opérations (comme le renouvellement) sont faites à titre personnel, même quand le nom de domaine est relié à une organisation.
C'est au moment de réglé qu'on choisit l'organisation depuis laquelle faire le paiement :
{{:technique:adminsys:dns:gandi_registrar_3.png?500|}}
===== Serveurs DNS =====
Le **[[https://fr.wikipedia.org/wiki/Domain_Name_System|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)//
==== Configuration de la délégation DNS ====
Le nom de domaine ''picasoft.net'' a été réservé par Picasoft chez le //registrar// français [Gandi](https://www.gandi.net/fr). 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.
==== Configuration du serveur Bind9 ====
Nous utilisons le logiciel [[https://fr.wikipedia.org/wiki/BIND|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;};
};
===== Fichier de zone =====
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.
Tous les fichiers de zone se trouvent sur Git à cette adresse : https://gitlab.utc.fr/picasoft/projets/zonefile-picasoft.\\
Toute modification doit être synchronisée avec ce dépôt, via un push direct ou une merge request.
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.
==== Ajout d'un sous-domaine ====
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:
- le sous-domaine (''team'')
- le type d'enregistrement (''IN A'' pour une adresse IP)
- la valeur de l'enregistrement (l'IP de la machine, ici ''91.224.148.57'')
- 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 [[https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames | 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''.
==== Sauvegarde du fichier de zone DNS sur Git ====
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**.
#### Depuis votre machine
Cloner le [dépôt Git](https://gitlab.utc.fr/picasoft/zonefile-picasoft) 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`.
#### Depuis Alice
Il faut tout d'abord configurer notre utilisateur sur Git :
git config --local user.name ""
git config --local user.email ""
puis:
cd /etc/bind/picasoft.net
git add db.picasoft.net
git commit -m ""
git push origin master
Bien que le contenu fichier de zone ne soit pas confidentiel, le //repository// [[https://gitlab.utc.fr/picasoft/zonefile-picasoft|Gitlab distant]] est privé.
====== Gestion du reverse DNS sur les IPs ======
Le **[[https://en.wikipedia.org/wiki/Reverse_DNS_lookup|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 [[https://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/Bind#D%C3%A9l%C3%A9gation-dun-reverse-classless-|la documentation de Tetaneutral]], il est possible de déléguer à Picasoft la gestion de enregistrements correspondant aux IP que l'on utilise.
==== Configuration du serveur Bind9 ====
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.
==== Fichier de zone reverse ====
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".
====== Compléments ======
===== Serveur DNS maître et serveurs esclaves =====
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 ((On parle de plusieurs jours : on voit sur le //header// du fichier de zone que la copie de la zone sur les //slaves// est valable pendant 28 jours. Passé ce délai, si le maître ne donne plus de nouvelle, la zone est invalidé et les //slaves// ne répondent plus aux requêtes (et là ça devient très ennuyeux). )) 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