DNS et DHCP dans CentOS 7 - Réseaux SMB

Index général de la série: Réseaux informatiques pour les PME: introduction

Salut les amis!. Nous verrons dans cet article comment implémenter l'important couple de services pour les réseaux constitués par le DNS et DHCP sur CentOS - Linux, en particulier dans sa version 7.2.

  • Certains articles sur le DNS font référence au fait que la mise en œuvre de ce service est un peu obscure et difficile. Je ne suis pas tout à fait d'accord avec cette affirmation. Je dirais plutôt que c'est un peu conceptuel et que beaucoup de ses fichiers de configuration ont une syntaxe difficile. Heureusement, nous avons des outils pour vérifier, étape par étape, la syntaxe de chaque fichier de configuration que nous modifions. Par conséquent, nous essaierons de rendre la lecture de cet article aussi agréable et agréable que possible..

Pour ceux qui recherchent les bases des deux services, nous vous recommandons fortement de commencer votre recherche sur Wikipedia, à la fois dans ses versions espagnole et anglaise. Il n'en est pas moins vrai que les articles en anglais sont presque toujours plus complets et cohérents. Pourtant, Wikipedia est un très bon point de départ.

Pour ceux d'entre vous qui veulent vraiment en savoir plus sur le DNS et BIND, nous vous recommandons de lire le livre «OReilly - DNS et BIND 4ed" écrit par Paul albitz y Liu Cricket, ou une édition ultérieure qui existe sûrement.

Nous avons déjà publié un article sur le sujet intitulé «DNS et DHCP dans openSUSE 13.2 Harlequin - Réseaux PME»Pour les amoureux de l'environnement graphique. Cependant, à partir de maintenant, ils seront confrontés à des articles sur ce sujet - pas sur d'autres - écrits avec beaucoup d'utilisation de l'émulateur d'un terminal ou d'une console. Wow, dans le style classique utilisé par les administrateurs système UNIX® / Linux.

Si vous souhaitez en savoir plus sur le nom de famille du titre de cet article «Réseaux de PME»Vous pouvez visiter la page de ce blog«Réseaux de PME: première coupe virtuelle«. Vous y trouverez des liens vers de nombreux autres articles publiés.

  • Une fois l'installation du système d'exploitation CentOS 7 terminée avec les packages que nous recommandons, erépertoire l /usr/share/doc/bind-9.9.4/ Il contient une bonne quantité de documentation que nous vous recommandons de consulter avant de vous lancer dans une recherche sur Internet sans savoir au préalable que, du bout des doigts et chez vous, vous pouvez trouver ce que vous cherchez.

Installation du système de base

Données générales du domaine et du serveur DNS

Nom de domaine: fromlinux.fan
Nom du serveur DNS: dns.fromlinux.fan
Adresse IP: 192.168.10.5
Masque de sous-réseau: 255.255.255.0

Installation

Nous commençons par une nouvelle installation ou une nouvelle installation du système d'exploitation CentOS 7 comme indiqué dans l'article précédent «CentOS 7 Hypervisor I - Réseaux SMB«. Nous devons uniquement apporter les modifications suivantes:

  • Sur Image 22 «SÉLECTION DU LOGICIEL«, Nous vous recommandons de choisir dans la colonne de gauche«Environnement de base»L'option correspondant à un«Serveur d'infrastructure«, Alors que dans la colonne de droite«Plugins pour l'environnement sélectionné»Cochez la case«Serveur de noms DNS«. Nous installerons le serveur DHCP plus tard.
  • Rappelons-nous la déclaration des référentiels supplémentaires comme indiqué dans le Image 23, après avoir réglé le «NOM DU RÉSEAU ET DE L'ÉQUIPE«.
  • Les images faisant référence aux partitions que nous allons créer sur notre disque dur ne sont données qu'à titre indicatif. N'hésitez pas à sélectionner les partitions à votre propre discrétion, pratique et bon jugement.
  • Enfin, dans le Image 13 «NOM DU RÉSEAU ET DE L'ÉQUIPE», il faut changer les valeurs en fonction des paramètres généraux du domaine déclaré et du serveur DNS, sans oublier de préciser le nom d'hôte -dans ce cas «dns«- une fois la configuration du réseau terminée. C'est positif de faire ping -à partir d'un autre hôte- à l'adresse IP spécifiée une fois le réseau actif:

DNS et DHCP sur CentOS

Il y a vraiment peu de changements très évidents à faire par rapport à l'article précédent.

Contrôles et ajustements initiaux

Après avoir installé le système d'exploitation, nous devons au moins revoir les fichiers suivants, et pour cela nous démarrons une session via SSH à partir de notre ordinateur sysadmin.fromlinux.fan:

buzz @ sysadmin: ~ $ ssh 192.168.10.5
Mot de passe de buzz@192.168.10.5: Dernière connexion: Sam 28 Jan 09:48:05 2017 from 192.168.10.1
[buzz @ dns ~] $

L'opération ci-dessus peut prendre plus de temps que la normale, et cela est principalement dû au fait que nous n'avons pas encore de DNS sur le LAN. Vérifiez à nouveau plus tard que DNS fonctionne.

[buzz @ dns ~] $ cat / etc / hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 :: 1 localhost localhost.localdomain localhost6 localhost6.localdomain6

[buzz @ dns ~] $ cat / etc / hostname
dns

[buzz @ dns ~] $ cat / etc / sysconfig / network-scripts / ifcfg-eth0
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=eth0
UUID=946f5ac9-238a-4a94-9acb-9e3458c680fe
DEVICE=eth0
ONBOOT=yes
IPADDR=192.168.10.5
PREFIX=24
GATEWAY=192.168.10.1
DNS1=127.0.0.1
DOMAIN=desdelinux.fan

[buzz @ dns ~] $ cat /etc/resolv.conf 
# Généré par la recherche NetworkManager à partir du serveur de noms linux.fan 127.0.0.1

Les principales configurations répondent à nos sélections. Notez que même sur un serveur Red Hat 7 - CentOS 7, est configuré par défaut lorsque Gestionnaire de réseau afin que ce soit celui qui gère les interfaces réseau, qu'elles soient filaires ou sans fil (WiFi), les connexions VPN, les connexions PPPoE, et toute autre connexion réseau.

[buzz @ dns ~] $ sudo systemctl status networkmanager
[sudo] mot de passe pour le buzz: ● networkmanager.service Chargé: introuvable (Raison: aucun fichier ou répertoire de ce type) Actif: inactif (mort)

[buzz @ dns ~] $ sudo systemctl status NetworkManager
● NetworkManager.service - Network Manager Loaded: chargé (/usr/lib/systemd/system/NetworkManager.service; activé; préréglage du fournisseur: activé) Actif: actif (en cours) depuis le samedi 2017/01/28 12:23:59 EST; Il y a 12 minutes PID principal: 705 (NetworkManager) CGroup: /system.slice/NetworkManager.service └─705 / usr / sbin / NetworkManager --no-daemon

Red Hat - CentOS vous permet également de connecter et de déconnecter des interfaces réseau à l'aide des commandes classiques si haut e si bas. Exécutons sur une console serveur:

[root @ dns ~] # ifdown eth0
Le périphérique 'eth0' a été déconnecté avec succès.

[root @ dns ~] # ifup eth0
Connexion activée avec succès (chemin actif D-Bus: / org / freedesktop / NetworkManager / ActiveConnection / 1)
  • Nous suggestons ne modifiez pas les paramètres par défaut proposés par CentOS 7 par rapport à Gestionnaire de réseau.

Nous déclarons définitivement les référentiels que nous allons utiliser et mettons à jour le système d'exploitation si nécessaire:

[buzz @ dns ~] $ su Mot de passe: [root @ dns buzz] # cd /etc/yum.repos.d/
[root @ dns yum.repos.d] # ls -l
total 28 -rw-r - r--. 1 racine racine 1664 9 décembre 2015 CentOS-Base.repo -rw-r - r--. 1 racine racine 1309 9 décembre 2015 CentOS-CR.repo -rw-r - r--. 1 racine racine 649 9 décembre 2015 CentOS-Debuginfo.repo -rw-r - r--. 1 racine racine 290 9 décembre 2015 CentOS-fasttrack.repo -rw-r - r--. 1 racine racine 630 9 décembre 2015 CentOS-Media.repo -rw-r - r--. 1 racine racine 1331 9 décembre 2015 CentOS-Sources.repo -rw-r - r--. 1 racine racine 1952 9 décembre 2015 CentOS-Vault.repo

Il est sain de lire le contenu des fichiers de déclaration d'origine à partir des référentiels recommandés par CentOS. Les changements que nous apportons ici sont dus au fait que nous n'avons pas accès à Internet et que nous travaillons avec des référentiels locaux téléchargés depuis le Village WWW, par des collègues qui nous facilitent un peu la vie. 😉

[root @ dns yum.repos.d] # mkdir original
[root @ dns yum.repos.d] # mv CentOS- * original /

[root @ dns yum.repos.d] # nano centos-repos.repo
[centos-base]
name=CentOS-$releasever
baseurl=http://10.10.10.1/repos/centos/7/base/
gpgcheck=0
enabled=1

[centos-updates]
name=CentOS-$releasever
baseurl=http://10.10.10.1/repos/centos/7/updates/x86_64/
gpgcheck=0
enabled=1

[root @ dns yum.repos.d] # miam nettoyer tout
Plugins chargés: fastmirror, langpacks Nettoyage des référentiels: centos-base centos-updates Nettoyer tout

[root @ dns yum.repos.d] # yum mise à jour
Plugins chargés: plus rapide mirror, langpacks centos-base | 3.4 ko 00:00 centos-mises à jour | 3.4 ko 00:00 (1/2): centos-base / primary_db | 5.3 Mo 00:00 (2/2): centos-updates / primary_db | 9.1 Mo 00:00 Détermination des miroirs les plus rapides Aucun paquet marqué pour la mise à jour

Le message «Aucun (il y a) des paquets marqués pour mise à jour» - «Aucun package marqué pour mise à jour»Indique qu'en déclarant les référentiels les plus à jour disponibles lors de l'installation, précisément les packages les plus récents ont été installés.

À propos du contexte SELinux et du pare-feu

Nous allons centrer cet article - fondamentalement - sur la mise en œuvre des services DNS et DHCP, qui est son objectif principal.

Si un lecteur a sélectionné une politique de sécurité pendant le processus d'installation, comme indiqué dans le Image 06 de l'article de référence «CentOS 7 Hypervisor I - Réseaux SMB»Utilisé pour l'installation de ce serveur DNS - DHCP, et vous constatez que vous ne savez pas comment configurer correctement SELinux et le pare-feu CentOS, nous vous suggérons d'exécuter ce qui suit:

Modifier le fichier / etc / sysconfig / selinux et changer SELINUX = appliquer par SELINUX = désactiver

[root @ dns ~] # nano / etc / sysconfig / selinux
# Ce fichier contrôle l'état de SELinux sur le système. # SELINUX = peut prendre l'une de ces trois valeurs: # enforcing - La politique de sécurité SELinux est appliquée. # permissive - SELinux affiche des avertissements au lieu de les appliquer. # disabled - Aucune stratégie SELinux n'est chargée.
SELINUX = désactivé
# SELINUXTYPE = peut prendre l'une des trois valeurs suivantes: # target - Les processus ciblés sont protégés, # minimum - Modification de la politique ciblée. Seuls les processus sélectionnés sont pr $ # mls - Protection de sécurité à plusieurs niveaux. SELINUXTYPE = ciblé

Ensuite, exécutez les commandes suivantes

[root @ dns ~] # setenforce 0
[root @ dns ~] # service firewalld arrêt
Redirection vers / bin / systemctl stop firewalld.service

[root @ dns ~] # systemctl désactiver le pare-feud
Suppression du lien symbolique /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service. Suppression du lien symbolique /etc/systemd/system/basic.target.wants/firewalld.service.

Si vous implémentez un serveur DNS faisant face à Internet, vous ne devez PAS faire ce qui précède, mais configurer correctement le contexte SELinux et le pare-feu. Voir "Configuration du serveur avec GNU / Linux, par l'auteur Joel Barrios Dueñas" ou la documentation CentOS elle-même - Red Hat

Nous configurons le BIND - nommé

  • Erépertoire l /usr/share/doc/bind-9.9.4/ contient une bonne quantité de documentation que nous vous recommandons de consulter avant de vous lancer dans une recherche sur Internet sans savoir au préalable que, du bout des doigts et chez vous, vous pouvez trouver ce que vous cherchez

Dans de nombreuses distributions, le service DNS installé via le package BIND est appelé nommé (Démon de nom). Dans CentOS 7, il est installé désactivé par défaut, selon la sortie de la commande suivante, où il indique que son état est «handicapé«, Et que cet état est prédéfini par son« vendeur »- préréglage du fournisseur. Pour mémoire, BIND est un logiciel libre.

Activation du service nommé

[root @ dns ~] # statut systemctl nommé
● named.service - Berkeley Internet Name Domain (DNS) Loaded: chargé (/usr/lib/systemd/system/named.service; handicapé; préréglage du fournisseur: désactivé) Actif: inactif (mort)

[root @ dns ~] # systemctl enable nommé
Création d'un lien symbolique depuis /etc/systemd/system/multi-user.target.wants/named.service vers /usr/lib/systemd/system/named.service.

[root @ dns ~] # systemctl start nommé

[root @ dns ~] # statut systemctl nommé
● named.service - Berkeley Internet Name Domain (DNS) Loaded: chargé (/usr/lib/systemd/system/named.service; activée; préréglage du fournisseur: désactivé)
   Actif: actif (en cours d'exécution) depuis le samedi 2017 janvier 01 à 28:13:22 EST; Il y a 38min Processus: 5 ExecStart = / usr / sbin / named -u nommé $ OPTIONS (code = sorti, status = 1990 / SUCCESS) Process: 0 ExecStartPre = / bin / bash -c if [! "$ DISABLE_ZONE_CHECKING" == "oui"]; puis / usr / sbin / named-checkconf -z /etc/named.conf; else echo "La vérification des fichiers de zone est désactivée"; fi (code = exit, status = 1988 / SUCCESS) PID principal: 0 (nommé) CGroup: /system.slice/named.service └─1993 / usr / sbin / named -u named 1993 janvier 28:13:22 dns named [45]: erreur (réseau inaccessible) lors de la résolution de «./NS/IN»: 1993: 2001: 500f :: f # 2 53 janvier 28:13:22 DNS nommé [47]: erreur (réseau inaccessible) lors de la résolution de «./ DNSKEY / IN ': 1993: 2001: 500 :: 3 # 42 53 janvier 28:13:22 DNS nommé [47]: erreur (réseau inaccessible) lors de la résolution de' ./NS/IN ': 1993: 2001: 500 :: 3 # 42 53 janvier 28:13:22 DNS nommé [47]: erreur (réseau inaccessible) lors de la résolution de «./DNSKEY/IN»: 1993: 2001: 500d :: d # 2 53 janvier 28:13:22 DNS nommé [47 ]: erreur (réseau inaccessible) lors de la résolution de «./NS/IN»: 1993: 2001: 500d :: d # 2 53 janvier 28:13:22 DNS nommé [47]: erreur (réseau inaccessible) lors de la résolution de «./DNSKEY/ IN ': 1993: dc2001 :: 3 # 35 53 janvier 28:13:22 DNS nommé [47]: erreur (réseau inaccessible) lors de la résolution de' ./NS/IN ': 1993: dc2001 :: 3 # 35 53 janvier 28: 13:22 DNS nommé [47]: erreur (réseau inaccessible) résolution de «./DNSKEY/IN»: 1993: 2001fe :: 7 # 53 53 janvier 28:13:22 DNS nommé [47]: erreur (réseau inaccessible) res olving './NS/IN': 1993: 2001fe :: 7 # 53 53 janvier 28:13:22 DNS nommé [48]: managed-keys-zone: Impossible de récupérer l'ensemble DNSKEY '.': expiration du délai

[root @ dns ~] # redémarrage systemctl nommé

[root @ dns ~] # statut systemctl nommé
● named.service - Berkeley Internet Name Domain (DNS) Loaded: chargé (/usr/lib/systemd/system/named.service; activé; prédéfini du fournisseur: désactivé)
   Actif: actif (en cours d'exécution) depuis le sam. 2017-01-28 13:29:41 EST; Il y a 1s Processus: 1449 ExecStop = / bin / sh -c / usr / sbin / rndc stop> / dev / null 2> & 1 || / bin / kill -TERM $ MAINPID (code = sorti, statut = 0 / SUCCESS) Processus: 1460 ExecStart = / usr / sbin / named -u nommé $ OPTIONS (code = sorti, status = 0 / SUCCESS) Process: 1457 ExecStartPre = / bin / bash -c si [! "$ DISABLE_ZONE_CHECKING" == "oui"]; puis / usr / sbin / named-checkconf -z /etc/named.conf; else echo "La vérification des fichiers de zone est désactivée"; fi (code = sorti, statut = 0 / SUCCESS) PID principal: 1463 (nommé) CGroup: /system.slice/named.service └─1463 / usr / sbin / named -u nommé 28 janvier 13:29:41 dns nommé [1463]: managed-keys-zone: le fichier journal est obsolète: suppression du fichier journal le 28 janvier 13:29:41 DNS nommé [1463]: managed-keys-zone: série chargée le 2 28 janvier 13:29:41 dns named [1463]: zone 0.in-addr.arpa/IN: série chargée 0 28 janvier 13:29:41 dns nommée [1463]: zone localhost.localdomain / IN: série chargée 0 28 janvier 13:29:41 dns nommé [1463]: zone 1.0.0.127.in-addr.arpa/IN: série chargée 0 28 janvier 13:29:41 DNS nommé [1463]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .6.ip0.arpa / IN: série chargée 28 13 janvier 29:41:1463 DNS nommé [0]: zone localhost / IN: série chargée 28 13 janvier 29 : 41: 1463 DNS nommé [28]: toutes les zones chargées le 13 janvier 29:41:1463 DNS nommé [28]: exécuté le 13 janvier 29:41:1 dns systemd [XNUMX]: Démarrage du domaine de nom Internet (DNS) de Berkeley.

Après avoir activé le service nommé et nous le démarrons pour la première fois, la sortie de la commande statut systemctl nommé montre des erreurs. Lorsque nous redémarrons le service ci-dessous, le nommé crée tous les fichiers de configuration qui, par défaut, sont nécessaires à son bon fonctionnement. Par conséquent, lorsque nous exécutons à nouveau la commande statut systemctl nommé plus aucune erreur n'est affichée.

  • Cher lecteur, cher et exigeant: si vous voulez savoir - au moins - quel chemin mène à la fin du terrier du lapin, veuillez lire calmement les résultats détaillés de chaque commande. 😉 L'article vous paraîtra sûrement un peu long, mais ne niez pas qu'il gagne en explication et en clarté.

Nous modifions le fichier /etc/named.conf

De nombreux commentaires de lecteurs expriment -Je ne le dis pas- La manie des mainteneurs de différentes distributions Linux, de placer les fichiers de configuration système dans des dossiers avec des noms différents selon la distribution. Ont raison. Mais que pouvons-nous, les simples utilisateurs qui utilisent ces distributions, faire? Adapter! 😉

Au fait, dans FreeBSD, UNIX® clone «The Origin», le fichier est /usr/local/etc/namedb/named.conf; tandis que dans Debian, en plus de la division en quatre fichiers named.conf, named.conf.options, named.conf.default-zones et named.conf.local, est dans le dossier / etc / bind /. Ceux qui veulent savoir où openSUSE le place, lisez «DNS et DHCP dans openSUSE 13.2 Harlequin - Réseaux PME«. Les lecteurs ont raison! 😉

Et comme nous le faisons toujours: avant de modifier quoi que ce soit, nous sauvegardons le fichier de configuration d'origine sous un autre nom.

[root @ dns ~] # cp /etc/named.conf /etc/named.conf.original

Pour vous faciliter la vie, au lieu de générer la clé TSIG pour les mises à jour DNS dynamiques par DHCP, nous copions la même clé rndc.clé comme dhcp.key.

[root @ dns ~] # cp /etc/rndc.key /etc/dhcp.key

[root @ dns ~] # nano /etc/dhcp.key
clé "dhcp-key" {algorithme hmac-md5; secret "OI7Vs + TO83L7ghUm2xNVKg =="; };

Pour que le nommé peut lire le fichier qui vient d'être copié, on modifie son groupe propriétaire:

[root @ dns ~] # chown root: nommé /etc/dhcp.key [root @ dns ~] # ls -l /etc/rndc.key /etc/dhcp.key -rw-r -----. 1 racine nommée 77 28 janvier 16:36 /etc/dhcp.key -rw-r -----. 1 racine nommée 77 28 janvier 13:22 /etc/rndc.key

De petits détails comme le précédent sont ce qui peut nous rendre fous en essayant de savoir, maintenant ... où est le problème ...? avec quelques adjectifs supplémentaires, que nous n'écrivons pas par respect pour le respectable.

Maintenant si - enfin! - on modifie le fichier /etc/named.conf. Les modifications ou ajouts que nous avons apportés, par rapport à l'original, sont en audacieux. Regardez bien combien.

[root @ dns ~] # nano /etc/named.conf
// // named.conf // // Fourni par le package de liaison Red Hat pour configurer le serveur DNS // ISC BIND named (8) en tant que serveur de noms de mise en cache uniquement (en tant que résolveur DNS de l'hôte local uniquement). // // Voir / usr / share / doc / bind * / sample / pour des fichiers de configuration nommés. //

// Liste de contrôle d'accès déclarant quels réseaux pourront consulter
// mon serveur nommé
acl embourbé {
 127.0.0.0 / 8;
 192.168.10.0 / 24;
};

choix {
 // Je déclare que le démon nommé écoute également l'interface
 // eth0 qui a l'IP: 192.168.10.5
    port d'écoute 53 {127.0.0.1; 192.168.10.5; };
    port d'écoute sur v6 53 {:: 1; }; répertoire "/ var / named"; fichier de vidage "/var/named/data/cache_dump.db"; fichier-statistiques "/var/named/data/named_stats.txt"; fichier-memstatistics "/var/named/data/named_mem_stats.txt";

 // Déclaration des transitaires
 // transitaires {
 // 0.0.0.0;
 // 1.1.1.1;
 //};
    // avance en premier;

    // J'autorise uniquement les requêtes sur mon ACL embourbé
    allow-query {mired; }; // Pour vérifier avec la commande dig de linux.fan axfr // depuis le poste de travail SysAdmin et localhost uniquement // Nous n'avons pas de serveurs DNS esclaves. Nous n'en avons pas besoin ... jusqu'à maintenant.
 allow-transfer {localhost; 192.168.10.1; };

    / * - Si vous créez un serveur DNS AUTORITATIF, n'activez PAS la récursivité. - Si vous créez un serveur DNS RECURSIF (mise en cache), vous devez activer la récursivité. - Si votre serveur DNS récursif a une adresse IP publique, vous DEVEZ activer le contrôle d'accès pour limiter les requêtes à vos utilisateurs légitimes. Si vous ne le faites pas, votre serveur fera partie des attaques d'amplification DNS à grande échelle. La mise en œuvre de BCP38 au sein de votre réseau réduirait considérablement cette surface d'attaque * /
    // Nous voulons un serveur AUTHORITY pour notre LAN - PME
    récursivité non;

    dnssec-enable oui; dnssec-validation oui; / * Chemin d'accès à la clé ISC DLV * / bindkeys-file "/etc/named.iscdlv.key"; répertoire-clés-gérées "/ var / named / dynamic"; fichier pid "/run/named/named.pid"; session-keyfile "/run/named/session.key"; }; journalisation {canal default_debug {fichier "data / named.run"; dynamique de gravité; }; }; zone "." IN {indice de type; fichier "named.ca"; }; inclure "/etc/named.rfc1912.zones"; inclure "/etc/named.root.key";

// Nous incluons la clé TSIG pour les mises à jour DNS dynamiques // par DHCP
inclure "/etc/dhcp.key";

// Déclaration du nom, du type, de l'emplacement et de l'autorisation de mise à jour
// des zones d'enregistrements DNS // les deux zones sont des MAÎTRES
zone "desdelinux.fan" {
 type maître;
 fichier "dynamic / db.fromlinux.fan";
 allow-update {clé dhcp-key; };
};

zone "10.168.192.in-addr.arpa" {
 type maître;
 fichier "dynamic / db.10.168.192.in-addr.arpa";
 allow-update {clé dhcp-key; };
};

Nous vérifions la syntaxe

[root @ dns ~] # named-checkconf 
[root @ dns ~] #

Puisque la commande ci-dessus ne renvoie rien, la syntaxe est correcte. Cependant, si nous exécutons la même commande, mais avec l'option -z, la sortie sera:

[root @ dns ~] # named-checkconf -z
zone localhost.localdomain / IN: zone série 0 chargée localhost / IN: zone série 0 chargée 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .ip6.arpa / IN: zone série 0 chargée 1.0.0.127.in-addr.arpa/IN: zone série 0 chargée 0.in-addr.arpa/IN: zone série 0 chargée depuis linux.fan/IN: chargement depuis le maître échec du fichier dynamic / db.from linux.fan: fichier introuvable zone de linux.fan/IN: non chargé en raison d'erreurs. _default / desdelinux.fan / IN: fichier introuvable zone 10.168.192.in-addr.arpa/IN: chargement depuis le fichier maître dynamic / db.10.168.192.in-addr.arpa a échoué: fichier introuvable zone 10.168.192 .in-addr.arpa / IN: non chargé en raison d'erreurs. _default / 10.168.192.in-addr.arpa / IN: fichier introuvable

Bien sûr, ce sont des erreurs qui se produisent parce que nous n'avons pas encore créé les zones d'enregistrement DNS pour notre domaine.

  • Pour plus d'informations sur la commande nommé-checkconf, courir homme nommé-checkconf, avant de rechercher toute autre information sur Internet. Je vous assure que cela vous fera gagner beaucoup de temps.

Nous créons le fichier Direct Zone à partir de linux.fan

... pas sans un peu de théorie d'abord. 😉

Comme modèle pour créer le fichier de données de zone, nous pouvons prendre le /var/named/named.empty, ou /usr/share/doc/bind-9.9.4/sample/var/named/named.empty. Les deux sont identiques.

[root @ dns ~] # cat /var/named/named.empty 
$ TTL 3H @ IN SOA @ rname.invalid. (0; série 1D; rafraîchir 1H; réessayer 1W; expirer 3H); durée de mise en cache minimale ou négative pour vivre NS @ A 127.0.0.1 AAAA :: 1

Temps de vie - Il est temps de vivre TTL Enregistrement SOA

Prenons une parenthèse pour expliquer le TTL - Il est temps de vivre du registre SOA - Début de l'autorité d'une zone maître. Il est intéressant de connaître leur signification lorsque nous voulons modifier l'une de leurs valeurs.

$ TTL: Temps de vie - Temps de vivre pour tous les enregistrements du fichier qui suivent la déclaration (mais qui précèdent toute autre déclaration $ TTL) et qui n'ont pas de déclaration TTL explicite.

en série: Numéro de série des données de zone. Chaque fois que nous modifions manuellement un enregistrement DNS dans une zone, nous devons augmenter ce nombre de 1, surtout si nous avons des serveurs esclaves ou secondaires. Chaque fois qu'un serveur DNS secondaire ou esclave contacte son serveur maître, il demande le numéro de série des données du maître. Si le numéro de série de l'esclave est inférieur, les données de cette zone sur le serveur esclave sont obsolètes et l'esclave effectue un transfert de zone pour se mettre à jour.

rafraîchir: Il indique au serveur esclave l'intervalle de temps dans lequel il doit vérifier si ses données sont à jour par rapport au maître.

recommencez: Si le serveur maître n'est pas disponible - parce qu'il est tombé malade, disons - pour l'esclave après un intervalle de temps rafraîchir, recommencez Il indique à l'esclave combien de temps attendre avant d'essayer de contacter à nouveau son maître.

expirer: Si l'esclave ne peut pas contacter son maître pendant un certain temps expirer, alors si la relation de zone esclave-maître a été foirée et que le serveur esclave n'a d'autre choix que d'expirer la zone en question. L'expiration d'une zone par un serveur DNS esclave signifie qu'il cessera de répondre aux requêtes DNS liées à cette zone, car les données disponibles sont trop anciennes pour être utiles.

  • Ce qui précède nous apprend indirectement et chargé d'un grand bon sens - le moins commun des sens - que si nous n'avons pas besoin de serveurs DNS esclaves pour le fonctionnement de notre PME, nous ne les implémentons pas, à moins qu'ils ne soient strictement nécessaires. Essayons toujours de passer du simple au complexe.

minimum: Dans les versions antérieures à LIER 8.2, le dernier enregistrement SOA Il indique également la durée de vie par défaut - Temps de vie par défaut, et durée de vie négative du cache - Temps de mise en cache négatif pour vivre pour la zone. Cette heure fait référence à toutes les réponses négatives données par le serveur faisant autorité pour la zone.

Fichier de zone /var/named/dynamic/db.fromlinux.fan

[root @ dns ~] # nano /var/named/dynamic/db.fromlinux.fan
$ TTL 3H @ IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. (1; série 1D; rafraîchir 1H; réessayer 1W; expirer 3H); minimum ou; Temps de mise en cache négatif pour vivre; @ IN NS dns.fromlinux.fan. @ IN MX 10 mail.fromlinux.fan. @ IN TXT "FromLinux, votre Blog dédié au Logiciel Libre"; sysadmin IN A 192.168.10.1 ad-dc IN A 192.168.10.3 fileserver IN A 192.168.10.4 dns IN A 192.168.10.5 proxyweb IN A 192.168.10.6 blog IN A 192.168.10.7 ftpserver IN A 192.168.10.8 mail IN A 192.168.10.9

Nous vérifions /var/named/dynamic/db.fromlinux.fan

[root @ dns ~] # named-checkzone de linux.fan / var / named / dynamic / db. fromlinux.fan
zone de linux.fan/IN: série chargée 1 OK

Nous créons le fichier de zone inversée 10.168.192.in-addr.arpa

  • L'enregistrement SOA de cette zone est le même que celui de la zone directe sans tenir compte de l'enregistrement MX..
[root @ dns ~] # nano /var/named/dynamic/db.10.168.192.in-addr.arpa
$ TTL 3H @ IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. (1; série 1D; rafraîchir 1H; réessayer 1W; expirer 3H); minimum ou; Temps de mise en cache négatif pour vivre; @ IN NS dns.fromlinux.fan. ; 1 IN PTR sysadmin.fromlinux.fan. 3 IN PTR ad-dc.fromlinux.fan. 4 IN PTR fileserver.fromlinux.fan. 5 IN PTR dns.fromlinux.fan. 6 DANS PTR proxyweb.desdelinux.fan. 7 DANS PTR blog.desdelinux.fan. 8 DANS PTR ftpserver.fromlinux.fan. 9 DANS PTR mail.fromlinux.fan.

[root @ dns ~] # named-checkzone 10.168.192.in-addr.arpa /var/named/dynamic/db.10.168.192.in-addr.arpa 
zone 10.168.192.in-addr.arpa/IN: série chargée 1 OK

Avant de redémarrer le named nous vérifions sa configuration

  • Tant que nous ne sommes pas sûrs que les fichiers de configuration nommés, named.conf, et ses fichiers de zone ne sont pas configurés correctement, nous vous suggérons de ne pas redémarrer le démon named. Si nous faisons cela et modifions ultérieurement un fichier de zone, nous devons augmenter le numéro de série de la zone modifiée de 1.
  • Regardons le "." à la fin des noms de domaine et d'hôte.
[root @ dns ~] # named-checkconf 
[root @ dns ~] # named-checkconf -z
zone localhost.localdomain / IN: zone série 0 chargée localhost / IN: zone série 0 chargée 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .ip6.arpa / IN: zone série 0 chargée 1.0.0.127.in-addr.arpa/IN: zone série 0 chargée 0.in-addr.arpa/IN: zone série 0 chargée depuis linux.fan/IN: série série 1 chargée zone 10.168.192.in-addr.arpa/IN: série 1 chargée

Toute la configuration nommée actuelle

Pour plus de clarté, et bien que l'article devienne long, nous donnons la sortie complète de la commande nommé-checkconf -zp:

[root @ dns ~] # named-checkconf -zp
zone localhost.localdomain / IN: zone série 0 chargée localhost / IN: zone série 0 chargée 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .ip6.arpa / IN: zone série 0 chargée 1.0.0.127.in-addr.arpa/IN: zone série 0 chargée 0.in-addr.arpa/IN: zone série 0 chargée depuis linux.fan/IN: série série 1 chargée zone 10.168.192.in-addr.arpa/IN: options série 1 chargées {fichier bindkeys "/etc/named.iscdlv.key"; session-keyfile "/run/named/session.key"; répertoire "/ var / named"; fichier de vidage "/var/named/data/cache_dump.db"; port d'écoute 53 {127.0.0.1/32; 192.168.10.5/32; }; port d'écoute sur v6 53 {:: 1/128; }; répertoire-clés-gérées "/ var / named / dynamic"; fichier-memstatistics "/var/named/data/named_mem_stats.txt"; fichier pid "/run/named/named.pid"; fichier-statistiques "/var/named/data/named_stats.txt"; dnssec-enable oui; dnssec-validation oui; récursivité non; allow-query {"embourbé"; }; autoriser le transfert {192.168.10.1/32; }; }; acl "embourbé" {127.0.0.0/8; 192.168.10.0/24; }; journalisation {canal "default_debug" {fichier "data / named.run"; dynamique de gravité; }; }; key "dhcp-key" {algorithme "hmac-md5"; secret "OI7Vs + TO83L7ghUm2xNVKg =="; }; zone "." IN {indice de type; fichier "named.ca"; }; zone "localhost.localdomain" IN {type master; fichier "named.localhost"; allow-update {"aucun"; }; }; zone "localhost" IN {type master; fichier "named.localhost"; allow-update {"aucun"; }; }; zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {type maître; fichier "named.loopback"; allow-update {"aucun"; }; }; zone "1.0.0.127.in-addr.arpa" IN {type master; fichier "named.loopback"; allow-update {"aucun"; }; }; zone "0.in-addr.arpa" IN {type master; fichier "named.empty"; allow-update {"aucun"; }; }; zone "desdelinux.fan" {type maître; fichier "dynamic / db.fromlinux.fan"; allow-update {clé "dhcp-key"; }; }; zone "10.168.192.in-addr.arpa" {type maître; fichier "dynamic / db.10.168.192.in-addr.arpa"; allow-update {clé "dhcp-key"; }; }; clés-gérées {"." clé initiale-257 Août 3 "AwEAAagAIKlVZrpC8Ia6gEzahOR + 7W9euxhJhVVLOyQbSEW29O0gcCjF FVQUTf8v6fLjwBd58YI0EzrAcQqBGCzh / RStIoO0g8NfnfL0MTJRkxoX bfDaUeVPQuYEhg2NZWAJQ37VnMVDxP / VHL9M / QZxkjf496 / Efucp5gaD X2RS6CXpoY6LsvPVjR68ZSwzz0apAzvN1dlzEheX9ICJBBtuA7G6LQpz W3hOA5hzCTMjJPJ2LbqF8dsV6DoBQzgul6sGIcGOYl0OyQdXfZ7relS Qageu + ipAdTTJ57AsRTAoub25ONGcLmqrAmRLKBP8dfwhYB1N4knNnulq QXA + Uk7ihz1 ="; };
  • Suite à la procédure de modification du nommé.conf Selon nos besoins et vérifier, et créer chaque fichier de zone et le vérifier, nous doutons que nous devrons faire face à des problèmes de configuration majeurs. Au final on se rend compte que c'est un jeu de garçon, avec de nombreux concepts et une syntaxe pointilleuse,

Les contrôles ont donné des résultats satisfaisants, nous pouvons donc redémarrer le BIND - nommé.

Nous redémarrons le nommé et vérifions son statut

[root @ dns ~] # redémarrage systemctl named.service
[root @ dns ~] # statut systemctl named.service

Si nous obtenons une erreur quelconque dans la sortie de la dernière commande, nous devons redémarrer le service.nommé et revérifiez votre Commande. Si les erreurs ont disparu, le service a démarré avec succès. Sinon, nous devons procéder à un examen approfondi de tous les fichiers modifiés et créés, et répéter la procédure.

La sortie correcte de l'état doit être:

[root @ dns ~] # statut systemctl named.service
● named.service - Berkeley Internet Name Domain (DNS) Loaded: chargé (/usr/lib/systemd/system/named.service; activé; prédéfini du fournisseur: désactivé) Actif: actif (en cours d'exécution) depuis le dim.2017-01-29 10:05:32 EST; Il y a 2min 57s Processus: 1777 ExecStop = / bin / sh -c / usr / sbin / rndc stop> / dev / null 2> & 1 || / bin / kill -TERM $ MAINPID (code = sorti, statut = 0 / SUCCESS) Processus: 1788 ExecStart = / usr / sbin / named -u nommé $ OPTIONS (code = sorti, statut = 0 / SUCCESS) Processus: 1786 ExecStartPre = / bin / bash -c si [! "$ DISABLE_ZONE_CHECKING" == "oui"]; puis / usr / sbin / named-checkconf -z /etc/named.conf; else echo "La vérification des fichiers de zone est désactivée"; fi (code = sorti, statut = 0 / SUCCESS) PID principal: 1791 (nommé) CGroup: /system.slice/named.service └─1791 / usr / sbin / named -u nommé 29 janvier 10:05:32 dns nommé [1791]: zone 1.0.0.127.in-addr.arpa/IN: série chargée 0 29 janvier 10:05:32 DNS nommé [1791]: zone 10.168.192.in-addr.arpa/IN: série chargée le 1er janvier 29 10:05:32 DNS nommé [1791]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN : série chargée 0 29 janvier 10:05:32 dns nommé [1791]: zone desdelinux.fan/IN: série chargée 1 29 janvier 10:05:32 DNS nommé [1791]: zone localhost.localdomain / IN: série chargée 0 29 janvier 10:05:32 DNS nommé [1791]: zone localhost / IN: série chargée 0 29 janvier 10:05:32 DNS nommé [1791]: toutes les zones chargées
29 janvier 10:05:32 DNS nommé [1791]: fonctionnement
29 janvier 10:05:32 dns systemd [1]: Démarrage de Berkeley Internet Name Domain (DNS). 29 janvier 10:05:32 DNS nommé [1791]: zone 10.168.192.in-addr.arpa/IN: envoi de notifications (série 1)

Chèques

Les contrôles peuvent être exécutés sur le même serveur ou sur une machine connectée au LAN. Nous préférons les faire de l'équipe sysadmin.fromlinux.fan auquel nous avons donné une autorisation expresse afin qu'il puisse effectuer des transferts de zone. L'archive / Etc / resolv.conf de cette équipe est la suivante:

buzz @ sysadmin: ~ $ cat /etc/resolv.conf 
# Généré par la recherche NetworkManager à partir du serveur de noms linux.fan 192.168.10.5

buzz @ sysadmin: ~ $ dig depuis linux.fan axfr
; << >> DiG 9.9.5-9 + deb8u1-Debian << >> de linux.fan axfr ;; options globales: + cmd de linux.fan. 10800 IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 1 86400 3600 604800 10800 de linux.fan. 10800 IN NS dns.fromlinux.fan. à partir de linux.fan. 10800 DANS MX 10 mail.fromlinux.fan. à partir de linux.fan. 10800 IN TXT "FromLinux, votre Blog dédié au Logiciel Libre" ad-dc.desdelinux.fan. 10800 DANS UN 192.168.10.3 blog.desdelinux.fan. 10800 DANS UN 192.168.10.7 dns.fromlinux.fan. 10800 DANS UN 192.168.10.5 fileserver.fromlinux.fan. 10800 DANS UN 192.168.10.4 ftpserver.fromlinux.fan. 10800 DANS UN 192.168.10.8 mail.fromlinux.fan. 10800 DANS UN 192.168.10.9 proxyweb.fromlinux.fan. 10800 DANS UN 192.168.10.6 sysadmin.fromlinux.fan. 10800 IN À 192.168.10.1 à partir de linux.fan. 10800 IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 1 86400 3600 604800 10800 ;; Temps de requête: 0 ms ;; SERVEUR: 192.168.10.5 # 53 (192.168.10.5) ;; QUAND: dim 29 janvier 11:44:18 EST 2017 ;; Taille XFR: 13 enregistrements (messages 1, octets 385)

buzz @ sysadmin: ~ $ dig 10.168.192.in-addr.arpa axfr
; << >> DiG 9.9.5-9 + deb8u1-Debian << >> 10.168.192.in-addr.arpa axfr ;; options globales: + cmd 10.168.192.in-addr.arpa. 10800 DANS SOA dns.fromlinux.fan.10.168.192.in-addr.arpa. root.dns.fromlinux.fan.10.168.192.in-addr.arpa. 1 86400 3600 604800 10800 10.168.192.in-addr.arpa. 10800 IN NS dns.fromlinux.fan. 1.10.168.192.in-addr.arpa. 10800 IN PTR sysadmin.fromlinux.fan. 3.10.168.192.in-addr.arpa. 10800 IN PTR ad-dc.fromlinux.fan. 4.10.168.192.in-addr.arpa. 10800 IN PTR fileserver.fromlinux.fan. 5.10.168.192.in-addr.arpa. 10800 IN PTR dns.fromlinux.fan. 6.10.168.192.in-addr.arpa. 10800 DANS PTR proxyweb.fromlinux.fan. 7.10.168.192.in-addr.arpa. 10800 IN PTR blog.desdelinux.fan. 8.10.168.192.in-addr.arpa. 10800 IN PTR ftpserver.fromlinux.fan. 9.10.168.192.in-addr.arpa. 10800 IN PTR mail.fromlinux.fan. 10.168.192.in-addr.arpa. 10800 DANS SOA dns.fromlinux.fan.10.168.192.in-addr.arpa. root.dns.fromlinux.fan.10.168.192.in-addr.arpa. 1 86400 3600 604800 10800 ;; Temps de requête: 0 ms ;; SERVEUR: 192.168.10.5 # 53 (192.168.10.5) ;; QUAND: dim 29 janvier 11:44:57 EST 2017 ;; Taille XFR: 11 enregistrements (messages 1, octets 352)

buzz @ sysadmin: ~ $ dig IN SOA depuis linux.fan
buzz @ sysadmin: ~ $ dig IN MX depuis linux.fan buzz @ sysadmin: ~ $ dig IN TXT depuis linux.fan
buzz @ sysadmin: ~ $ host dns
dns.fromlinux.fan a l'adresse 192.168.10.5
buzz @ sysadmin: ~ $ host sysadmin
sysadmin.desdelinux.fan a l'adresse 192.168.10.1 ... Et toutes les autres vérifications dont nous avons besoin
  • Jusqu'à présent, nous avons la base d'un serveur DNS dans notre réseau de PME. Nous espérons que vous avez apprécié toute la procédure, qui était assez simple, non? 😉

Nous installons et configurons DHCP

[root @ dns ~] # yum installer dhcp
Plugins chargés: plus rapide mirror, langpacks centos-base | 3.4 ko 00:00:00 centos-mises à jour | 3.4 ko 00:00:00 Chargement des vitesses de miroir à partir du fichier hôte mis en cache Résolution des dépendances -> Exécution du test de transaction ---> Le package dhcp.x86_64 12: 4.2.5-42.el7.centos doit être installé -> Résolution des dépendances Dépendances résolues terminées ============================================= ================================================== ==================================== Taille du référentiel de version d'architecture de package =========== ================================================== ================================================== ====================== Installation: dhcp x86_64 12: 4.2.5-42.el7.centos-base 511k Résumé de la transaction ==== ================================================== ================================================== ============================= Installer 1 paquet Taille totale de téléchargement: 511k Taille installée: 1.4 M Est-ce correct [y / d / N]: y Téléchargement des packages: dhcp-4.2.5-42.el7.centos.x86_64.rpm | 511 ko 00:00:00 Exécution du contrôle de transaction Exécution du test de transaction Le test de transaction a réussi Exécution de la transaction Installation: 12: dhcp-4.2.5-42.el7.centos.x86_64 1/1 Vérification: 12: dhcp-4.2.5-42. el7.centos.x86_64 1/1 Installé: dhcp.x86_64 12: 4.2.5-42.el7.centos Terminé!

[root @ dns ~] # nano /etc/dhcp/dhcpd.conf
# # Fichier de configuration du serveur DHCP. # voir /usr/share/doc/dhcp*/dhcpd.conf.example # voir la page de manuel de dhcpd.conf (5) # ddns-update-style interim; ddns-updates on; ddns-domainname "desdelinux.fan."; ddns-rev-domainname "in-addr.arpa."; ignorer les mises à jour du client; faisant autorité; option ip-forwarding désactivé; option nom de domaine "desdelinux.fan"; # option ntp-servers 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org; inclure "/etc/dhcp.key"; zone de linux.fan. {primaire 127.0.0.1; clé dhcp-key; } zone 10.168.192.in-addr.arpa. {primaire 127.0.0.1; clé dhcp-key; } redlocal de réseau partagé {sous-réseau 192.168.10.0 masque de réseau 255.255.255.0 {routeurs d'option 192.168.10.1; option masque de sous-réseau 255.255.255.0; option adresse de diffusion 192.168.10.255; option serveurs de noms de domaine 192.168.10.5; option netbios-name-servers 192.168.10.5; plage 192.168.10.30 192.168.10.250; }} # END dhcpd.conf

[root @ dns ~] # dhcpd -t
Internet Systems Consortium Serveur DHCP 4.2.5 Copyright 2004-2013 Internet Systems Consortium. Tous les droits sont réservés. Pour plus d'informations, veuillez visiter https://www.isc.org/software/dhcp/ Ne pas rechercher LDAP car ldap-server, ldap-port et ldap-base-dn n'ont pas été spécifiés dans le fichier de configuration

[root @ dns ~] # systemctl enable dhcpd
Création d'un lien symbolique depuis /etc/systemd/system/multi-user.target.wants/dhcpd.service vers /usr/lib/systemd/system/dhcpd.service.

[root @ dns ~] # systemctl start dhcpd

[root @ dns ~] # systemctl status dhcpd
● dhcpd.service - Démon serveur DHCPv4 chargé: chargé (/usr/lib/systemd/system/dhcpd.service; activé; prédéfini du fournisseur: désactivé) Actif: actif (en cours d'exécution) depuis dom 2017-01-29 12:04:59 C'EST T; Il y a 23s Docs: man: dhcpd (8) man: dhcpd.conf (5) PID principal: 2381 (dhcpd) Statut: "Dispatching packets ..." CGroup: /system.slice/dhcpd.service └─2381 / usr / sbin / dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid 29 janvier 12:04:59 dns dhcpd [2381]: Internet Systems Consortium DHCP Server 4.2.5 29 janvier 12 : 04: 59 dns dhcpd [2381]: Copyright 2004-2013 Internet Systems Consortium. 29 janvier 12:04:59 dns dhcpd [2381]: Tous droits réservés. 29 janvier 12:04:59 dns dhcpd [2381]: Pour plus d'informations, veuillez visiter https://www.isc.org/software/dhcp/ 29 janvier 12:04:59 dns dhcpd [2381]: Pas de recherche LDAP depuis LDAP -server, ldap-port et ldap-base-dn n'ont pas été spécifiés dans le fichier de configuration 29 janvier 12:04:59 dns dhcpd [2381]: a écrit 0 baux dans le fichier de baux. 29 janvier 12:04:59 dns dhcpd [2381]: écoute sur LPF / eth0 / 52: 54: 00: 12: 17: 04 / redlocal 29 janvier 12:04:59 dns dhcpd [2381]: envoi sur LPF / eth0 / 52: 54: 00: 12: 17: 04 / redlocal 29 janvier 12:04:59 dns dhcpd [2381]: Envoi sur Socket / fallback / fallback-net 29 janvier 12:04:59 dns systemd [1]: Démarré Démon du serveur DHCPv4.

Ce qui reste à faire?

Facile. Démarrez un Windows 7 ou un autre client avec un logiciel gratuit et commencez à tester et à vérifier. Nous l'avons fait avec deux clients: seven.fromlinux.fan y suse-desktop.fromlinux.fan. Les contrôles étaient les suivants:

buzz @ sysadmin: ~ $ hôte sept
seven.fromlinux.fan a l'adresse 192.168.10.30

buzz @ sysadmin: ~ $ host seven.fromlinux.fan
seven.fromlinux.fan a l'adresse 192.168.10.30

buzz @ sysadmin: ~ $ dig IN TXT seven.fromlinux.fan
.... ;; SECTION QUESTION :; seven.fromlinux.fan. IN TXT ;; SECTION RÉPONSE: seven.desdelinux.fan. 3600 EN TXT "31b7228ddd3a3b73be2fda9e09e601f3e9"....

Nous renommons l'équipe "sept" en "LAGER" et redémarrons. Après avoir redémarré le nouveau LAGER, nous vérifions:

buzz @ sysadmin: ~ $ hôte sept
Hôte sept introuvable: 5 (REFUSÉ)

buzz @ sysadmin: ~ $ host seven.fromlinux.fan
Hôte seven.desdelinux.fan introuvable: 3 (NXDOMAIN)

bourdonnement@sysadmin: ~ $ host lager
lager.desdelinux.fan a l'adresse 192.168.10.30

bourdonnement@sysadmin: ~ $ host lager.fromlinux.fan
lager.desdelinux.fan a l'adresse 192.168.10.30

buzz @ sysadmin: ~ $ dig IN TXT lager.fromlinux.fan
.... ;; SECTION QUESTION :; lager.fromlinux.fan. IN TXT ;; SECTION RÉPONSE: lager.fromlinux.fan. 3600 EN TXT "31b7228ddd3a3b73be2fda9e09e601f3e9"....

Concernant le client suse-desktop:

buzz @ sysadmin: ~ $ hôte suse-dektop
Hôte suse-dektop introuvable: 5 (REFUSÉ)

buzz @ sysadmin: ~ $ hôte suse-desktop
suse-desktop.desdelinux.fan a l'adresse 192.168.10.33

buzz @ sysadmin: ~ $ hôte suse-desktop.fromlinux.fan
suse-desktop.desdelinux.fan a l'adresse 192.168.10.33

buzz @ sysadmin: ~ $ hôte 192.168.10.33
33.10.168.192.in-addr.arpa pointeur de nom de domaine suse-desktop.desdelinux.fan.

buzz @ sysadmin: ~ $ hôte 192.168.10.30
30.10.168.192.in-addr.arpa pointeur de nom de domaine LAGER.desdelinux.fan.
buzz @ sysadmin: ~ $ dig -x 192.168.10.33
.... ;; SECTION DES QUESTIONS :; 33.10.168.192.in-addr.arpa. EN PTR ;; SECTION DE RÉPONSE: 33.10.168.192.in-addr.arpa. 3600 DANS PTR suse-desktop.fromlinux.fan. ;; SECTION AUTORITÉ: 10.168.192.in-addr.arpa. 10800 IN NS dns.fromlinux.fan. ;; SECTION SUPPLÉMENTAIRE: dns.fromlinux.fan. 10800 DANS UN 192.168.10.5 ....

buzz @ sysadmin: ~ $ dig IN TXT suse-desktop.fromlinux.fan ....
; suse-desktop.desdelinux.fan. IN TXT ;; SECTION RÉPONSE: suse-desktop.desdelinux.fan. 3600 EN TXT "31b78d287769160c93e6dca472e9b46d73"

;; SECTION AUTORITÉ: desdelinux.fan. 10800 IN NS dns.fromlinux.fan. ;; SECTION SUPPLÉMENTAIRE: dns.fromlinux.fan. 10800 DANS UN 192.168.10.5
....

Exécutons également les commandes suivantes

[root @ dns ~] # creuser à partir de linux.fan axfr
; << >> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 << >> desdelinux.fan axfr ;; options globales: + cmd de linux.fan. 10800 IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 6 86400 3600 604800 10800 de linux.fan. 10800 IN NS dns.fromlinux.fan. à partir de linux.fan. 10800 DANS MX 10 mail.fromlinux.fan. à partir de linux.fan. 10800 IN TXT "FromLinux, votre Blog dédié au Logiciel Libre" ad-dc.desdelinux.fan. 10800 DANS UN 192.168.10.3 blog.desdelinux.fan. 10800 DANS UN 192.168.10.7 dns.fromlinux.fan. 10800 DANS UN 192.168.10.5 fileserver.fromlinux.fan. 10800 DANS UN 192.168.10.4 ftpserver.fromlinux.fan. 10800 DANS UN 192.168.10.8 LAGER.fromlinux.fan. 3600 EN TXT "31b7228ddd3a3b73be2fda9e09e601f3e9"LAGER.fromlinux.fan.   3600 DANS UN 192.168.10.30 mail.fromlinux.fan. 10800 DANS UN 192.168.10.9 proxyweb.fromlinux.fan. 10800 DANS UN 192.168.10.6 suse-desktop.fromlinux.fan. 3600 EN TXT "31b78d287769160c93e6dca472e9b46d73"suse-desktop.desdelinux.fan. 3600 DANS UN 192.168.10.33 sysadmin.fromlinux.fan. 10800 IN À 192.168.10.1 à partir de linux.fan. 10800 IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 6 86400 3600 604800 10800

Dans la sortie ci-dessus, nous avons mis en évidence sur audacieux les TTL -en secondes- pour les ordinateurs avec des adresses IP accordées par le service DHCP ceux qui ont une déclaration explicite du TTL 3600 donnée par le DHCP. Les adresses IP fixes sont guidées par le $ TTL de 3H -3 heures = 10800 secondes- déclaré dans l'enregistrement SOA de chaque fichier de zone.

Ils peuvent vérifier la zone inversée de la même manière.

[root @ dns ~] # dig 10.168.192.in-addr.arpa axfr

D'autres commandes extrêmement intéressantes sont:

[root @ dns ~] # named-journalprint /var/named/dynamic/db.desdelinux.fan.jnl
[root @ dns ~] # named-journalprint /var/named/dynamic/db.10.168.192.in-addr.arpa.jnl
[root @ dns ~] # journalctl -f

Modification manuelle des fichiers de zones

Une fois que DHCP entre en jeu, la mise à jour dynamique des fichiers de zone du nomméSi à tout moment nous avons besoin de modifier manuellement un fichier de zone, nous devons effectuer la procédure suivante, mais pas avant d'en savoir un peu plus sur le fonctionnement de l'utilitaire rdc pour le contrôle du serveur de noms.

[root @ dns ~] # man rndc
....
       freeze [zone [classe [vue]]]
           Suspendre les mises à jour d'une zone dynamique. Si aucune zone n'est spécifiée, toutes les zones sont suspendues. Cela permet d'apporter des modifications manuelles à une zone normalement mise à jour par mise à jour dynamique. Cela entraîne également la synchronisation des modifications du fichier journal dans le fichier maître. Toutes les tentatives de mise à jour dynamique seront refusées tant que la zone est gelée.

       dégel [zone [classe [vue]]]
           Activez les mises à jour d'une zone dynamique figée. Si aucune zone n'est spécifiée, toutes les zones gelées sont activées. Cela oblige le serveur à recharger la zone à partir du disque et à réactiver les mises à jour dynamiques une fois le chargement terminé. Une fois qu'une zone est décongelée, les mises à jour dynamiques ne seront plus refusées. Si la zone a changé et que l'option ixfr-from-differences est utilisée, le fichier journal sera mis à jour pour refléter les changements dans la zone. Sinon, si la zone a changé, tout fichier journal existant sera supprimé. ....

Tu pensais que j'allais transcrire tout le manuel? ... un morceau et ils partent en voiture. Le reste je vous laisse le soin. 😉

Fondamentalement:

  • rndc freeze [zone [classe [vue]]], suspend la mise à jour dynamique d'une zone. Si aucun n'est spécifié, tout gèlera. La commande permet l'édition manuelle de la zone gelée ou de toutes les zones. Toute mise à jour dynamique sera refusée tant qu'elle est gelée.
  • dégel rndc [zone [classe [vue]]], active les mises à jour dynamiques sur une zone précédemment gelée. Le serveur DNS recharge le fichier de zone à partir du disque et les mises à jour dynamiques sont réactivées une fois le rechargement terminé.

Précautions à prendre lorsque nous éditons manuellement un fichier de zone? La même chose que si on le créait, sans oublier d'augmenter le numéro de série de 1 ou en série avant d'enregistrer le fichier avec les modifications finales.

exemple:

[root @ dns ~] # rndc freeze depuis linux.fan

[root @ dns ~] # nano /var/named/dynamic/db.fromlinux.fan
Je modifie le fichier de zone pour quelque raison que ce soit, nécessaire ou non. J'enregistre les modifications

[root @ dns ~] # rndc dégel depuis linux.fan
Un rechargement et un dégel de zone ont été lancés. Consultez les journaux pour voir le résultat.

[root @ dns ~] # journalctl -f
29 janvier 14:06:46 DNS nommé [2257]: zone de dégel 'desdelinux.fan/IN': succès
29 janvier 14:06:46 DNS nommé [2257]: zone de linux.fan/IN: zone serial (6) inchangée. la zone peut ne pas être transférée aux esclaves.
29 janvier 14:06:46 DNS nommé [2257]: zone desdelinux.fan/IN: série 6 chargée

L'erreur dans la sortie précédente, qui apparaît en rouge sur la console, est due au fait que j'ai "oublié" d'augmenter le numéro de série de 1. Si j'avais suivi correctement la procédure, la sortie aurait été:

[root @ dns ~] # journalctl -f
- Les journaux commencent au dim 2017-01-29 08:31:32 EST. - 29 janvier 14:06:46 dns nommé [2257]: zone desdelinux.fan/IN: série chargée 6 29 janvier 14:10:01 dns systemd [1]: Session 43 démarrée de l'utilisateur root. 29 janvier 14:10:01 dns systemd [1]: Démarrage de la session 43 de l'utilisateur root. 29 janvier 14:10:01 dns CROND [2693]: (root) CMD (/ usr / lib64 / sa / sa1 1 1) 29 janvier 14:10:45 dns nommé [2257]: a reçu la commande de canal de contrôle 'freeze de linux. fan '29 janvier 14:10:45 dns nommé [2257]: zone de gel' desdelinux.fan/IN ': succès 29 janvier 14:10:58 dns nommé [2257]: reçu la commande de canal de contrôle' thaw desdelinux.fan 'Jan 29 14:10:58 DNS nommé [2257]: zone de dégel 'desdelinux.fan/IN': succès 29 janvier 14:10:58 DNS nommé [2257]: zone desdelinux.fan/IN: le fichier journal est obsolète: suppression du fichier journal 29 janvier 14:10:58 dns nommé [2257]: zone desdelinux.fan/IN: série 7 chargée
  • Amis lecteurs, je répète que vous devez lire attentivement les sorties des commandes. Pour quelque chose que ses développeurs ont consacré autant de travail à programmer chaque commande, aussi simple soit-elle.

Résumé

Jusqu'à présent, nous avons traité de la mise en œuvre de la paire DNS - DHCP, services importants et cruciaux pour la bonne performance de notre réseau PME, se référant à l'octroi d'adresses dynamiques via DHCP et à la résolution des noms d'ordinateurs et de domaines via DNS.

Nous espérons sincèrement que vous avez apprécié toute la procédure comme nous l'avons fait. Bien qu'il puisse sembler plus difficile d'utiliser la console, il est beaucoup plus facile et plus pédagogique d'implémenter un service sous UNIX® / Linux avec son aide.

Ils me pardonnent toute mauvaise interprétation des concepts pensés, créés, écrits, révisés, réécrits et publiés dans la langue de Shakespeare, et non de Cervantes. 😉

Prochaine livraison

Je pense un peu plus de la même chose - avec des ajouts théoriques sur les enregistrements DNS - mais dans Debian. Nous ne pouvons pas oublier cette distribution, non?


Le contenu de l'article adhère à nos principes de éthique éditoriale. Pour signaler une erreur, cliquez sur c'est par ici !.

15 commentaires, laissez le vôtre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.

  1.   Christian Marchan dit

    Merci beaucoup pour votre travail louable dans la rédaction d'articles aussi fructueux. Cela me sera d'une grande utilité

  2.   federico dit

    Et merci beaucoup, Cristian, de m'avoir suivi et de votre appréciation de ce post. Succès!

  3.   Ismaël Allvarez Wong dit

    Après avoir jeté un premier coup d'œil à ce nouveau billet de Federico, le grand professionnalisme qui a été observé tout au long de la série «PYMES» est à nouveau perceptible; en plus du grand détail qui illustre votre domaine sur deux des services les plus importants (DNS et DHCP) de tout réseau. A cette occasion et contrairement à mes précédents commentaires, j'ai un 2ème commentaire en attente après avoir mis en pratique ce que j'ai déclaré dans ce post.

  4.   crespo88 dit

    Pas de commentaires, pa '400 !!! Merci Fico car tu sais très bien que j'ai lu tes posts et on ne peut pas en demander plus. Vous commencez avec une très bonne organisation, de la façon d'installer et de paramétrer le bureau personnel d'un utilisateur, le poste de travail est la base, c'est le sentiment d'être de ces services réseau que vous expliquez très bien. Vous avez grimpé et s'il est vrai que le niveau augmente, il est vrai que vous avez écrit et publié pour ceux qui sont inférieurs à ceux qui commencent, pour ceux qui sont comme moi depuis un certain temps et pour les plus avancés.
    Au fil du temps, j'en suis venu à la conclusion que je sais que beaucoup sont déjà arrivés, la théorie, ce qui nous coûte tant à acquérir pour le simple fait de ne pas vouloir lire, car l'exécution est déjà beaucoup plus facile quand on sait ce qu'on fait, pourquoi ???, les questions, où trouver et comment sortir de l'erreur qui donne tant de maux de tête quand on ne sait même pas d'où elles viennent, ça vaut la redondance.
    Pour cette raison, je ne veux pas que vous laissiez derrière vous ces éléments théoriques que vous inclurerez à propos des enregistrements DNS dans la prochaine publication comme vous l'avez annoncé, encore moins lorsqu'il s'agit du cher et bien-aimé DEBIAN.
    MERCI BEAUCOUP et nous attendons.

  5.   chasseur dit

    Excellent comme toujours Fico! J'attends la version Debian, je joue à tout avec cette distribution depuis des années.

  6.   federico dit

    Wong: Votre opinion après lecture vaut beaucoup. J'attends vos commentaires lorsque vous testez le contenu, car je sais que c'est ainsi que vous aimez le faire. 😉

  7.   federico dit

    Crespo: Comme toujours, vos commentaires sont très bien reçus. Je vois que vous avez capturé la ligne générale que j'ai soulevée dans la composition de cette série. J'espère que, comme vous, beaucoup l'ont déjà remarqué. Merci pour ton commentaire.

  8.   federico dit

    Dhunter: Ravi de vous lire à nouveau! Vous n'aurez pas à attendre longtemps. Lundi au plus tard -ou avant- il sera terminé pour publication. Ne pensez pas qu'il est facile pour moi de couvrir trois distributions différentes, mais le lecteur respectable le demande. Non seulement Debian et Ubuntu, mais les Trois Orientés vers les PME.

  9.   crespo88 dit

    Si vous avez publié, c'est parce que vous le pouvez, nous vous soutenons et nous savons que vous suivrez cette ligne.
    En tant que chasseur, j'attends la sortie de Debian avec des dents acérées. Ce serait bien si vous parliez un peu de NTP. Sl2 et un gros câlin. Si mes professeurs m'avaient tout appris comme ça, HAHAJJA, Platinum Degree, HAHAJJA.

  10.   federico dit

    Le niveau de détail des sorties de commande est nécessaire pour montrer son importance. Ils en disent beaucoup. Il est vrai que peu d'articles abordent ce niveau de détail, car ils pensent que ce seraient des articles longs et lourds à lire. Eh bien, une partie du travail d'un SysAdmin est de lire ces sorties lourdes et détaillées, non seulement face à un problème, mais aussi face à des vérifications.

  11.   Ismaël Allvarez Wong dit

    Bonjour Federico, j'avais promis auparavant, d'écrire quelques commentaires après avoir étudié attentivement le poste en question; Eh bien, les voici ensuite:
    - Excellente technique au lieu de générer la clé TSIG pour les mises à jour DNS dynamiques par DHCP, en copiant la même clé rndc.key que dhcp.key, cela en apparence "si simple" montre que l'objectif n'est pas seulement la technicité du HOWTO-INSTALL-DNS - & - DHCP mais nous apprenant à réfléchir, 5 ÉTOILES POUR L'AUTEUR.
    - Très intéressant dans le fichier de configuration DNS, named.conf, la présence de la ligne «allow-transfer {localhost; 192.168.10.1; }; » pour tester le domaine «desdelinux.fan» uniquement à partir du poste de travail SysAdmin et du localhost (le serveur DNS lui-même), et également insérer la clé TSIG pour mettre à jour le DNS depuis DHCP.
    - Très bien la création des zones directes et inverses du DNS ainsi que l'explication "détaillée" de leurs types d'enregistrements, ainsi que l'exécution de la commande "# named-checkconf -zp" pour vérifier toute la syntaxe du named avant son réinitialisation matérielle, ainsi que des exemples d'exécution de la commande "dig" pour vérifier différents types d'enregistrements DNS.
    . Dans la configuration DHCP (en utilisant le fichier /etc/dhcp/dhcpd.conf):
    - Comment ajouter notre réseau local avec sa plage d'adresses IP dynamiques à attribuer, la définition du serveur de noms, etc. ainsi que comment dire à DHCP de mettre à jour les enregistrements DNS en utilisant les lignes "ddns- ..." dans sa configuration.
    . Quand tout est déjà opérationnel, 5 ÉTOILES POUR L'AUTEUR, dans l'exécution de la commande "# dig desdelinux.fan axfr" pour vérifier le TTL des ordinateurs sur le LAN qui ont une IP statique de ceux qui ont une IP dynamique attribuée.
    . Enfin, GREAT, la modification manuelle des fichiers Zones en les gelant d'abord avec "# rndc freeze desdelinux.fan", puis en faisant la modification et enfin en les débloquant avec "# rndc thaw desdelinux.fan"
    . ET LE MEILLEUR, TOUT A ÉTÉ FAIT À PARTIR DU TERMINAL.
    Continuez comme ça Fico.

    1.    Joie dit

      Bonjour,
      Ik kom net kijken, dit omdat ik sondeer te achterhalen hoe het kan dat alles gedeeld en verwijderd wordt op mijn computer zelfs mijn foto's. Ik heb totaal geen control meer sur mijn eigen computer sur mobiel.
      Het zit m dus ook in het dns in dhcp. Ik weet echt niet hoe ik dit moet oplossen en het kan verwijderen. Misschien dat iemand mij wilt helpen? Dit est namelijk buiten mij om geinstalleerd. Walgelijk gedrag vind ik het.

  12.   federico dit

    Wong: votre commentaire complète l'article. Sérieusement, cela montre que vous l'avez étudié à fond. Sinon, vous ne pourriez pas commenter avec le niveau de détail que vous faites. Ajoutez juste ça autoriser le transfert Il est principalement utilisé lorsque nous avons un esclave DNS et que nous autorisons le transfert de zones du maître vers celui-ci. Je l'utilise de cette façon car c'est un mécanisme facile à mettre en œuvre pour effectuer des contrôles non dangereux à partir d'un seul ordinateur. Merci beaucoup pour votre évaluation de 5. Salutations! et je continuerai à vous attendre dans mes prochains articles.

  13.   IgnacioM dit

    Bonjour Federico. Je sais que je suis un peu en retard, mais j'aimerais vous poser une question.
    Cette procédure m'aiderait-elle si je souhaite pointer un domaine vers mon serveur vps?

    Toutes les 15 minutes, je reçois ces messages système:

    DHCPREQUEST sur eth0 vers le port 67 (xid =…)
    DHCPACK de (xid =…)
    lié à - renouvellement dans 970 secondes.

    Et d'après ce que j'ai compris, je devrais créer un enregistrement A avec mon domaine et l'adresse IP de mon serveur dédié.

    * Je félicite et merci pour cet article, je ne sais pas si c'est ce que je cherchais mais je l'ai trouvé très intéressant et bien expliqué. En plus je prends la recommandation de "DNS and BIND" que j'ai déjà un peu bavardé et cela me semble très intéressant.

    Salutations depuis l'Argentine!

    1.    antonio valdès toujague dit

      veuillez me contacter via valdestoujague@yandex.com

bool (vrai)