# Configuration DNS Debian 10

**URL:** <https://www.debian-fr.org/t/configuration-dns-debian-10/84895>\
**Category:** Trucs et Astuces\
**Created:** [Juin 30, 2021, 3:05 UTC](https://www.debian-fr.org/t/configuration-dns-debian-10/84895 "2021-06-30T15:05:34Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![philippe2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/7feea3/32.png) [@philippe2](https://www.debian-fr.org/u/philippe2)\
**Post date:** [Juin 30, 2021, 3:05 UTC](https://www.debian-fr.org/t/configuration-dns-debian-10/84895/1 "2021-06-30T15:05:34Z")

</div>

# 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](https://www.debian-fr.org/uploads/default/original/2X/2/2915eeb1cf2c1ea0f13166d50e10b45304d95057.png)  
**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 ‹&nbsp;Ping&nbsp;› 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 ‹&nbsp;Ping&nbsp;› 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.**

> **[fr/Bind9 - Debian Wiki](https://wiki.debian.org/fr/Bind9)**

**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/syslo** g_

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**

[https://fr.wikipedia.org/wiki/Domain\_Name\_System#NS\_record](https://fr.wikipedia.org/wiki/Domain_Name_System#NS_record)

**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=«&nbsp;-4&nbsp;»

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

---

<div class="post-metadata">

**Author:** ![anon90668717](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/3e96dc/32.png) [@anon90668717](https://www.debian-fr.org/u/anon90668717)\
**Post date:** [Juin 30, 2021, 4:10 UTC](https://www.debian-fr.org/t/configuration-dns-debian-10/84895/2 "2021-06-30T16:10:49Z")

</div>

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

erratum: je viens de m’apercevoir que c’etait ds «&nbsp;trucs et astuces&nbsp;»…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

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Juillet 1, 2021, 8:32 UTC](https://www.debian-fr.org/t/configuration-dns-debian-10/84895/3 "2021-07-01T20:32:22Z")

</div>

> [@philippe2](#):
>
> 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)

Pourquoi en bridge? ce n’est pas utile.

> [@philippe2](#):
>
> 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** _

Le ifdown/ifup est normallement suffisant.

> [@philippe2](#):
>
> **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** _

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.

> [@philippe2](#):
>
> 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.

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

> [@philippe2](#):
>
> 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.

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.

> [@philippe2](#):
>
> _ **greta@srv-debian:~$ sudo reboot** _
> 
> Et enfin vérifier que le contenu du fichier ip\_forward

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

> [@philippe2](#):
>
> 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 :

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

> [@philippe2](#):
>
> Le routage est maintenant autorisé par MASQUERADE

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…

> [@philippe2](#):
>
> On choisit comme zone directe tssr que l’on va faire suivre de .lan ce qui va nous donner : tssr.lan

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.

> [@philippe2](#):
>
> allow-update { none; } : pas de mise à jour vers d’autres serveurs.

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.

> [@philippe2](#):
>
> 600 ;retry en seconde 10m

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

> [@philippe2](#):
>
> _nameserver 127.0.0.53_
> 
> _nameserver 172.16.0.1_
> 
> _search tssr.lan_

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

> [@philippe2](#):
>
> COMME CETTE CONFIGURATION S’EFFACE A CHAQUE REDEMARRAGE ON VA PREFERER MODIFIER LE FICHIER RESOLVED.CONF

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.

> [@philippe2](#):
>
> Pour effectuer les tests il faut se mettre dans le dossier /var/cache/bind

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

> [@philippe2](#):
>
> forwarders {
> 
> 8.8.8.8;
> 
> 8.8.4.4;
> 
> };

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.