linux configurer dns server et client
Ce cours fait partie de l'ensemble Linux à voir ici, sur Linux les fondamentaux ici et linux les commandes des bases du shell ici , ensuite linux et les droits sur les fichiers , Linux les gestionnaires de paquets , Linux editeur nano , linux configurer dhcp server et client , linux configurer dns server et client , linux disque durs et partitions , linux disque durs et partitions avec LVM
linux configurer dns server et client: rappel des connaissances vues en rapport avec cette formation
Rappel des connaissances vues en rapport avec cette formation
Rappel de la définition d’un serveur et de son rôle
Rappel sur les fondamentaux réseau
Rappel du protocole DHCP et de son fonctionnement
Rappel du protocole DNS et de son fonctionnement
Rappel sur l’environnement Linux et ses commandes utiles
Rappel sur les exercices basiques de cours sur l’environnement Linux
Rappel sur le terme Virtualisation et de son fonctionnement
Une question? Posez-la ici
linux configurer dns server et client: Définir les prérequis pour l’implémentation de DNS
Définir les prérequis pour l’implémentation de DNS (TD)
Topologie réseau
Plan d’adressage
Identifiants
Préparer les enveloppes des machines virtuelles (serveur et postes client)
Installer et préparer un système d’exploitation (serveur et postes client)
Faire un snapshot
linux configurer dns server et client: Rappel Virtualisation
Merci de cliquer sur l’image
ou d’ouvrir ce lien vidéo :
https://youtu.be/4J_00mQ5BAs
Rappel Virtualisation
Utiliser les ressources de la machine pour faire tourner plusieurs autres systèmes.
Hyperviseur :
Assure le contrôle du processeur et des ressources de la machine
Alloue à chaque VM les ressources dont elle a besoin
S’assure que ces VM ne rentrent pas en conflits
Type d’hyperviseur :
Bare metal : logiciel installé directement sur le hardware (Serveur HP, DELL, Lenovo, etc…)
Host metal : logiciel installé à l’intérieur d’un système d’exploitation (VirtualBox, Hyper-V, etc…)
Rappel Virtualisation
Architecture physique (Application + OS + Hardware)
Type de virtualisation :
Virtualisation d’application
Virtualisation d’application (Application) + Architecture physique (OS + Hardware)
Virtualisation de sessions : Applications sur le serveur distant + accès de ces applications via un navigateur web ou client depuis son poste de travail
Streaming d’application : Image de l’application sur un serveur qui le charge sur le poste de travail via le réseau
Rappel Virtualisation
Virtualisation d’OS
Virtualisation d’OS (Application + OS) + Architecture physique (Hardware)
Pour serveur et postes de travail
Virtualisation de poste de travail
VDI (Virtual Desktop Infrastructure) : OS sur le serveur distant + affichage session à distance sur le poste de travail
Streaming d’OS : Image de l’OS sur un serveur qui le charge sur le poste de travail via le réseau
Une question? Posez-la ici
linux configurer dns server et client: Implémenter et configurer un serveur DNS et postes clients (TD)
Implémenter et configurer un serveur DNS et postes clients (TD)
Rappel des prérequis
Savoir le vocabulaire et termes concernant DNS (complément du rappel)
Savoir les composants de Bind9
Savoir la syntaxe des fichiers de configuration DNS Bind
Savoir et configurer les prérequis nécessaires avant l’installation du DNS Maître
Savoir bloquer/débloquer les entrées des serveurs DNS dans /etc/resolv.conf
Savoir installer un serveur DNS Maître avec Bind9
Savoir configurer un serveur DNS Maître avec Bind9
Savoir configurer un serveur DNS Maître avec Bind9 pour les postes clients
Savoir configurer des postes clients pour obtenir un service DNS
Vérifier les relations serveur DNS / postes clients
Une question? Posez-la ici
linux configurer dns server et client: Rappels
Merci de cliquer sur l’image
ou d’ouvrir ce lien vidéo :
https://youtu.be/qzWdzAvfBoo
Dernier point important de la configuration réseau.
Dans votre navigateur, vous utilisez des URLs lisible du type facebook.com ou google.fr qui fait référence au nom de domaine d’un site web.
Mais quand votre carte réseau cherche a communiquer avec ces URLs elle a besoin de leurs adresse IP !
C’est là qu’intervient le server DNS (Domain Name System)
Un serveur DNS est un serveur qui garde en mémoire l’adresse IP associée à un nom de domaine.
Si il ne l’a pas en mémoire, il dialogue avec d’autres serveurs DNS pour obtenir l’information.
DNS utilise le port 53
Quand vous tapez une URL (ici google.com) dans votre navigateur, votre carte réseau contacte votre serveur DNS pour lui demander « Qui est google.com ?»
Le serveur DNS regarde dans son répertoire de nom de domaine et renvoie la réponse « google.com est à l’adresse 172.217.18.206 »
Le système d'exploitation ou Operating System (OS) est la couche qui fait le lien entre les applications installés sur un ordinateur et le matériel.
Il gère la mémoire, l'utilisation du processeur entre les différentes applications, les accès aux réseaux, ainsi que les entrés sorties (clavier, souris, etc.)
GPL (Gnu Politic Licence) spécifie qu’un logiciel y adhérant sera pour toujours en Open Source.
Open Source (logiciel libre) signifie que les utilisateurs sont libres :
d’exécuter le programme, pour tous les usages
d’étudier le fonctionnement du programme, de l’adapter à ses besoins (accès au code source)
de redistribuer des copies
d’améliorer le programme et de publier des améliorations
Ce sont les 4 règles fondatrices du logiciel libre.
Open Source obéit à une définition très précise établie par l’Open Source Initiative (organisation pour la promotion du logiciel Open Source)
Mais qu'est-ce qu'une distribution Linux et quelles sont les différences ?
Une distribution est une version personnalisée de Linux ; cette personnalisation peut être :
Une modification du noyau Linux pour apporter des optimisations
L'ajout d'une interface graphique (environnement de bureau)
L'ajout de divers logiciels
Pourquoi tant de distribution ? Chaque distribution à ses propres avantages :
Expériences utilisateurs et facilité d’utilisation (Ubuntu)
Productivité, création de serveurs, développement (Fedora)
Fiable et sécurisé (Linux Mind)
Schéma des relations entre les différentes distributions :
https://futurist.se/gldt/wp-content/uploads/12.10/gldt1210.svg
Un gestionnaire de paquets est un logiciel permettant de faciliter le téléchargement et l'installation d'un logiciel appelé paquet.
Toutes les distributions Linux en ont un.
Les plus connus sont :
APT : Advanced Packaging Tool que l'on retrouve sur Debian et de nombreux descendant, ne s'utilise qu'en ligne de commande
Synaptic : Interface graphique pour APT
Aptitude : Interface graphique pour APT
RPM : Red Hat Package Manager est un gestionnaire de paquet de Red Hat
Yum : Présent sur Red Hat, CentOS et Fedora.
Un shell est un terminal permettant de taper des commandes pour exécuter des tâches, tel que :
Se déplacer dans le système de fichiers (répertoire)
Modifier des fichiers
Télécharger des fichiers
Configurer le système
etc.
linux configurer dns server et client: un peu de vocabulaire dns
Zone : Ensemble des directives correspondantes à un domaine. À chaque zone correspond un fichier mais une zone n'est pas forcément un domaine.
DNS récursif : DNS capable d'interroger d'autres servers DNS, lorsqu'il ne parvient à trouver un serveur faisant autorité sur le nom de domaine recherché.
Serveur « primaire » ou « maître » d'une zone (en anglais serveur « authoritive ») : serveur qui a la configuration de sa zone grâce à un fichier. C'est le serveur principal d'un domaine.
Serveur secondaire : serveur qui des informations sur une zone à partir d'un serveur primaire et non grâce à sa configuration.
DNS : Un peu de vocabulaire (complément du rappel)
Faire autorité sur un domaine : C'est le fait pour un serveur DNS de répondre directement aux requêtes d’un domaine, sans passer par un autre serveur ou un cache.
Un cache : C'est le fichier dans lequel le serveur DNS récursif conserve l'information qu'il a obtenu d'un autre serveur à la suite d'une requête qui lui a été faite par un client.
Donc les serveurs qui font autorités sur un domaine sont, soit des serveurs primaires, soit des serveurs secondaires s'ils ont une copie de ces informations.
linux configurer dns server et client: Composants de Bind9
DNS : Composants de Bind9
Plusieurs serveur DNS sont disponibles dans la distribution Debian. Nous allons installer le serveur DNS de référence à savoir BIND (Berkeley Internet Name Daemon) de l'Internet Software Consortium dans sa version 9.
Version 9 : stable et sécurisée
Version 10 depuis 2013 intègre le DHCP
/usr/sbin/named C’est le programme qui lance le serveur
/etc/init.d/bind9 Permet de gérer et de redémarrer le service bind
En root :
/etc/init.d/bind9 stop : pour arrêter
/etc/init.d/bind9 start : pour démarrer
/etc/init.d/bind9 restart : pour redémarrer (si il était démarrer, avec restart, il est éteint, puis redémarrer avec un nouveau processus
/etc/init.d/bind9 reload : pour recharger la configuration (ne stoppe pas avant de recharger)
On peut aussi utiliser « service » avec chacune des commandes décrites pour « init.d »:
Par exemple : « service bind9 restart »
DNS : Composants de Bind9
« /etc/bind/named.conf »
C'est le fichier de configuration centrale de bind.
Il peut se trouver dans différents dossiers (sécurité, chroot)
par exemple dans « /etc/named.conf » ou « /etc/ »
On peut externaliser certains points de configuration de ce fichier central dans des fichiers:
/etc/bind/named.conf.local
/etc/bind/named.conf.options
« /var/named/ »
Il s'agit d'un répertoire de travail.
L'utilitaire rndc
« /usr/sbin/rndc » est le fichier binaire de l'utilitaire de contrôle rndc.
Il permet de gérer Bind9
rndc [b source-adress] [-c config-file] [k key-file] [-s serveur] [-p port] [-V] [-y key-id] {commande}
Après l'installation de bind9, on peut utiliser les commandes rndc suivantes :
reload : pour recharger
stop : arrêter le serveur
flush : vider le cache
status : afficher l'état du serveur
aucune : liste des commandes utilisables
linux configurer dns server et client: Syntaxe des fichiers de configuration
Exemples de fichier : named.conf, named.conf.local, named.conf.options, etc…
Il faut toujours un point virgule pour finir une instruction.
Exemple d’instruction (statements) entre accolades :
Une instruction simple est entre guillemets double.
Par exemple dans le fichier « /etc/bind/named.conf », nous avons :
include "/etc/bind/name.conf.options";
include "/etc/bind/name.conf.local";
include "/etc/bind/name.conf.default-zones";
linux configurer dns server et client: Syntaxe des fichiers de configuration
Options de configuration du DNS
Ils sont souvent situés dans le fichier « named.conf.options ».
Dans l'instruction "option” du fichier named.conf.options, on peut donner les instructions suivantes:
DNS : Syntaxe des fichiers de configuration
L'instruction zones
Permet de définir les paramètres généraux d'une zone.
zone "nom-de-notre-zone" { #1
type master; #2
file "/etc/bind/db.xxx"; #3
#4
}
#1 : Nom de la zone dans l'entête ;
#2 : type (master pour primaire ou slave pour secondaire ou int pour Le programme qui lance le server : /usr/sbin/nracine) ;
#3 : fichier chemin du fichier de configuration de zone
#4 : éventuellement des options
linux configurer dns server et client: prérequis nécessaire avant installation DNS Maître
Il va s'agir de configurer un serveur DNS qui servira de serveur cache pour le système sur lequel Bind va être installé, et qui sera le serveur DNS maître pour les systèmes clients du réseau local.
Soit notre serveur DHCP-DNS nommé : « srv-dhcp-dns »
Adresse IP pour l’interface « enp0s8 » du serveur « srv-dhcp-dns » : 192.168.4.10
Soit notre nom de domaine local : « formation.local »
Soit un poste client sur le réseau local : « poste-client-user01 » avec l'IP 192.168.4.150
En DHCP avec réservation par adresse MAC
Soit un autre poste client sur le réseau local : « poste-client-user02 » avec l’IP 172.20.45.50
En DHCP dans notre deuxième réseau local
Soit notre serveur DHCP relais nommé : « srv-dhcp-relais »
Adresse IP pour l’interface « enp0s9 » du serveur « srv-dhcp-dns » : 172.20.0.10
Même si nous le savons déjà, nous allons taper la commande « hostname » sur notre serveur DHCP-DNS « srv-dhcp-dns » afin de connaître le nom du système sur lequel on installera Bind :
Si on veut le changer pour lui donner un nom plus significatif de sa fonction de server (ça ne sera pas le cas ici), il faut aller dans le fichier « /etc/hostname » :
Puis, il faut redémarrer le serveur afin de prendre en compte le changement du nouveau hostname.
Nous allons maintenant compléter le fichier « /etc/host.conf ». Ce fichier indique quels services de conversion des noms sont disponibles, et dans quel ordre il faut les appliquer.
C’est la partie cliente du système sur lequel va être installé Bind. Un même système peut être à la fois client et serveur, c'est-à-dire, serveur DNS “pour lui-même”.
Nous allons donc indiquer dans quel ordre appliquer cette recherche et enregistrer le fichier :
order hosts = d'abord dans le fichier /etc/hosts
bind = puis par le DNS en cas d'echec
multi on : Autoriser plusieurs adresses par nom
Nous allons maintenant compléter le fichier « /etc/hosts ». Ce fichier permet d’attribuer des noms d'hôtes à chacune des adresses IP.
Il s'agit là encore de l'aspect client du système. On renseigne tous les clients du réseau local ainsi que le nom de domaine de ce système en tant que client.
Nous pouvons maintenant, recharger la configuration réseau pour prendre en compte les modifications avec la commande « /etc/init.d/networking restart » :
DNS : Prérequis nécessaire avant installation DNS Maître
Maintenant, nous allons déclarer notre nom de domaine « formation.local » dans le fichier « /etc/resolv.conf » sans oublier, de retirer les DNS extérieurs, afin que Bind soit consulté.
Par défaut, le fichier ressemble à ça (par rapport à notre configuration dans le TD DHCP) :
Nous modifions donc ce fichier avec les nouvelles données et on enregistre
DNS : Prérequis nécessaire avant installation DNS Maître
Sur le système voué à servir de serveur DNS, s'il a été installé un environnement de bureau, lors du redémarrage du système, la nouvelle configuration du fichier « /etc/resolv.conf » sera effacée par Network Manager.
Deux solutions pour résoudre ce problème :
soit on configure Network Manager
soit on se crée un script de démarrage pour effacer les modifications de Network Manager
Nous allons choisir la solution via le script !
/!\ Attention /!\
Si vous décidez par vous-même de supprimer Network Manager, notez bien que ça déstabilise complètement le système. Cette suppression s’effectue avec cette commande (pour information) :
DNS : Prérequis nécessaire avant installation DNS Maître
1ère solution : Configurer Network Manager
Sur l’interface graphique, il faut aller dans : Système Préférences Connexions réseau
Puis il faut modifier toutes les connexions que vous avez dans tous les onglets (Filaire, Sans fil, etc…), en faisant, pour chacune d’entre-elles :
Cliquez sur la connexion à modifier ;
Bouton « Modifier » ;
Onglet « Paramètres IPv4 » (et aussi IPv6 si vous l’utilisez) ;
Méthode : Adresses automatiques uniquement (DHCP) ;
Serveurs DNS : 127.0.0.1
Puis appliquez les modifications. Si la connexion est partagée entre tous les utilisateurs, un mot de passe administrateur vous sera demandé.
DNS : Prérequis nécessaire avant installation DNS Maître
2ème solution : Script de démarrage pour effacer les modifications de Network Manager
On va modifier le fichier avec un script, en même temps que résoudre le problème « Network Manager », donc inutile d'éditer « /etc/resolv.conf » après l'exécution du script.
Création du script pour Network Manager
On se déplace dans le répertoire « /etc/NetworkManager/dispatcher.d/ » afin de créer le script à l’intérieur de celui-ci et nous faisons un « ls » pour voir les fichiers existants :
DNS : Prérequis nécessaire avant installation DNS Maître
Nous allons donc créer le fichier du script « 99-dns » avec la commande « touch » et nous refaisons un « ls » afin de s’assurer que le fichier a bien été créé. Puis on l’édite et on enregistre :
*99-dns est un nom aléatoire qui a été donné ici mais respectant bien la nomenclature de ce répertoire.
DNS : Prérequis nécessaire avant installation DNS Maître
Bind sera ainsi, le server DNS du système sur lequel il est installé. On peut simplement commenter les anciens paramètres du fichier afin d'avoir sous la main les DNS de Google par exemple (en cas où).
Avant l’exécution du script, il faut mettre les droits utilisateurs « rwxr-xr-x » sur ce fichier.
U = rwx = 4 + 2 + 1 = 7
G = r-x = 4 + 0 + 1 = 5
O = r-x = 4 + 0 + 1 = 5
La commande a utilisé est : « chmod UGO /etc/NetworkManager/dispatcher.d/99-dns »
Vu qu’on est déjà dans le répertoire, la commande a utilisé est donc « chmod 755 99-dns »
DNS : Prérequis nécessaire avant installation DNS Maître
Maintenant, on exécute le script avec la commande « bash » :
On regarde le fichier « /etc/resolv.conf » avec la commande « less » ou « cat » afin de voir si le script a bien renseigné les informations qu’on lui a fournit :
Ce qui retournera ces informations :
domain formation.local
search formation.local
nameserver 192.168.4.10
#nameserver 8.8.8.8
#nameserver 8.8.4.4
linux configurer dns server et client: Bloquer les entrées dans « /etc/resolv.conf »
chattr (Change Attribute) est un utilitaire Linux en ligne de commande qui est utilisé pour définir / annuler certains attributs d'un fichier dans le système Linux pour sécuriser la suppression ou la modification accidentelle de fichiers et dossiers importants, même si vous êtes connecté en tant qu'utilisateur root.
Utilisez la commande ci-dessous pour empêcher « resolv.conf » ou tout autres fichiers de le remplacer après le redémarrage du service réseau et/ou de votre machine.
Pour bloquer la modification et désactiver l'insertion dans le fichier, utilisez la commande ci-dessous:
« chattr +i /etc/resolv.conf » : pour bloquer le fichier (par exemple, pour bloquer le DNS local)
Personne/Rien ne pourra le modifier, y compris l'utilisateur racine.
Pour annuler la modification et réactiver l'insertion dans le fichier, utilisez la commande ci-dessous:
« chattr -i /etc/resolv.conf » : pour débloquer le fichier (par exemple, pour activer le DNS internet)
linux configurer dns server et client: Installation du serveur DNS Maître avec Bind9
Dans le cas où vous partagez votre connexion internet, il est très utile d'utiliser un serveur DNS cache.
Par contre, pour que vos postes clients qui utilisent cette connexion partagée se servent de ce serveur cache DNS, n'oubliez surtout pas de configurer tous les postes pour qu’ils utilisent comme serveur DNS votre serveur et pas un autre.
Pour cela, donnez comme adresse de serveur DNS, l'adresse interne (côté LAN donc) de votre serveur.
Pour commencer, nous allons mettre à jour la liste des paquets existants dont fait parti « bind9 » avec la commande « apt-get update » :
linux configurer dns server et client: Configuration du serveur DNS Maître avec Bind9
Une fois le serveur installé et démarré, nous allons configurer notre premier site.
Tout d’abord, nous allons (en une seule commande) nous déplacer dans le répertoire de bind9 « /etc/bind/ » que nous venons d’installer et observer les différents fichiers :
La mise en place d’un nouveau nom de domaine, aussi appelé zone, se fait par la création d’un fichier (similaire au fichier « db.local »). Ce fichier contient l’ensemble des enregistrements DNS du domaine. Ce sont ces informations qui seront envoyées lors d’une requête DNS. Ils donnent notamment les adresses IPs de plusieurs services, les IPs des sous-domaines, le temps de vie avant revérification des informations (TTL), etc…
Nous allons donc prendre le fichier « db.local » comme modèle (copie) afin de créer notre fichier « db.formation.local » et l’observer :
DNS : Configuration du serveur DNS Maître avec Bind9
Un DNS est constitué de plusieurs enregistrements, les RR ou Ressources Records, définissant les diverses informations relatives au domaine. Le premier enregistrement est consacré à la résolution de noms, dans notre cas, il s'agit du fichier db.example.com. Le second sera quant à lui en rapport avec la résolution de noms inverses ; il s'agit du fichier « db.formation.local »
Il existe différents types d’enregistrements représentant chacun un type information différent.
Ci-dessous figure une liste des enregistrements couramment utilisées.
Enregistrement A
C’est l’enregistrement le plus courant. Il fait correspondre une adresse IPv4 à un nom d’hôte.
www IN A A.B.C.D A.B.C.D étant une adresse IPv4
Enregistrement AAAA
Variante de l’enregistrement A, il fait correspondre une adresse IPv6 à un nom d’hôte.
www IN AAAA ::A
Enregistrement SOA
Il permet de définir les informations relatives à la zone. En l'occurrence le nom du serveur DNS primaire « srv-dhcp-dns.formation.local. » et l'adresse mail du contact technique (« root.example.com. » ; le « @ » est remplace par un point). Il est composé de plusieurs champs :
Serial : est un entier non signé 32 bits. C'est le numéro de série à incrémenter à chaque modification du fichier. Il permet au serveur secondaire de recharger les informations qu'ils ont. L'usage général vient à le formater de cette manière YYYYMMDDXX, soit pour la première modification du 01/04/2007 -> 2007040101, pour la seconde 2007040102.
Refresh : définit la période de rafraîchissement des données.
Retry : si une erreur survient au cours du dernier rafraîchissement, celle-ci sera répétée au bout du délai Retry.
Expire : le serveur sera considéré comme non disponible au bout du délai Expire.
Negative cache TTL : définit la durée de vie d'une réponse NXDOMAIN de notre part.
Enregistrement CNAME (Canonical Name)
Il permet de créer un alias pointant vers un autre enregistrement du domaine courant ou d’un domaine externe.
Il est possible de créer un enregistrement CNAME pointant vers un autre enregistrement CNAME mais cette pratique double le nombre de requêtes, il et donc déconseillé de la pratiquer.
mail IN CNAME www
ftp IN CNAME ftp.domain.tld.
www IN A A.B.C.D
DNS : Configuration du serveur DNS Maître avec Bind9
Enregistrement NS (Name Server)
Il définit les serveurs DNS du domaine. Cet enregistrement doit pointer obligatoirement vers un enregistrement de type A et pas un enregistrement CNAME.
IN NS domain.tld.
ns IN A A.B.C.D
Enregistrement TXT
Il permet de définir un enregistrement contenant un texte libre. Cet enregistrement est notamment utilisé pour confirmer le détenteur du domaine pour pouvoir utiliser certains services externes tel que Google Webmaster tools ou encore un service d’envoi de mails (Mandrill, Mailgun, …).
domain.tld. IN TXT "text"
Avant de poursuivre, nous allons tester nos enregistrements créés pour vérifier s’ils sont corrects afin d’éviter des erreurs au redémarrage de bind.
La commande « dig » va vérifier la syntaxe du fichier passé en paramètre. Nous allons donc l’utiliser pour vérifier sur notre domaine formation.local.
Si la commande « dig » n’est pas disponible, il faut installer le paquet « dnsutils » :
La commande « dig srv-dhcp-dns.formation.local » nous retourne ceci :
Il ne vous reste plus qu’à comparer le retour de la commande avec les enregistrements que vous avez rentrez précédemment pour le domaine. Les enregistrements sont normalement les mêmes.
Maintenant, nous allons créer la recherche inverse en prenant le fichier « db.127 » comme modèle (copie) afin de créer notre fichier « db.192 » et l’observer :
Par défaut, le fichier ressemble à ceci :
Avant de poursuivre, nous allons tester nos enregistrements créés pour vérifier s’ils sont corrects afin d’éviter des erreurs au redémarrage de bind.
La commande « dig » va vérifier la syntaxe du fichier passé en paramètre. Nous allons donc l’utiliser pour vérifier sur l’IP de notre domaine formation.local.
Si la commande « dig » n’est pas disponible, il faut installer le paquet « dnsutils » :
La commande « dig 192.168.4.10 » nous retourne ceci :
Il ne vous reste plus qu’à comparer le retour de la commande avec les enregistrements que vous avez rentrez précédemment pour le domaine. Les enregistrements sont normalement les mêmes.
La configuration du domaine terminée, il est nécessaire maintenant d’inclure cette configuration dans la liste des domaines de bind9 en modifiant le fichier « named.conf.local » :
DNS : Configuration du serveur DNS Maître avec Bind9
Pour définir une déclaration de « zone », il faut d’abord savoir ce que c’est et ce qu’elle contient.
En effet, une déclaration de « zone » définit les caractéristiques d'une zone tels que l'emplacement de ses fichiers de configuration et les options spécifiques à la zone. Cette déclaration peut-être utilisée pour remplacer les déclarations globales d’options.
Une déclaration de zone se présente sous le format suivant :
zone <zone-name> <zone-class> {
<zone-options>;
[<zone-options>; ...]
};
<zone-name> = nom de la zone
<zone-class> = à la classe optionnelle de la zone
<zone-options> = représente une liste des options caractérisant la zone.
L'attribut <zone-name> de la déclaration de zone est particulièrement important, puisqu'il représente la valeur par défaut assignée à la directive $ORIGIN utilisés au sein du fichier de zone correspondant qui se trouve dans le répertoire « /var/named/ ». Le démon « named » attache le nom de la zone à tout nom de domaine qui n'est pas pleinement qualifié, listé dans le fichier de zone.
Par exemple, si une déclaration de zone définit l'espace de nom pour « example.com », utilisez « example.com » comme <zone-name> afin qu'il soit placé à la fin des noms d'hôtes au sein du fichier de zone « example.com ».
De nombreuses options de « zone » sont disponibles, dont beaucoup dépendent l'une de l'autre pour fonctionner correctement. Ci-dessous figure une liste des options couramment utilisées.
allow-query : spécifie les clients qui sont autorisés à requérir des informations à propos de cette zone. Par défaut toutes les requêtes d'informations sont autorisées.
allow-transfer : spécifie les serveurs esclaves qui sont autorisés à requérir un transfert des informations de la zone. Par défaut toutes les requêtes de transfert sont autorisées.
allow-update : spécifie les hôtes qui sont autorisés à mettre à jour dynamiquement des informations dans leur zone. Par défaut aucune requête de mise à jour dynamique n'est autorisée.
Soyez très prudent lorsque vous autorisez des hôtes à mettre à jour des informations à propos de leur zone. Ne mettez en œuvre cette option que si vous accordez une confiance absolue à l'hôte. De manière générale, il est préférable de laisser un administrateur mettre à jour manuellement les enregistrements de la zone et recharger le service « named » service.
file : spécifie le nom du fichier qui contient les données de configuration de la zone, dans le répertoire de travail « named ».
masters : spécifie les adresses IP à partir desquelles demander des informations sur la zone faisant autorité. Cette option ne doit être utilisée que si la zone est définie en tant que « type slave ».
notify : établit si named notifie les serveurs esclaves lorsqu'une zone est mise à jour. Cette directive accepte les options suivantes :
yes : notifie les serveurs esclaves.
no : ne notifie pas les serveurs esclaves.
explicit : notifie seulement les serveurs esclaves spécifiés dans une liste also-notify à l'intérieur d'une déclaration de zone.
zone-statistics : configure « named » pour qu'il conserve des statistiques concernant cette zone, en les écrivant soit dans l'emplacement par défaut (« /var/named/named.stats »), soit à l'emplacement expressément désigné par l'option « statistics-file » dans la déclaration « server ».
type : définit le type de zone. Les types énumérés ci-dessous peuvent être utilisés.
forward : retransmet toutes les requêtes d'informations à propos de cette zone vers d'autres serveurs de noms
hint : un type spécial de zone utilisé pour diriger des transactions vers les serveurs de noms racines qui résolvent des requêtes lorsqu'une zone n'est pas connue autrement. Aucune configuration au-delà de la valeur par défaut n'est nécessaire avec une zone « hint ».
master : désigne le serveur de noms faisant autorité pour cette zone. Une zone devrait être configurée comme de type « master » (maître) si les fichiers de configuration de la zone se trouvent sur le système.
slave : désigne le serveur de noms comme serveur esclave pour cette zone. Cette option spécifie également l'adresse IP du serveur de noms maître pour cette zone.
Un exemple de déclaration de zone pour le serveur de noms primaire hébergeant example.com (192.168.0.1) dont le type est « master » :
zone "example.com" IN {
type master;
file "example.com.zone";
allow-update { none; };
};
Un exemple de déclaration de zone pour le serveur de noms de la zone example.com (192.168.0.1) dont le type est « slave » :
zone "example.com" {
type slave;
file "example.com.zone";
masters { 192.168.0.1; };
};
DNS : Configuration du serveur DNS Maître avec Bind9
Si nous voulons inclure des options dans nos configurations, il faut modifier le fichier « named.conf.options ».
En effet, ce fichier définit les options globales de configuration de serveur et établit des valeurs par défaut pour les autres déclarations.
Cette déclaration peut être utilisée en autres pour spécifier l'emplacement du répertoire de travail « named », ou pour déterminer les types de requêtes autorisés.
Par défaut, le fichier ressemble à ceci :
DNS : Configuration du serveur DNS Maître avec Bind9
De nombreuses options sont disponibles, dont beaucoup dépendent l'une de l'autre pour fonctionner correctement. Ci-dessous figure une liste des options couramment utilisées.
allow-query : spécifie les hôtes autorisés à interroger ce serveur de noms. Par défaut, tous les hôtes sont autorisés à interroger le serveur de noms. Une liste de contrôle d'accès ou un ensemble d'adresses IP ou de réseaux peuvent être utilisés ici afin de n'autoriser que des hôtes précis à interroger le serveur de noms.
allow-recursion : semblable à « allow-query », cette option s'applique à des demandes récursives. Par défaut, tous les hôtes sont autorisés à effectuer des demandes récursives sur le serveur de noms.
blackhole : spécifie les hôtes qui ne sont pas autorisés à interroger le serveur de noms.
directory : change le répertoire de travail « named » pour une valeur autre que la valeur par défaut, /var/named/.
DNS : Configuration du serveur DNS Maître avec Bind9
forward : contrôle le comportement de retransmission d'une directive « forwarders ».
Les options suivantes sont acceptées :
first : établit que les serveurs de noms spécifiés dans la directive « forwarders » soient interrogés avant que « named » ne tente de résoudre le nom lui-même.
only : spécifie que « named » ne doit pas tenter d'effectuer lui-même une résolution de nom dans le cas où des demandes vers les serveurs de noms spécifiés dans la directive « forwarders » échoueraient.
forwarders : spécifie une liste d'adresses IP valides correspondant aux serveurs de noms vers lesquels les requêtes devraient être envoyées pour la résolution.
DNS : Configuration du serveur DNS Maître avec Bind9
forward : contrôle le comportement de retransmission d'une directive « forwarders ».
Les options suivantes sont acceptées :
first : établit que les serveurs de noms spécifiés dans la directive « forwarders » soient interrogés avant que « named » ne tente de résoudre le nom lui-même.
only : spécifie que « named » ne doit pas tenter d'effectuer lui-même une résolution de nom dans le cas où des demandes vers les serveurs de noms spécifiés dans la directive « forwarders » échoueraient.
forwarders : spécifie une liste d'adresses IP valides correspondant aux serveurs de noms vers lesquels les requêtes devraient être envoyées pour la résolution.
listen-on : spécifie l'interface réseau sur laquelle « named » prend note des requêtes. Par défaut, toutes les interfaces sont utilisées.
De cette manière, si le serveur DNS sert également de passerelle, BIND peut être configuré de telle sorte qu'il ne réponde qu'aux requêtes en provenance de l'un des réseaux.
Une directive « listen-on » peut ressembler à l'extrait ci-dessous :
options {
listen-on { 10.0.1.1; };
};
Dans cet exemple, seules les requêtes qui proviennent de l'interface de réseau servant le réseau privé (10.0.1.1) seront acceptées.
notify : établit si « named » notifie les serveurs esclaves lorsqu'une zone est mise à jour. Les options suivantes sont acceptées :
yes : notifie les serveurs esclaves.
no : ne notifie pas les serveurs esclaves.
explicit : notifie seulement les serveurs esclaves spécifiés dans une liste « also-notify » à l'intérieur d'une déclaration de zone.
pid-file : spécifie l'emplacement du fichier de processus ID créé par « named ».
statistics-file : spécifie un autre emplacement des fichiers de statistiques. Par défaut, les « named » sont enregistrées dans le fichier « /var/named/named.stats ».
Avant de redémarrer le serveur, nous allons tester le fichier de domaine créé pour vérifier s’il est correct afin d’éviter des erreurs au redémarrage de bind.
La commande « named-checkzone », inclue dans le package de bind9, va vérifier la syntaxe du fichier passé en paramètre. Nous allons donc l’utiliser pour vérifier sur notre domaine formation.local :
Nous avons obtenu une erreur car il ne faut surtout pas oublier de mettre le FQDN complet !
A savoir « srv-dhcp-dns.formation.local » et non pas uniquement « formation.local » :
Nous pouvons maintenant, redémarrer le service pour prendre en compte les modifications avec la commande « /etc/init.d/bind9 restart » ou avec « service bind9 restart »
linux configurer dns server et client: Configuration du serveur DNS Maître avec Bind9 pour les postes clients
Maintenant, nous allons mettre en place la configuration des postes clients sur notre serveur DNS Maître en éditant les fichiers « /etc/bind/db.formation.local » et « /etc/bind/db.192 ».
DNS : Configuration du serveur DNS Maître avec Bind9 pour les postes clients
Maintenant, nous allons mettre en place la configuration des postes clients sur notre serveur DNS Maître en éditant les fichiers « /etc/bind/db.formation.local » et « /etc/bind/db.192 ».
Nous pouvons maintenant, redémarrer le service pour prendre en compte les modifications avec la commande « /etc/init.d/bind9 restart » ou avec « service bind9 restart » :
Sur chacun des postes clients, il faut configurer les fichiers « /etc/host.conf » et « /etc/resolv.conf ».
Nous allons commencer par modifier le fichier « /etc/host.conf » afin que le serveur bind du réseau local soit interrogé par le client :
order : indique l'ordre des requêtes : ici, d'abord le fichier hosts, puis, en cas d'échec, le serveur de noms qui sera le serveur Bind quand le fichier « /etc/resolv.conf » aura été modifier pour se faire.
multi mis à on : plusieurs adresses IP peuvent être associées à un même nom.
nospoof : oblige, par sécurité, à vérifier la concordance entre adresse IP et nom lors de la résolution d'adresses inverse.
Le client va lire le fichier « hosts.conf » et rechercher l'adresse correspondant au nom demandé d'abord dans le fichier hosts local.
Si la requête échoue, il va s'adresser à Bind, le serveur DNS du réseau local, qui va lui-même demander à des forwarders s'il ne sait pas répondre. Pour qu'il trouve l'adresse de ce serveur DNS, il consulte le fichier « /etc/resolv.conf » qu'il est donc nécessaire de modifier.
Nous continuons en modifiant le fichier « /etc/resolv.conf » afin que le serveur bind du réseau local soit interrogé par le client.
Il y a deux solutions :
Solution N°1 : Installer un script client pour /etc/resolv.conf
Ce qui permet là aussi de ne plus être embêté par Network Manager, mais cette fois il va permettre de renseigner le système client DNS par l'adresse IP du serveur local bind.
Nous allons choisir cette solution via le script !
Solution 2 : Configurer Network Manager
DNS : Configuration des postes clients
1ère solution : Installer un script client pour /etc/resolv.conf (sur tous les postes clients)
On va modifier le fichier avec un script, en même temps que résoudre le problème « Network Manager », donc inutile d'éditer « /etc/resolv.conf » après l'exécution du script.
Création du script pour Network Manager
On se déplace dans le répertoire « /etc/NetworkManager/dispatcher.d/ » afin de créer le script à l’intérieur de celui-ci et nous faisons un « ls » pour voir les fichiers existants :
DNS : Configuration des postes clients
Nous allons donc créer le fichier du script « 99-dns » avec la commande « touch » et nous refaisons un « ls » afin de s’assurer que le fichier a bien été créé. Puis on l’édite et on enregistre :
*99-dns est un nom aléatoire qui a été donné ici mais respectant bien la nomenclature de ce répertoire.
DNS : Configuration des postes clients
Bind sera ainsi, le server DNS du système sur lequel il est installé. On peut simplement commenter les anciens paramètres du fichier afin d'avoir sous la main les DNS de Google par exemple (en cas où).
Avant l’exécution du script, il faut mettre les droits utilisateurs « rwxr-xr-x » sur ce fichier.
U = rwx = 4 + 2 + 1 = 7
G = r-x = 4 + 0 + 1 = 5
O = r-x = 4 + 0 + 1 = 5
La commande a utilisé est : « chmod UGO /etc/NetworkManager/dispatcher.d/99-dns »
Vu qu’on est déjà dans le répertoire, la commande a utilisé est donc « chmod 755 99-dns »
Maintenant, on exécute le script avec la commande « bash » :
On regarde le fichier « /etc/resolv.conf » avec la commande « less » ou « cat » afin de voir si le script a bien renseigné les informations qu’on lui a fournit :
Ce qui retournera ces informations :
domain formation.local
search formation.local
nameserver 192.168.4.10
#nameserver 8.8.8.8
#nameserver 8.8.4.4
Si vous choisissez la 1ère solution, vous devez refaire ces différentes étapes sur tous les postes clients du réseau local.
En l’occurrence, ici, on refait ces étapes sur le poste-client-user02 !
DNS : Configuration des postes clients
2ème solution : Configurer Network Manager
Sur l’interface graphique, il faut aller dans : Système Préférences Connexions réseau
Puis il faut modifier toutes les connexions que vous avez dans tous les onglets (Filaire, Sans fil, etc…), en faisant, pour chacune d’entre-elles :
Cliquez sur la connexion à modifier ;
Bouton « Modifier » ;
Onglet « Paramètres IPv4 » (et aussi IPv6 si vous l’utilisez) ;
Méthode : Adresses automatiques uniquement (DHCP) ;
Serveurs DNS : IP du serveur DNS local à savoir 192.168.4.10
Puis appliquez les modifications. Si la connexion est partagée entre tous les utilisateurs, un mot de passe administrateur vous sera demandé.
Si vous choisissez la 2ème solution, vous devez refaire ces différentes étapes sur tous les postes clients du réseau local.
En l’occurrence, ici, on refait ces étapes sur le poste-client-user02 !
linux configurer dns server et client: vérification des relations DNS/clients
On va commencer par vérifier que le serveur DNS se connaisse lui-même.
Nous tapons la commande « hostname » pour avoir le nom complet sur le système avec Bind :
Avec la commande « nslookup », on va demander l’adresse associée à cet hôte « srv-dhcp-dns » :
Idem pour la zone inverse, on va faire l’inverse de ce que l’on vient de demander.
Avec la commande « nslookup », on va demander le nom associé à cette adresse « 192.168.4.10 » :
Nous avons une réponse dans les deux cas, donc tout est fonctionnel.
On va faire quelques commandes « dig » qui vont permettent d'interroger le serveur DNS et de diagnostiquer les dysfonctionnements dans la résolution de nom.
La commande « dig srv-dhcp-dns » = interrogation du hostname
On va faire quelques commandes « dig » qui vont permettent d'interroger le serveur DNS et de diagnostiquer les dysfonctionnements dans la résolution de nom.
La commande « dig formation.local »
= interrogation simple du nom de domaine
On va faire quelques commandes « dig » qui vont permettent d'interroger le serveur DNS et de diagnostiquer les dysfonctionnements dans la résolution de nom.
La commande « dig -x 192.168.4.10 » = Recherche DNS inversée (PTR doit être établi en amont)
On va faire quelques commandes « dig » qui vont permettent d'interroger le serveur DNS et de diagnostiquer les dysfonctionnements dans la résolution de nom.
Puis, on va vérifier que le serveur DNS connaisse nos postes clients.
Nous tapons la commande « nslookup », on va demander l’adresse associé au hostname de nos deux clients à savoir « poste-user01 » et « poste-user02 ».
Maintenant, on va vérifier que notre serveur relais DHCP ainsi que nos postes clients interrogent bien le DNS local.
Nous tapons la commande « host –a srv-dhcp-dns » sur notre serveur DHCP relais.
Nous tapons la commande « host –a srv-dhcp-dns » sur notre poste client user01.
Nous tapons la commande « host –a srv-dhcp-dns » sur notre poste client user02.
DNS : Vérification des relations DNS/clients
On va faire quelques commandes « dig » depuis notre serveur relais DHCP qui vont permettent d'interroger le serveur DNS et de diagnostiquer les dysfonctionnements dans la résolution de nom.
La commande « dig formation.local »
= interrogation simple du nom de domaine
Si la commande « dig » n’est pas disponible,
il faut installer le paquet « dnsutils ».
On va faire quelques commandes « dig » depuis notre serveur relais DHCP qui vont permettent d'interroger le serveur DNS et de diagnostiquer les dysfonctionnements dans la résolution de nom.
La commande « dig -x 192.168.4.10 »
= Recherche DNS inversée
(PTR doit être établi en amont)
Si la commande « dig » n’est pas
disponible, il faut installer le
paquet « dnsutils ».
On va faire quelques commandes « dig » depuis notre poste client user01 qui vont permettent d'interroger le serveur DNS et de diagnostiquer les dysfonctionnements dans la résolution de nom.
La commande « dig formation.local »
= interrogation simple du nom de domaine
Si la commande « dig » n’est pas disponible,
il faut installer le paquet « dnsutils ».
DNS : Vérification des relations DNS/clients
On va faire quelques commandes « dig » depuis notre poste client user01 qui vont permettent d'interroger le serveur DNS et de diagnostiquer les dysfonctionnements dans la résolution de nom.
La commande « dig -x 192.168.4.10 »
= Recherche DNS inversée
(PTR doit être établi en amont)
Si la commande « dig » n’est pas
disponible, il faut installer le
paquet « dnsutils ».
DNS : Vérification des relations DNS/clients
On va faire quelques commandes « dig » depuis notre poste client user02 qui vont permettent d'interroger le serveur DNS et de diagnostiquer les dysfonctionnements dans la résolution de nom.
La commande « dig formation.local »
= interrogation simple du nom de domaine
Si la commande « dig » n’est pas disponible,
il faut installer le paquet « dnsutils ».
DNS : Vérification des relations DNS/clients
On va faire quelques commandes « dig » depuis notre poste client user02 qui vont permettent d'interroger le serveur DNS et de diagnostiquer les dysfonctionnements dans la résolution de nom.
La commande « dig -x 192.168.4.10 »
= Recherche DNS inversée
(PTR doit être établi en amont)
Si la commande « dig » n’est pas
disponible, il faut installer le
paquet « dnsutils ».
Ce transcript reflète exclusivement l'opinion de ses auteurs et n’engage en aucune façon Consultingit
Besoin d'aides avec Linux??