3 - Installation du serveur Debian
3.3 - Le « Domain Name Server » DNS
Vous aurez peut-être remarqué dans la configuration du daemon DHCP de la page précédente, que l'adresse IP privée de notre serveur Debian à été indiqué dans l'option « domain-name-servers ».
Autrement dit, notre serveur doit aussi être en mesure de répondre au requête DNS des clients. Pour cela, nous allons utiliser le daemon « Bind » qui n'est rien de moins que le daemon DNS qui équipe les « root dns ». C'est à dire les serveur sur lesquels reposent l'ensemble du nommage internet public.
Il ne nous reste donc qu'à installer se daemon sur notre serveur :
# @server
sudo apt install bind9 dnsutils
⚠️ Si votre hôtes est sous Windows
Sous Windows, Virtualbox fourni par defaut aux systèmes virtualisés les adresses IP des serveurs DNS de l'hôte. Hors, ceux-ci peuvent changer d'un réseau à l'autre. Surtout sur un ordinateur portable. Nous allons donc modifier la configuration de la machine virtuelle du serveur Debian pour masquer les DNS de l'hôte via le « proxy DNS » de Virtualbox.
Cette option n'est modifiable quand ligne de commande et sous Windows... Bref. Stopper la machine virtuelle Debian (sudo poweroff). Puis, Lancer un terminal de commande sur l'hôte et entrer :
# @host
cd %ProgramFiles%
Oracle\Virtualbox\VBoxManage.exe modifyvm "Serveur Debian" --natdnsproxy1 on
Une fois le serveur Debian relancé, vérifier que le proxy DNS est bien en place en exécutant la commande suivante :
# @server
cat /etc/resolv.conf
Vous devez obtenir le résultat suivant (possiblement accompagné de ligne « search » suivant le réseau sur lequel vous opérez) :
nameserver 10.0.2.3
Le « cache DNS »
Une fois BIND installé, il faut encore le configurer :
# @server
sudo vi /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
forwarders {
10.0.2.3;
};
dnssec-validation no;
listen-on { 10.0.0.254; };
};
Dans la section « forwarders », indiquez l'adresses IP du serveur Cache DNS émulé par VirtualBox. Pour trouver cette adresse, entrez la commande :
# @server
cat /etc/resolv.conf
Si cela ne fonctionne pas pour vous, vous pouvez mettre à la place les adresses IP des serveurs DNS de votre système hôte.
Ainsi, nous indiquons que pour toute demande DNS qui ne trouverait pas de réponse localement, il faut s'adresse aux DNS de Virtualbox ou de l'hôte.
Sans autre configuration, notre serveur DNS n'est qu'un « cache » qui mémorise les réponses apporté par les DNS auquel il se réfère. Ainsi, lorsque les clients du réseau privés demande l'adresse IP d'un même nom de domaine plusieurs fois, le serveur n'interroge qu'une seule fois les serveurs « au dessus de lui ».
Pour tester la configuration de bind :
# @server
sudo named-checkconf /etc/bind/named.conf
Sauf erreur, il ne reste qu'à redémarrer le daemon :
# @server
sudo service bind9 restart
Comme pour le daemon DHCP, on peut contrôler le bon fonctionnement du service avec :
# @server
sudo service bind9 status
Reconfiguration de la carte réseau du client Ubuntu
Dans Virtualbox, nous devons désormais indiquer que la carte réseau du client n'est plus configurer en NAT, mais en réseau interne :
- Réseau [Adapter 1]
Mode d'accès réseau : NAT- Mode d'accès réseau : Réseau interne
- Nom : intnet
Zone locale
Bien entendu, avoir sont propre serveur DNS permet également de déclarer ces propres noms de domaines locaux qui permettent de simplifier l'appel des machines sur un réseau local.
Nous allons configurer un domaine « admx.osef ». Ce domaine permettra d'appeler nos deux machines avec les nom suivants :
- srv.admx.osef le serveur Debian
- client.admx.osef le client Ubuntu
L'extension « osef » est utilisé pour éviter d'entrer en collision avec une extension existant réellement sur l'internet publique. Vous pouvez inventer votre propre extension si vous le souhaitez.
Les fichiers
Pour renseigner notre nouveau domaine, nous alons creer deux fichiers
- /etc/bind/db.10.0.0
- /etc/bind/db.admx.osef
et en modifier un troisième
- /etc/bind/named.conf.local
/etc/bind/db.10.0.0
; BIND reverse data file for admx.osef
;
$TTL 604800
@ IN SOA admx.osef. root.admx.osef. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS admx.osef.
1 IN PTR client.admx.osef.
254 IN PTR srv.admx.osef.
/etc/bind/db.admx.osef
; BIND data file for admx.osef domain
;
$TTL 604800
@ IN SOA admx.osef. root.admx.osef. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS admx.osef.
@ IN A 10.0.0.254
srv IN A 10.0.0.254
client IN A 10.0.0.1
dns IN CNAME srv
Pour finaliser la création de notre domaine, nous devons indiquer l'existance des deux fichiers précédents. Cela se passe dans le fichier /etc/bind/named.conf.local :
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "admx.osef" {
type master; file "/etc/bind/db.admx.osef";
};
zone "0.0.10.in-addr.arpa" {
type master; file "/etc/bind/db.10.0.0";
};
Ce fichier ne sera pas écrasé lors d'une mise à jour du paquet bind9.
Il ne reste qu'à tester la configuration de bind :
# @server
sudo named-checkconf /etc/bind/named.conf
Puis redémarrer le daemon :
# @server
sudo service bind9 restart
Pour vérifier que le daemon est bien en cours d'exécution, il faut rechercher le processus appelé « named » ou utiliser l'option status de la commande service :
ps aux | grep named
sudo service bind9 status
Pour vérifier en une seule fois que les deux services réseaux (dhcp & dns) sont bien en cours d'exécution, on peut utiliser une expression régulière :
ps aux | grep -E '(named|kea-dhcp4)'
>>> Vous pouvez passer aux diagnostiques & exercices
