Différences

Ci-dessous, les différences entre deux révisions de la page.

--- reseau:dns:dnspresentation [2022/10/13 22:59]
techer.charles_educ-valadon-limoges.fr [Les tests]
+++ reseau:dns:dnspresentation [2023/10/04 22:03] (Version actuelle)
techer.charles_educ-valadon-limoges.fr [Retour Bloc 2]
@@ Ligne 2: / Ligne 2: @@
 ===== Le protocole de résolution de noms de domaine DNS =====
-La communication sur un réseau local ou sur Internet nécessite d'utiliser des adresses IP pour pouyvoir communiquer. Il est cependant plus facile d'utiser des noms que des adresses IP.
+La communication sur un réseau local ou sur Internet nécessite d'utiliser des adresses IP pour pouvoir communiquer. Il est cependant plus facile d'utiliser des noms que des adresses IP.
 Le système **DNS  (Domain Name System)** permet :
@@ Ligne 14: / Ligne 14: @@
   * Le terme employé pour déterminer l'adresse IP assodiée à un nom DNS FQDN en adresse IP est celui de **résolution inverse** de l'adresse IP.
-Le système DNS est un modèle en arborescence hiérarchique avec une gestion décentralisée des données (chacun étant responsable des données de sa zone).
+===== Arborescence DNS =====
+Le système DNS est un modèle en **arborescence hiérarchique** avec une gestion décentralisée des données (chacun étant responsable des données de sa zone).
+{{ :reseau:dns:dns_01.png |}}
 Le système de noms DNS se présente sous forme d'un arbre inversé avec
@@ Ligne 31: / Ligne 35: @@
 Chaque information élémentaire de la base de données DNS est un objet appelé **resource record** (RR). Un nœud peut contenir aussi bien des domaines que des noms de machines.
-===== Arborescence DNS =====
-{{ :reseau:dns:dns_01.png |}}
+===== Les deux types de serveurs DNS =====
 Il y a deux grands types de serveur DNS :
   * Le **serveur DNS récursif** appelé aussi **résolveur** qui dispose uniquement d’un cache et de l’adresses des serveurs racines :
-    * Il est sollicité par des hôtes afin de répondre à leurs requêtes.
+    * Il est **sollicité par des hôtes** afin de répondre à leurs requêtes.
     * Si la réponse n’est pas dans son cache, il sollicitera l’ensemble des serveurs faisant autorité concernés en partant d’un **serveur racine**,
-    * le service utilisé est le service **Unbound**.
+    * le service utilisé avec l'OS Debian est le service **Unbound**.
-   * Le **serveur DNS faisant autorité** gère une ou plusieurs zones et les enregistrements associés. Les serveurs racines ou gérant les TLD sont des serveurs faisant autorité.
+  * Le **serveur DNS faisant autorité** gère une ou plusieurs zones et les enregistrements associés. Les serveurs racines ou gérant les TLD sont des serveurs faisant autorité.
+    * le service utilisé avec l'OS Debian est le service **bind9**
+L'ordinateur client dispose dans sa configuration réseau **d’un ou plusieurs serveurs DNS récursifs** déclarés sous la forme d’adresses IP (dans **/etc/resolv.conf** sous Debian GNU/Linux). Lorsque ce dernier souhaitera résoudre un nom de domaine (pour se connecter à un site web par exemple), il contactera le **serveur DNS récursif** défini précédemment afin d’obtenir une réponse.
+===== Fonctionnement global de la résolution DNS pour le contexte CUB=====
-L'ordinateur client dispose dans sa configuration réseau **d’un ou plusieurs serveurs DNS récursifs** déclarés sous la forme d’adresses IP (dans /etc/resolv.conf sous Debian GNU/Linux). Lorsque ce dernier souhaitera résoudre un nom de domaine (pour se connecter à un site web par exemple), il contactera le **serveur DNS récursif** défini précédemment afin d’obtenir une réponse.
 {{ :reseau:dns:dns_02.png |}}
+  - Le client du LAN souhaite obtenir l’adresse IP correspondant au nom de domaine FQDN www.undomaine.fr (www.undomaine.fr. IN A?). Pour cela, il sollicite le serveur DNS récursif défini dans ses paramètres réseaux.
+  - Le serveur récursif vérifie s’il a déjà la réponse dans son cache, ce qui n’est pas le cas. Il décide donc de solliciter le serveur racine le plus proche. Le serveur racine lui indique qu’il ne dispose pas de l’information recherchée mais qu’il connaît les serveurs faisant autorité sur le TLD .fr.
+  - Le serveur récursif sollicite maintenant l’un des serveurs faisant autorité sur le TLD .fr. Ce dernier lui indique qu’il n’a pas l’information recherchée mais qu’il connaît le ou les serveurs faisant autorité sur le sous-domaine undomaine.fr.
+  - Le serveur récursif contacte ensuite le serveur faisant autorité sur le domaine undomaine.fr. Ce dernier dispose de l’information recherchée dans son fichier de zone sous la forme d’un enregistrement. Il l’a fourni au serveur récursif.
+  - Ce dernier stocke l’information dans son cache et la transmet enfin au client.
+===== Fonctionnement de la résolution DNS pour le domaine cub.fr =====
+{{ :reseau:dns:dns_03.png |}}
+  - Le client souhaite obtenir l’adresse IP correspondant au nom de domaine FQDN dc0.lan.galeway.cub.fr (dc0.lan.galeway.cub.fr. IN A?) auprès du serveur récursif défini dans ses paramètres réseaux.
+  - Le serveur récursif vérifie s’il a déjà la réponse dans son cache, ce qui n’est pas le cas. Il décide donc de solliciter le serveur faisant autorité sur le domaine cub.fr. Attention ! Ce fonctionnement n’est pas le fonctionnement normal d’un serveur récursif qui commencera par contacter l’un des serveurs racines en premier lieu. Dans le cas présent, le domaine cub.fr étant un domaine fictif, nous avons paramétré le serveur récursif pour qu’il sollicite directement le serveur faisant autorité sur ce domaine via les directives « private-zone » et « stub-zone ».
+  - Le serveur faisant autorité sur le domaine cub.fr répond au serveur récursif qu’il ne détient pas l’information souhaitée mais qu’il connaît (grâce à la délégation de zone) les serveurs faisant autorité sur galeway.cub.fr.
+  - Le serveur récursif interroge donc l’un des serveurs faisant autorité sur galeway.cub.fr situé dans la DMZ de l’agence.
+  - Le serveur faisant autorité sur galeway.cub.fr répond au serveur récursif qu’il ne détient pas l’information mais qu’il connaît le ou les serveurs faisant autorité sur le sous-domaine lan.galeway.cub.fr .
+  - Le serveur récursif interroge ensuite le serveur DNS faisant autorité sur lan.galeway.cub.fr.
+  - Ce dernier dispose de l’enregistrement (RR) recherché et fournit la réponse au serveur récursif.
+  - Le serveur récursif stocke la réponse dans son cache et la transmet au client.
+===== Topologie DNS d'une agence =====
+{{ :reseau:dns:dns_04.png |}}
+Remarque : la configuration IP des serveurs de la DMZ fait référence à un serveur DNS externe récursif (9.9.9.9). En effet, les serveurs de la DMZ n’ont pas la légitimité à accéder à des serveurs internes.
 ===== Conseils =====
@@ Ligne 155: / Ligne 187: @@
 ===== Schéma de résolution de nom par un hôte =====
+  * Article Wikipédia concernant DNS (https://fr.wikipedia.org/wiki/Domain_Name_System)
-Légende :
-.	Le client souhaite se connecter à l’aide de son navigateur au serveur web se nommant fr.wikipédia.org. Il a besoin de connaître à quelle adresse IP est associé ce nom de domaine. Pour cela, il va demander quelle est l’adresse IP correspondante au nom de domaine fr.wikipédia.org au serveur DNS récursif défini dans ses paramètres réseaux.
+==== La résolution et le domaine inverse ====
-.	Le serveur DNS récursif ne dispose pas de la réponse, il sollicite ainsi le serveur racine le plus proche afin d’obtenir la correspondance.
-.	Le serveur racine a.root-servers.net ne dispose pas de l’information demandée, par contre il sait quels sont les serveurs faisant autorité sur le domaine de premier niveau .org. Il demande donc au serveur récursif de solliciter l’un de ces serveurs afin d’obtenir la réponse attendue.
-.	Le serveur récursif sollicite ensuite le serveur faisant autorité sur .org le plus proche a0.org.afilias-nst.info.
-.	Le serveur a0.org.afilias-nst.info n’a pas le réponse attendue et propose donc au serveur récursif de solliciter les serveurs faisant autorité sur le sous-domaine wikipedia.org.
-.	Le serveur récursif envoie une requête auprès du serveur faisant autorité sur wikipedia.org ici ns0.wikimedia.org afin d’obtenir une réponse.
-.	Le serveur faisant autorité sur la zone wikipedia.org dispose d’un fichier de zone contenant l’enregistrement (RR) correspondant à la demande initiale. Il est donc en mesure de fournir l’information au serveur récursif : fr.wikpedia.org correspond à l’adresse IP 91.198.174.232.
-.	Le serveur récursif stocke cette réponse dans son cache et la conservera pendant toute la durée du TTL de l’enregistrement définie au préalable sur le serveur disposant du fichier de zone. Puis transfère la réponse au client.
-.	Le client, s’il dispose d’un cache, peut également stocker l’information. Il est dorénavant en mesure de pouvoir envoyer sa requête http vers le serveur web 91.198.174.232 correspondant au nom de domaine fr.wikipédia.org.
-Source : Article Wikipédia concernant DNS (https://fr.wikipedia.org/wiki/Domain_Name_System)
-.	La résolution et le domaine inverses
 Dans la plupart des recherches DNS (Domain Name System), les clients effectuent une recherche directe, à savoir une recherche basée sur le nom DNS d’un autre ordinateur stocké dans un enregistrement de ressource hôte (A). Ce type de requête attend une adresse IP comme données de ressource pour la réponse.DNS propose également un processus de recherche inversée, dans lequel les clients utilisent une adresse IP connue et recherchent un nom d’ordinateur sur la base de cette adresse.
 Une recherche inversée assume la forme d’une question du type «Pouvez-vous me donner le nom DNS de l’ordinateur qui utilise l’adresse IP 192.168.1.20 ?». DNS n’a pas été conçu initialement pour prendre en charge ce type de requête. L’un des problèmes liés à la prise en charge du processus de requête inversée est la différence dans la façon dont l’espace de noms DNS organise et indexe les noms et la façon dont les adresses IP sont affectées. Si la seule méthode permettant de répondre à la question précédente consiste à rechercher dans tous les domaines de l’espace de noms DNS,  une requête inversée prendrait trop longtemps et exigerait trop de traitement pour être réellement utile.
 Pour résoudre ce problème, un domaine spécial, le domaine in-addr.arpa, a été défini dans les normes DNS et réservé dans l’espace de noms DNS Internet afin de fournir un moyen fiable et pratique d’effectuer des requêtes inversées. Pour créer l’espace de noms inversé, des sous-domaines dans le domaine in-addr.arpa sont formés, à l’aide du classement inversé des nombres dans la notation décimale séparée par des points des adresses IP.
 La déclaration inverse est importante sur les adresses IP publiques Internet puisque l'absence d'une résolution inverse est considérée comme une erreur opérationnelle (RFC 1912) qui peut entraîner le refus d'accès à un service. Par exemple, un serveur de messagerie électronique se présentant en envoi avec une adresse IP n'ayant pas de résolution inverse (PTR) a de grandes chances de se voir refuser, par l'hôte distant, la transmission du courrier (message de refus de type : IP lookup failed).
-Sources : Cours de Marie-Pascale Delamare, professeure d’Informatique et Wikipédia.
+  * Source : Cours de Marie-Pascale Delamare, professeure d’Informatique et Wikipédia : http://www.linux-france.org/prj/edu/archinet/systeme/ch30s03.html
-Source : http://www.linux-france.org/prj/edu/archinet/systeme/ch30s03.html
-.	Sûreté et sécurité du système DNS
+==== Sûreté et sécurité du système DNS ====
 La création de DNS date de 1983. C’est donc un protocole assez ancien. À l’époque la notion de sécurité n’était pas forcément primordiale et l’accent était mis davantage sur l’efficacité du protocole. Ainsi, il a été défini que le port d’écoute des serveurs DNS serait le port 53/UDP. Pour certaines tâches spécifiques, le port 53/TCP pourra être utilisé également.
 L’émergence d’une vraie réflexion concernant la sécurité de ce protocole est apparue assez tardivement. Les attaques les plus communes concernant DNS sont les suivantes :
-·	Le cybersquatting est une attaque qui consiste à déposer un nom de domaine en portant volontairement atteinte aux droits d’un tiers pour lui nuire ou en retirer profit.
+  * Le **cybersquatting** est une attaque qui consiste à déposer un nom de domaine en portant volontairement atteinte aux droits d’un tiers pour lui nuire ou en retirer profit.
-·	Le détournement d’un nom de domaine consiste à pirater le compte lié à un domaine sur le site d’administration du bureau d’enregistrement afin de modifier les serveurs DNS faisant autorité sur cette zone. Ainsi toutes les requêtes concernant le domaine seront redirigées vers les serveurs des attaquants.
+  * Le **détournement d’un nom de domaine** consiste à pirater le compte lié à un domaine sur le site d’administration du bureau d’enregistrement afin de modifier les serveurs DNS faisant autorité sur cette zone. Ainsi toutes les requêtes concernant le domaine seront redirigées vers les serveurs des attaquants.
-·	L’empoisonnement vise à intoxiquer le résolveur pour qu’il considère que le serveur « pirate » est légitime, en lieu et place du serveur originel. Cette opération permet notamment de capter et de détourner les requêtes vers un autre site web sans que les utilisateurs puissent s’en rendre compte.
+  * **L’empoisonnement** vise à intoxiquer le résolveur pour qu’il considère que le serveur « pirate » est légitime, en lieu et place du serveur originel. Cette opération permet notamment de capter et de détourner les requêtes vers un autre site web sans que les utilisateurs puissent s’en rendre compte.
-·	Le déni de service et le déni de service distribué ont pour objectif de rendre l’accès à un service impossible ou très pénible. La différence entre les 2 attaques résident au niveau de l’attaquant. Un DoS implique une seule source quand le DDoS implique des sources multiples (des réseaux de machines zombies nommés BotNet).
+  * **Le déni de service et le déni de service distribué** ont pour objectif de rendre l’accès à un service impossible ou très pénible. La différence entre les 2 attaques résident au niveau de l’attaquant. Un DoS implique une seule source quand le DDoS implique des sources multiples (des réseaux de machines zombies nommés BotNet).
-·	Attaque par réflexion des milliers de requêtes sont envoyées par l’attaquant au nom de la victime. Lorsque les destinataires répondent, toutes les réponses convergent vers l’émetteur officiel, dont les infrastructures se trouvent affectées.
+  * **Attaque par réflexion** des milliers de requêtes sont envoyées par l’attaquant au nom de la victime. Lorsque les destinataires répondent, toutes les réponses convergent vers l’émetteur officiel, dont les infrastructures se trouvent affectées.
+==== Bonnes pratiques ====
 Voici les bonnes pratiques et les mécanismes de sécurité qui permettent d’avoir une ligne directrice afin de garantir un niveau de sécurité correcte de ce service qui s’avère souvent critique.
-·	Assurer la meilleure redondance possible, de manière à ce qu’un serveur affecté par une attaque puisse être remplacé en toute transparence par d’autres serveurs disposant des mêmes informations mais situés sur d’autres réseaux. Il est donc recommandé d’avoir au minimum deux serveurs DNS répartis dans des zones géographiques distinctes. La capacité du service DNS à résister à une panne puis à revenir à son état nominal se nomme la résilience.
+  * Assurer la meilleure redondance possible, de manière à ce qu’un serveur affecté par une attaque puisse être remplacé en toute transparence par d’autres serveurs disposant des mêmes informations mais situés sur d’autres réseaux. Il est donc recommandé d’avoir au minimum deux serveurs DNS répartis dans des zones géographiques distinctes. La capacité du service DNS à résister à une panne puis à revenir à son état nominal se nomme la résilience.
-·	Veiller à utiliser des versions à jour des logiciels DNS, notamment de BIND, corrigées par les « patchs » appropriés, afin de ne pas être vulnérable à des attaques portant sur des failles de sécurité déjà bien identifiées.
+  * Veiller à utiliser des versions à jour des logiciels DNS, notamment de BIND, corrigées par les « patchs » appropriés, afin de ne pas être vulnérable à des attaques portant sur des failles de sécurité déjà bien identifiées.
-·	Assurer une surveillance régulière de ces serveurs à l’aide d’un outil de supervision et de leur configuration avec des programmes comme zonemaster (https://www.zonemaster.fr/domain_check).
+  * Assurer une surveillance régulière de ces serveurs à l’aide d’un outil de supervision et de leur configuration avec des programmes comme zonemaster (https://www.zonemaster.fr/domain_check).
-·	Envisager un plan de continuité d’activité, permettant à la victime d’une attaque de poursuivre, ou de reprendre en cas d’incident grave, ses activités avec un minimum d’indisponibilité de ses services.
+  * Envisager un plan de continuité d’activité, permettant à la victime d’une attaque de poursuivre, ou de reprendre en cas d’incident grave, ses activités avec un minimum d’indisponibilité de ses services.
-·	Déployer DNSSec, protocole de sécurisation du DNS par l’authentification des serveurs et la signature cryptographique des enregistrements, ce système limitant notamment les attaques par empoisonnement.
+  * Déployer DNSSec, protocole de sécurisation du DNS par l’authentification des serveurs et la signature cryptographique des enregistrements, ce système limitant notamment les attaques par empoisonnement.
-·	Déployer DoT, protocole qui permet de chiffrer les échanges à l’aide du protocole TLS entre un client et un serveur DNS récursif.
+  * Déployer DoT, protocole qui permet de chiffrer les échanges à l’aide du protocole TLS entre un client et un serveur DNS récursif.
-·	Déployer le mécanisme d’authentification TSIG entre les serveurs maîtres et esclaves, mécanisme permettant d’éviter qu’une machine illégitime puisse récupérer des informations sensibles depuis le serveur maître.
+  * Déployer le mécanisme d’authentification TSIG entre les serveurs maîtres et esclaves, mécanisme permettant d’éviter qu’une machine illégitime puisse récupérer des informations sensibles depuis le serveur maître.
+  * source : DNS : types d’attaque et techniques de sécurisation publié par l’AFNIC (https://www.afnic.fr/wp-media/uploads/2021/01/DNS-types-dattaques-et-techniques-de-se%CC%81curisation.pdf).
+==== Retour Configurer le service DNS ====
+  * [[:reseau:dns:accueil|Configurer le service DNS]]
-Source : DNS : types d’attaque et techniques de sécurisation publié par l’AFNIC (https://www.afnic.fr/wp-media/uploads/2021/01/DNS-types-dattaques-et-techniques-de-se%CC%81curisation.pdf).

Les cours du BTS SIO

Outils pour utilisateurs

Outils du site

Différences

Outils de la page