1

Correction de liens morts

This commit is contained in:
2026-03-30 02:02:34 +02:00
parent 1b589b8930
commit 538b5cf901
139 changed files with 1161 additions and 1171 deletions

View File

@@ -1,15 +1,15 @@
---
comments_url: https://com.richard-dern.fr/post/513
date: '2012-02-05 17:56:00'
date: "2012-02-05 17:56:00"
dossier:
- Créer son propre Cloud
- Créer son propre Cloud
links:
- lang: fr
name: Page d'origine sur Archive.org
url: https://web.archive.org/web/20120622184230/http://ingnu.fr/2012/02/05/installer-et-configurer-un-serveur-dns/
- lang: fr
name: Archive
url: http://ingnu.fr/2012/02/05/installer-et-configurer-un-serveur-dns/
tags:
- Bind
- DNS
- Bind
- DNS
title: Installer et configurer un serveur DNS
weather:
humidity: 42
@@ -17,25 +17,25 @@ weather:
precipitations: false
pressure: 1027.0
source:
- open-meteo
- open-meteo
temperature: -6.8
wind_direction: 72
wind_speed: 11.4
weight: 2
---
Le deuxième article de [cette nouvelle rubrique](https://web.archive.org/web/20120622184230/http://ingnu.fr/category/creer-son-propre-cloud/) traite logiquement de la mise en place d'un serveur DNS.
Le deuxième article de [cette nouvelle rubrique](http://ingnu.fr/category/creer-son-propre-cloud/) traite logiquement de la mise en place d'un serveur DNS.
À moins que vous n'ayez recours à l'outil de gestion de vos DNS proposé par votre registrar et qu'il ne vous bride pas, vous devrez passer par l'étape du serveur DNS, d'autant qu'il nous permettra par la suite de faire bien d'autres choses que simplement faire pointer un domaine sur une IP...
Nous utiliserons le serveur [bind](https://web.archive.org/web/20120622184230/http://www.isc.org/software/bind).
Nous utiliserons le serveur [bind](http://www.isc.org/software/bind).
Nous allons tout d'abord l'installer sur le serveur principal en tant que maître.
Si vous disposez d'un second serveur, vous pourrez le configurer en tant qu'esclave pour assurer la continuité du service.
Important : *exemple.fr*
Important : `_exemple.fr_`
## Pare-feu
Tout d'abord, reprenons le script de pare-feu que [nous avons configuré précédemment](https://web.archive.org/web/20120622184230/http://ingnu.fr/2012/02/05/creer-son-propre-cloud-introduction/).
Tout d'abord, reprenons le script de pare-feu que [nous avons configuré précédemment](http://ingnu.fr/2012/02/05/creer-son-propre-cloud-introduction/).
```bash
nano /scripts/firewall
@@ -78,7 +78,7 @@ Pour installer bind, rien de plus simple :
apt-get install bind9 dnsutils
```
Le paquet [dnsutils](https://web.archive.org/web/20120622184230/http://packages.debian.org/squeeze/dnsutils) contient notamment les outils *nslookup* et *dig*, qui nous serviront par la suite à tester notre installation.
Le paquet [dnsutils](http://packages.debian.org/squeeze/dnsutils) contient notamment les outils _nslookup_ et _dig_, qui nous serviront par la suite à tester notre installation.
Rendez-vous dans le répertoire de configuration de bind :
@@ -112,24 +112,24 @@ ns2 IN A 2.2.2.2
```
Quelques explications s'imposent.
Dans la ligne relative au *SOA*, on déclare le serveur DNS autoritaire pour la zone (*ns.exemple.fr*) et l'adresse email du responsable (*postmaster.exemple.fr*, le "@"de l'adresse étant remplacé par un". ").
Ensuite, on attribue un numéro de série au fichier; ce numéro ne s'invente pas : il s'agit de la date (au format *YYYYMMDD*) suivi d'un nombre compris entre 00 et 99.
Dans la ligne relative au _SOA_, on déclare le serveur DNS autoritaire pour la zone (_ns.exemple.fr_) et l'adresse email du responsable (_postmaster.exemple.fr_, le "@"de l'adresse étant remplacé par un". ").
Ensuite, on attribue un numéro de série au fichier; ce numéro ne s'invente pas : il s'agit de la date (au format _YYYYMMDD_) suivi d'un nombre compris entre 00 et 99.
Pour plus de clarté, on va appeler ce nombre la "clé".
Si vous disposez de plusieurs domaines, vous pouvez utiliser le premier chiffre de la clé comme identifiant pour un domaine particulier (par exemple, *"j'attribuerai toujours un 1 au domaine exemple.fr, et un 2 au domaine exemple2.fr*"), tandis que le second chiffre de la clé vous servira à indenter les modifications survenues dans ce fichier pour le jour donné.
Si vous disposez de plusieurs domaines, vous pouvez utiliser le premier chiffre de la clé comme identifiant pour un domaine particulier (par exemple, _"j'attribuerai toujours un 1 au domaine exemple.fr, et un 2 au domaine exemple2.fr_"), tandis que le second chiffre de la clé vous servira à indenter les modifications survenues dans ce fichier pour le jour donné.
Par exemple, vous faites 4 modifications sur le fichier *db.exemple.fr*, et 7 sur le fichier *db.exemple2.fr*, en date d'aujourd'hui.
Vous pouvez attribuer les numéros de série suivants à vos fichiers : *2012020514* et *2012020527*.
Par exemple, vous faites 4 modifications sur le fichier _db.exemple.fr_, et 7 sur le fichier _db.exemple2.fr_, en date d'aujourd'hui.
Vous pouvez attribuer les numéros de série suivants à vos fichiers : _2012020514_ et _2012020527_.
Important : [ZoneCheck](https://web.archive.org/web/20120622184230/http://www.afnic.fr/fr/produits-et-services/services/zonecheck/)
Important : [ZoneCheck](http://www.afnic.fr/fr/produits-et-services/services/zonecheck/)
Les valeurs suivantes (*refresh*, *retry*, etc.) devraient convenir à la majorité des situations.
Les valeurs suivantes (_refresh_, _retry_, etc.) devraient convenir à la majorité des situations.
Nous définissons ensuite les deux serveurs DNS associés au nom de domaine : *ns.exemple.fr.* et *ns2.exemple.fr.*
Nous définissons ensuite les deux serveurs DNS associés au nom de domaine : _ns.exemple.fr._ et _ns2.exemple.fr._
Ensuite, nous indiquons que le serveur principal a pour adresse IP 1.1.1.1, puis nous associons les adresses 1.1.1.1 et 2.2.2.2 aux deux serveurs de noms.
Une fois que vous avez adapté cet exemple à votre propre domaine, vous pouvez enregistrer et fermer.
Théoriquement, dans une installation de base de bind sur une debian stable, le fichier *named.conf* contient la ligne suivante :
Théoriquement, dans une installation de base de bind sur une debian stable, le fichier _named.conf_ contient la ligne suivante :
```text
include "/etc/bind/named.conf.local";
@@ -141,7 +141,7 @@ Si ce n'est pas le cas, rajoutez-là :
echo "include \"/etc/bind/named.conf.local\";" >> named.conf
```
Et modifiez le fichier *named.conf.local* :
Et modifiez le fichier _named.conf.local_ :
```bash
nano named.conf.local
@@ -193,9 +193,9 @@ On reste donc sur la même machine, pour créer une clé de transfert :
dnssec-keygen -a HMAC-MD5 -b 512 -n HOST <localhost>.exemple.fr.
```
*dnssec-keygen* est un outil livré avec bind.
_dnssec-keygen_ est un outil livré avec bind.
Grâce à la commande suivante, on génère une clé en utilisant l'algorithme HMAC-MD5, d'une longueur de 512 bits, pour un hôte particulier (-n HOST), en l'occurrence, celui indiqué à la fin.
Remplacez *<localhost>* par le nom d'hôte du serveur.
Remplacez _<localhost>_ par le nom d'hôte du serveur.
Par exemple, j'ai appelé mon serveur "minerva", sur le domaine ingnu.fr.
La commande qui s'applique à mon cas devient donc :
@@ -203,20 +203,20 @@ La commande qui s'applique à mon cas devient donc :
dnssec-keygen -a HMAC-MD5 -b 512 -n HOST minerva.ingnu.fr.
```
On génère une clé pour un hôte donné, mais *dnssec-keygen* permet bien d'autres choses que nous n'utiliserons pas ici.
On génère une clé pour un hôte donné, mais _dnssec-keygen_ permet bien d'autres choses que nous n'utiliserons pas ici.
Notamment, vous pouvez choisir un algorithme différent, ou créer une clé pour toute une zone.
Pour l'heure, nous souhaitons avoir la possibilité de transférer de manière sécurisée les données de zones (dans notre exemple, le fichier *db.exemple.fr*) de notre serveur maître vers le serveur esclave que nous configurerons plus tard.
Pour l'heure, nous souhaitons avoir la possibilité de transférer de manière sécurisée les données de zones (dans notre exemple, le fichier _db.exemple.fr_) de notre serveur maître vers le serveur esclave que nous configurerons plus tard.
Cette commande est donc suffisante pour le moment.
A l'issue de l'exécution de cette commande (qui peut durer une vingtaine de secondes), deux nouveaux fichiers ont été créés.
Ils commencent par la lettre K majuscule, et portent respectivement l'extension *.key* et *.private*.
Ils commencent par la lettre K majuscule, et portent respectivement l'extension _.key_ et _.private_.
Le premier fichier contient une ligne qu'il est possible de rajouter dans un fichier de zone, tandis que le second contient quelques détails sur la création de la clé.
Nous n'utiliserons dans notre cas précis aucun des deux dans son état actuel.
Cependant, il peut être utile de les conserver pour un usage ultérieur.
La seule chose qui nous intéresse est la clé en elle-même qui figure dans les deux fichiers.
Utilisez la commande *cat* sur le fichier *.private*, et copiez la clé qui apparaîtra.
Créez ensuite le fichier *transfer.conf* :
Utilisez la commande _cat_ sur le fichier _.private_, et copiez la clé qui apparaîtra.
Créez ensuite le fichier _transfer.conf_ :
```bash
nano transfer.conf
@@ -240,7 +240,7 @@ Si un cas se présente où nous devrons diffuser d'autres clés, nous en génèr
Ensuite, nous affectons cette clé au serveur esclave, 2.2.2.2.
Incluez ce fichier à votre configuration, puis modifiez le fichier *named.conf.local* :
Incluez ce fichier à votre configuration, puis modifiez le fichier _named.conf.local_ :
```bash
echo "include \"/etc/bind/transfer.conf\" >> /etc/bind/named.conf
@@ -255,7 +255,7 @@ zone "exemple.fr" {
};
```
Nous avons rajouté la ligne *allow-transfer { 2.2.2.2; };* qui nous permet d'éviter que n'importe qui puisse transférer nos zones sur son serveur.
Nous avons rajouté la ligne _allow-transfer { 2.2.2.2; };_ qui nous permet d'éviter que n'importe qui puisse transférer nos zones sur son serveur.
Redémarrez bind :
```bash
@@ -271,7 +271,7 @@ Sur la machine qui hébergera ce serveur, installez bind :
apt-get install bind9 dnsutils
```
Nous avons créé le fichier *transfer.conf* sur le serveur maître.
Nous avons créé le fichier _transfer.conf_ sur le serveur maître.
Le même fichier doit être créé sur la machine esclave, avec une petite nuance.
```bash
@@ -293,7 +293,7 @@ server 1.1.1.1 {
};
```
Vous noterez qu'il s'agit exactement du même fichier, y compris la même clé, mais que l'adresse IP de la clause *server* change.
Vous noterez qu'il s'agit exactement du même fichier, y compris la même clé, mais que l'adresse IP de la clause _server_ change.
Dans la configuration du serveur esclave, c'est l'adresse IP du serveur maître qu'il faut indiquer.
Ensuite, comme pour la configuration du serveur maître, on ajouter ce fichier à la configuration de bind :
@@ -301,7 +301,7 @@ Ensuite, comme pour la configuration du serveur maître, on ajouter ce fichier
echo "include \"/etc/bind/transfer.conf\" >> /etc/bind/named.conf
```
Modifions ensuite le fichier *named.conf.local* pour y ajouter la configuration de votre (vos) domaine(s) :
Modifions ensuite le fichier _named.conf.local_ pour y ajouter la configuration de votre (vos) domaine(s) :
```text
zone "exemple.fr" {
@@ -312,7 +312,7 @@ zone "exemple.fr" {
};
```
Nous indiquons ici que le fichier de zone *db.exemple.fr*, une fois transféré, sera stocké dans le dossier */var/cache/bind*, qui devrait déjà être créé.
Nous indiquons ici que le fichier de zone _db.exemple.fr_, une fois transféré, sera stocké dans le dossier _/var/cache/bind_, qui devrait déjà être créé.
Si ce n'est pas le cas, il faut le créer, et donc tous les cas, lui attribuer les bons droits :
```bash
@@ -334,7 +334,7 @@ tail -100 /var/log/syslog
```
Il se peut que vous y trouviez une erreur à propos de l'heure qui n'est pas synchronisée.
Installez sur les deux serveurs le paquet [ntpdate](https://web.archive.org/web/20120622184230/http://packages.debian.org/squeeze/ntpdate), puis synchronisez les horloges avant de redémarrer bind :
Installez sur les deux serveurs le paquet [ntpdate](http://packages.debian.org/squeeze/ntpdate), puis synchronisez les horloges avant de redémarrer bind :
```bash
apt-get install ntpdate
@@ -359,4 +359,4 @@ Address: 1.1.1.1
Vous disposez désormais de l'une des pièces maîtresses de votre propre serveur.
La configuration de base que nous avons mis en place aujourd'hui va être complétée et sécurisée au fil des articles à venir, pour qu'au final, vous disposiez d'une solution complète vous permettant de vous affranchir des services offerts par Google, Twitter, facebook et bien d'autres.
Le serveur que nous allons monter avec ces articles va vous permettre de reprendre le contrôle de vos données.
Alors à bientôt pour le prochain article, qui traitera de la deuxième pierre angulaire de votre Cloud personnel et Libre : le serveur mail.
Alors à bientôt pour le prochain article, qui traitera de la deuxième pierre angulaire de votre Cloud personnel et Libre : le serveur mail.