Configuration DNS Debian 10

Comment configurer un serveur DNS sur Debian 10

Prérequis : Mettre son serveur Debian à jour, nommer son serveur en fonction du cahier des charges, et pour finir avoir un second PC sous Windows.

Utiliser pour cette configuration et faire les tests le logiciel de virtualisation VMWare Workstation.

1 - Cahier des charges du serveur

configuration locale :

nom du serveur : srv-debian

nom complet serveur : srv-debian.tssr.lan

nom de domaine local : tssr.lan

adresse ip du serveur : 172.16.0.1

masque sous réseau : 255.255.255.0

plage DHCP : 172.16.0.2 à 172.16.0.100

utilisateur : greta

mot de passe : Raimu300

en tête nom clients : poste1,poste2

configuration FAI:

adresse ip de la passerelle par défaut : 192.168.0.254

Masque de sous-réseau : 255.255.255.0

adresse du serveur DNS 1 chez le FAI : 1.0.0.1

adresse du serveur DNS 2 chez le FAI : 1.1.1.1

adresse du serveur DNS 3 chez le FAI : 192.168.0.254

2 – Schéma du réseau virtuel
image
3 Interfaces réseaux

Dans notre cas nous avons deux cartes réseaux sur notre PC avec la carte ens33 branchée sur le réseau du routeur de la Freebox pour l’accès à Internet et la deuxième carte réseau ens34 branchée sur notre réseau local (voir le schéma ci-dessus).

3.1 Configuration des interfaces réseaux

La configuration des cartes réseaux se trouve dans le fichier suivant : /etc/network/interfaces

Edition du fichier de configuration

greta@srv-debian:~$ sudo nano /etc/network/interfaces

La carte réseau ens33 est configurée en bridge dans ma la machine virtuelle. Son adresse IP appartient au réseau de la Freebox (voir le cahier des charges)

La carte réseau ens34 est configurée en Lan dans ma machine virtuelle. C’est l’adresse du serveur Debian (voir le schéma joint).

Après avoir changé ces valeurs, il faut appliquer la configuration :

· Arrêter les 2 cartes

greta@srv-debian:~$ sudo ifdown ens33

greta@srv-debian:~$ sudo ifdown ens34 (elle est déja arrêtée,car elle n’a pas une adresse ip valide)

· Les réactiver

greta@srv-debian:~$ sudo ifup ens33

greta@srv-debian:~$ sudo ifup ens34

· Puis relancer les services réseaux :

greta@srv-linux:~$ sudo systemctl restart systemd-networkd

· Vérifier les adresses des cartes réseaux.


greta@srv-debian:~$ ip a


3.2 Test des cartes

Test vers la première carte ens34. REUSSITE

Test avec l’outil ping sur le serveur

greta@srv-debian:~$ ping -c4 172.16.0.1

PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.

64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=0.032 ms

64 bytes from 172.16.0.1: icmp_seq=2 ttl=64 time=0.094 ms

64 bytes from 172.16.0.1: icmp_seq=3 ttl=64 time=0.094 ms

64 bytes from 172.16.0.1: icmp_seq=4 ttl=64 time=0.097 ms

Test à partir d’un client sous Windows 10 (il faut mettre le poste client sur le même réseau que l’interface ens34).

Ouvrir un terminal sous Windows 10 et saisir la commande ping

C:\Windows\system32>ping 172.16.0.1

Envoi d’une requête ‹ Ping › 172.16.0.1 avec 32 octets de données :

Réponse de 172.16.0.1 : octets=32 temps<1ms TTL=64

Réponse de 172.16.0.1 : octets=32 temps=1 ms TTL=64

  • Élément

Réponse de 172.16.0.1 : octets=32 temps<1ms TTL=64

Réponse de 172.16.0.1 : octets=32 temps<1ms TTL=64

Statistiques Ping pour 172.16.0.1:

  • Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),*

Durée approximative des boucles en millisecondes :

  • Minimum = 0ms, Maximum = 1ms, Moyenne = 0ms*

Test vers la deuxième carte ens33

Test ping à partir de srv-debian vers DNS de google : REUSSITE

Test ping vers DNS google à partir du client Windows : ECHEC

Cet échec vient du fait que le routage entre les deux cartes du serveur n’est pas autorisé ainsi que le routage nat dans le serveur.

En effet sur un poste Debian la fonctionnalité de « routage » est préinstallée d’origine dans le système, c’est donc à nous de la configurer.

Par défaut le routage entre les deux cartes réseaux est désactivé.

Vérification :

greta@srv-debian:~$ cat /proc/sys/net/ipv4/ip_forward

0

Le 0 dans ce fichier de configuration indique que le routage est interdit

3.3 Routage

Pour l’activer il suffit de modifier le fichier de configuration (/etc/sysctl.conf ).

On profitera pour désactiver IPV6, pour ne pas avoir des problèmes lors de la configuration du DHCP, ainsi que lors de la synchronisation des horloges des PC (services NTP). Ce service est nécessaire pour la création du domaine avec samba DC.

3.3.1 – Activer l’IP-Forwarding:

Entrer dans le fichier de configuration de sysctl :

greta@srv-debian:~$ sudo nano /etc/sysctl.conf

il faut décommenter la ligne suivante

#net.ipv4.ip_forward=1

et rajouter les lignes suivantes pour désactiver l’IPv6.

net.ipv6.conf.all.disable_ipv6 = 1

net.ipv6.conf.default.disable_ipv6 = 1

greta@srv-debian:~$ sudo reboot

Et enfin vérifier que le contenu du fichier ip_forward

greta@srv-debian:~$ cat /proc/sys/net/ipv4/ip_forward

1

3.3.2– Faire la règle de routage :

Cette commande sert à activer le NAT en sortie sur ens33 (interface du côté d’internet):

greta@srv-debian:~$ sudo iptables -t nat -A POSTROUTING -o ens33 -j MASQUERADE

3.3.3 – Rendre la configuration persistante :

Le paquet iptables-persistent est là pour simplifier la tâche :

greta@srv-debian:~$ sudo apt install iptables-persistent

sudo apt install iptables-persistent

Il suffit d’enregistrer les règles IPv4 dynamique :

Remarque : Il est possible de modifier les règles de routage si nécessaire, pour cela il faut ré-effectuer une configuration de iptables-persistent :

greta@srv-debian:~$ sudo dpkg-reconfigure iptables-persistent

Vérification des règles du pare feu :

greta@srv-debian:~$ sudo iptables -L -t nat

Le routage est maintenant autorisé par MASQUERADE et ainsi les adresses privées utilisent toutes la même adresse publique, ici celle de ens33.

Vérification sur le client par un ping.

Envoi d’une requête ‹ Ping › 8.8.8.8 avec 32 octets de données :

Réponse de 8.8.8.8 : octets=32 temps=15 ms TTL=118

Réponse de 8.8.8.8 : octets=32 temps=16 ms TTL=118

Réponse de 8.8.8.8 : octets=32 temps=16 ms TTL=118

Réponse de 8.8.8.8 : octets=32 temps=15 ms TTL=118

Statistiques Ping pour 8.8.8.8:

  • Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),*

Durée approximative des boucles en millisecondes :

  • Minimum = 15ms, Maximum = 16ms, Moyenne = 15ms*

4-Serveur Dns

4.1-Ressources.

4.2 Configuration et installation du DNS

Pour configurer le serveur DNS,il vaut mieux ouvrir deux consoles terminales. La deuxième console servira pour la lectures des logs du systeme(syslog)

tail -f /var/log/syslog

greta@srv-debian:~$ sudo tail -f /var/log/syslog

On va utiliser le paquet bind9 pour installer le DNS

greta@srv-debian:~$ sudo apt-get install -y bind9 bind9utils bind9-doc dnsutils

Répondez oui en tapant Y pour installer les logiciels.

4.3 Fichiers de configurations.

Il y a quatre fichiers de configurations :

/etc/bind/named.conf : fichier général

/etc/bind/named.conf.options : fichier contenant les options de Bind

/etc/bind/named.conf.local : fichier contenant nos zones

/etc/bind/named.conf.default-zones : fichier contenant les zones par défaut forward reverse et broadcast

Il est conseillé de sauvegarder les fichiers de configuration initiaux au cas où il y aurait une mauvaise manipulation.

greta@srv-debian:~$ sudo cp /etc/bind/named.conf /etc/bind/named.conf.back

greta@srv-debian:~$ sudo cp /etc/bind/named.conf.options /etc/bind/named.conf.options.back

greta@srv-debian:~$ sudo cp /etc/bind/named.conf.local /etc/bind/named.conf.local.back

greta@srv-debian:~$ sudo cp /etc/bind/named.conf.default-zones /etc/bind/named.conf.default-zones.back

4.4 Création serveur DNS sans mise à jour dynamique

Il faut configurer le fichier "/etc/bind/named.conf.local et le remplir avec notre cahier des charges

On choisit comme zone directe tssr que l’on va faire suivre de .lan ce qui va nous donner : tssr.lan

La zone inverse (si notre adresse IP est 172.16.0.1 / 24) est donc : 0.16.172.in-addr.arpa

greta@srv-debian:~$ sudo nano /etc/bind/named.conf.local

master : signifie que cette zone est maitre

db.greta.lan : fichier qui contient les noms d’ordinateurs vers les adresses IP.

allow-update { none; } : pas de mise à jour vers d’autres serveurs.

rev.greta.lan : fichier qui contient les adresses IP vers les noms d’ordinateurs.

4.5. Création du fichier « db.tssr.lan »

Ce fichier contient les noms d’ordinateurs vers les adresses IP, il se situe dans le répertoire /var/cache/bind.

greta@srv-debian:~$ cd /var/cache/bind/

greta@srv-debian:/var/cache/bind$ sudo nano db.tssr.lan

4.6. Création du fichier « rev.tssr.lan »

Ce fichier contient les adresses IP vers les noms d’ordinateurs, il se situe dans le répertoire /var/cache/bind.

greta@srv-debian:~$ cd /var/cache/bind/

greta@srv-debian:/var/cache/bind$ sudo nano rev.tssr.lan

$TTL 86400

@ IN SOA srv-debian.tssr.lan. root.tssr.lan. (

2020111101 ;serial

3600 ;refresh en seconde 1h

600 ;retry en seconde 10m

86400 ;expire 1jour

600) ; ttl 1h

@ IN NS srv-debian.tssr.lan.

1 IN PTR srv-debian.tssr.lan.

2 IN PTR client.tssr.lan.

Quand on installe un paquetage système, il crée un utilisateur dans notre cas il s’appelle bind. Il faut autoriser cet utilisateur à lire les fichiers que l’on vient de créer.

greta@srv-debian:/var/cache/bind$ls -la

greta@srv-debian:/var/cache/bind$ sudo chgrp bind /var/cache/bind/

verification :

greta@srv-debian:/var/cache/bind$ls -la

4.7.Signification

4.8. Modification du fichier « /etc/hosts »

Modification de /etc/hosts contenant la résolution de la zone locale et la propre résolution de la machine dans le domaine.

greta@srv-debian:~$ sudo nano /etc/hosts

Voici le contenu de ce fichier.

127.0.0.1 localhost

127.0.1.1 srv-debian

# The following lines are desirable for IPv6 capable hosts

::1 ip6-localhost ip6-loopback

ff02::1 ip6-allnodes

ff02::2 ip6-allrouter

Modifier en

127.0.0.1 srv-debian

172.16.0.1 srv-debian.tssr.lan srv-debian

Il faut maintenant, redémarrer le serveur.

greta@srv-debian:~$ sudo reboot

4.9 Modifications du fichier « /etc/resolv.conf »

Il faut aussi modifier le fichier /etc/resolv.conf qui indique le domaine à rechercher ici tssr.lan ainsi que le serveur DNS.

greta@srv-debian:~$ sudo nano /etc/resolv.conf

nameserver 127.0.0.53

search localdomain

Effacer la ligne search localdomain et rajouter en premier notre serveur

nameserver 127.0.0.53

nameserver 172.16.0.1

search tssr.lan

On peut rajouter d’autres serveurs si dans notre réseau c’est nécessaire.

COMME CETTE CONFIGURATION S’EFFACE A CHAQUE REDEMARRAGE ON VA PREFERER MODIFIER LE FICHIER RESOLVED.CONF

greta@srv-debian:/ sudo nano /etc/systemd/resolved.conf

Et modifier dans ce fichier :

[Resolve]

DNS=172.16.0.1

Domains=tssr.lan

Il faut créer un raccourci de /run/systemd/resolve/resolv.conf vers /etc/resolv.conf

greta@srv-debian:~$ sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

*** Redémarrer votre PC:***

greta@srv-debian:~$sudo reboot

Puis vérifier votre fichier resolv.conf qu’il soit conforme aux valeurs suivantes :

greta@srv-debian:~$cat /etc/resolv.conf

5. Test de nos zones

Il existe plusieurs outils pour tester les zones DNS :

Named checkzone

Dig qui interroge le serveur

Nslookup de même.

Named checkzone

Pour effectuer les tests il faut se mettre dans le dossier /var/cache/bind

greta@srv-debian:~$ cd /var/cache/bind/

greta@srv-debian:/var/cache/bind$ sudo named-checkzone -d tssr.lan db.tssr.lan

greta@srv-debian:/var/cache/bind$ sudo named-checkzone -d 0.16.172.in-addr.arpa rev.tssr.lan

6.Test du serveur dns .

6.1 Test de la zone directe

greta@srv-debian:/var/cache/bind$ nslookup srv-debian.tssr.lan

greta@srv-debian:/var/cache/bind$ nslookup client.tssr.lan

greta@srv-debian:/var/cache/bind$ nslookup client.tssr.lan

Server: 172.16.0.1

Address: 172.16.0.1#53

Name: client.tssr.lan

Address: 172.16.0.2

6.2 Test de la zone inversee .

greta@srv-debian:/var/cache/bind$ nslookup 172.16.0.1

greta@srv-debian:/var/cache/bind$ nslookup 172.16.0.1

1.0.16.172.in-addr.arpa name = srv-debian.tssr.lan.

greta@srv-debian:/var/cache/bind$ nslookup 172.16.0.2

greta@srv-debian:/var/cache/bind$ nslookup 172.16.0.2

2.0.16.172.in-addr.arpa name = client.tssr.lan.

Test d’interrogation du DNS extérieur

greta@srv-debian:~$ dig srv-debian.tssr.lan

7 Forcer ipv4 et forwarders

Editer le fichier named.conf.options

Pour les redirecteurs s’appuyer sur un DNS extérieur, celui de google.

greta@srv-debian:~$ sudo nano /etc/bind/named.conf.options

Décommenter les lignes suivantes :

// forwarders {

// 0.0.0.0;

// };

Et modifier comme suit

forwarders {

8.8.8.8;

8.8.4.4;

};

Forcer named à fonctionner en ipv4

greta@srv-linux:$sudo nano /etc/default/named

Rajouter à la fin du fichier.

OPTIONS="-4"

greta@srv-debian:~$ sudo nano /etc/default/bind9

Tu as carrément fait un copier-coller de ton sujet? Sérieux …

erratum: je viens de m’apercevoir que c’etait ds « trucs et astuces »…ton tuto est pourri et mal rédigé et surtout sent le narcissisme a plein nez

ps: je prie la modé de m’excuser pour le signalement

Pourquoi en bridge? ce n’est pas utile.

Le ifdown/ifup est normallement suffisant.

Coté rédaction je ne comprends pas, test ens34 réussit, la suite explique le test?
ceci dit, tester le ping à partir du serveur de l’interface si le ip a t’as donné le bon resultat, c’est un test inutile.
Après dans une doc, pas besoin de mettre les résultats des tests, juste de dire comment les faire.

Il faut juste activer le forward entre les deux interface, mais vu que ens33 est en bridge ça ne va pas être propre.

On ne voit pas trop ce que viens faire le DC dans l’histoire. et qui plus est l’activation de l’IPV6 n’a aucun impact sur la configuration DHCP ni le service NTP.

Inutile, un sysctl -p devrait suffire il me semble.

Inutile dans le cadre de la configuration actuelle. Le système va s’en occuper tout seul.

Pourquoi le NAT? ce n’est pas expliqué. La box Free n’est pas capable de router vers les machines PC windows, d’où le NAT dans le srv-debian, afin d’être sur du retour des requêtes issues du réseau 172.16…

Charabia, désolé.
Un somaine se doit pour être dans les règles de l’art d’être déterminé sous la forme domain.tld. Ici tu as choisit un tls non officiel, mais ça reste local donc pas de soucis.
mais si tu dispose d’un domaine public, il aurait été plus pertinent de faire un sous domaine du domaine public. C’est plus propre.

NOn inexact. Cette directive empeche qu’on puisse mettre le serveur à jour (soit par le client, soit par l’utilisation de nsupdate ou autre mécanisme du même type).
Pour empecher la mise à jour vers d’autres serveurs, on appelle ca un transfert, et c’est la directive allow-transfert.

C’est un peu court, tu va faire augmenter certaines requetes. 1h est largement suffisant, inutile d’aller plus bas.

Normallement la ligne search, ou la ligne domain est en premier.

Non il n’y a normalement pas de raison, sauf si on a installé le package resolvedconf, auquel cas, il faut utiliser la configuration correspondante à l’utilisation du paquet.

Inutile à partir du moment ou le chemin d’accès sera spécifié.

Mieux vaut utiliser les serveurs de opendns, plutot que Google qui fait une trace des requetes à des fins d’exploitation.

Voilà, c’était une lecture vite fait.