Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Linux
  3. Domain Name Server
Extrait - Linux Administration système et exploitation des services réseau (5e édition)
Extraits du livre
Linux Administration système et exploitation des services réseau (5e édition)
1 avis
Revenir à la page d'achat du livre

Domain Name Server

Domain Name Server

Ce chapitre traite de la gestion d’un serveur DNS Linux, configuration de base, définition des zones de noms et d’adresses, sécurisation.

1. Configuration de base d’un serveur DNS

L’objectif de cette section est de vous apprendre à :

  • configurer un serveur BIND ayant autorité sur une zone DNS et un serveur de cache récursif. Cela inclut la gestion de l’activité du serveur et la configuration des logs.

a. Compétences principales

  • Terminologie, fichiers de configuration et utilitaires de BIND 9.x.

  • Détermination de l’emplacement des fichiers de zone dans la configuration de BIND.

  • Rechargement des fichiers de configuration et de zone après modification.

  • Connaissance d’autres serveurs DNS : dnsmasq, djbdns et PowerDNS.

b. Éléments mis en œuvre

  • /etc/named.conf

  • /var/named/

  • rndc

  • named-checkconf

  • kill

  • host

  • dig

2. Création et gestion des zones DNS

L’objectif de cette section est de vous apprendre à :

  • créer un fichier de zone pour une zone directe ou inverse, et un fichier de déclaration des serveurs de niveau racine. Cela inclut la configuration correcte des enregistrements, l’ajout de noms d’hôtes dans une zone et de zones dans DNS. Délégation de zones auprès d’un autre serveur DNS.

a. Compétences principales

  • Terminologie, fichiers de configuration et utilitaires...

Configuration de base d’un serveur DNS

DNS (Domain Name System) est un protocole de résolution de noms, permettant de faire la relation entre un nom d’hôte ou de service et une adresse IP. Il a été créé en 1983 par Paul Mockapetris et Jon Postel, et défini à l’origine dans les RFC 882 et 883 (remplacées depuis par les RFC 1034 et 1035). Il est devenu le standard de fait pour la résolution de noms sur Internet.

1. Principes de DNS

DNS est un système de résolution de noms structuré en arborescence. Cette arborescence virtuelle est organisée en domaines et sous-domaines. Chaque domaine ou sous-domaine constitue un nœud de l’arborescence et peut contenir des noms associés à des adresses IP. Il existe également une branche de l’arborescence permettant de résoudre des adresses IP en noms d’hôtes ou de services (résolution inverse).

Les domaines et sous-domaines sont gérés par des serveurs de noms DNS qui coopèrent entre eux pour fournir aux clients DNS la relation entre des noms et des adresses IP. Ces dernières peuvent être des adresses IPv4 ou IPv6.

L’arborescence DNS peut être privée ou publique. La plus grande arborescence DNS publique est celle d’Internet.

a. Clients et serveurs DNS

Un client DNS (resolver) interroge un serveur DNS pour connaître la ou les adresses IP correspondant à un nom (résolution de nom), ou inversement pour connaître le ou les noms correspondant à une adresse IP (résolution d’adresse ou résolution inverse). Le serveur DNS répond s’il a les éléments suffisants, sinon il interroge d’autres serveurs DNS et répond finalement à son client, en fournissant les éléments demandés ou un code réponse d’échec de la résolution.

Un nom peut être un nom de machine (nom d’hôte) ou un nom de service (par exemple, serveur de noms, serveur de messagerie…). Un nom peut correspondre à plusieurs adresses IP, une adresse IP peut correspondre à plusieurs noms.

Pour pouvoir gérer un très grand nombre de noms, en perpétuelle évolution, de façon fiable et décentralisée...

Création et gestion des zones DNS

Un serveur primaire DNS gère une ou plusieurs zones, correspondant chacune à un domaine ou à un sous-domaine d’une arborescence DNS. Il peut éventuellement fournir une copie d’un fichier de zone, en lecture seulement, à un ou plusieurs serveurs secondaires. Ces derniers peuvent ainsi fournir des réponses faisant autorité à des demandes de résolution concernant des enregistrements de la zone. Par contre, seul le serveur primaire peut mettre à jour le contenu du fichier de zone.

Un serveur DNS peut être serveur primaire pour une ou plusieurs zones et serveur secondaire pour d’autres zones.

À chaque fichier de zone devrait correspondre un fichier de zone de recherche inverse, permettant la résolution inverse (fournir le nom DNS correspondant à une adresse IP). Il faudrait de même un fichier de zone de recherche inverse pour les adresses IPv6.

Le contenu d’un fichier de zone obéit à une syntaxe précise et contraignante, la moindre erreur peut empêcher son chargement par un serveur DNS.

1. Fichier de zone de recherche

La zone doit être déclarée dans le fichier de configuration named.conf par une directive zone spécifiant le nom de la zone, son type et le nom du fichier de zone.

Le fichier de zone doit se trouver dans le répertoire de données déclaré dans le fichier de configuration named.conf, par l’option directory (par défaut /var/named ou /var/cache/bind).

Exemple

Déclaration d’une zone dans le fichier named.conf :

zone "lpic2test.fr" IN { 
       type master; 
       file "lpic2.zone"; 
}; 

Il s’agit d’une zone de type master, pour laquelle le serveur DNS joue le rôle de serveur principal.

Un fichier de zone contient un enregistrement de type SOA, décrivant les caractéristiques de la zone, et un ensemble d’enregistrements de ressources (type RR) pour chaque nom d’hôte ou de service de la zone.

Dans un fichier de zone, les commentaires vont du caractère ; jusqu’à la fin de la ligne. Le séparateur de champs est une suite de caractères espace ou tabulation, le séparateur d’enregistrements...

Sécuriser un serveur DNS

Un serveur DNS est susceptible de recevoir des demandes issues de l’inter-réseau auquel il participe, demandes pouvant provenir de clients DNS ou d’autres serveurs DNS. Il peut donc constituer un point d’entrée vers l’organisation dont il dépend, et être utilisé pour recueillir des informations sensibles (adresses et noms de machines ou de services réseau).

D’autre part, dans l’hypothèse d’une faille de sécurité dans le programme exécutable de BIND, un serveur DNS pourrait être utilisé pour prendre le contrôle du système sur lequel il s’exécute, ou pour fournir des informations sensibles (comptes utilisateurs, etc.).

Différentes techniques permettent de sécuriser un serveur BIND :

  • Limiter les clients et serveurs DNS autorisés à communiquer avec lui.

  • Répartir les données noms/adresses entre plusieurs serveurs.

  • Restreindre les possibilités de lecture-écriture du serveur à une branche de l’arborescence du système de fichiers global (chroot jail).

1. Contrôle des clients autorisés

Un serveur BIND peut être configuré pour ne traiter les demandes que d’hôtes autorisés et/ou pour refuser les demandes de certains hôtes. La sélection peut se faire en spécifiant des adresses IP ou des identifiants de réseau/sous-réseau.

a. L’option allow-query

L’option allow-query, dans la directive options du fichier de configuration named.conf, permet de spécifier les clients DNS autorisés à interroger le serveur BIND.

Syntaxe

allow-query {Liste}; 

La liste est composée d’éléments délimités par un caractère ’;’. Un élément peut être :

  • une adresse IP, IPv4 ou IPv6,

  • un identifiant de réseau, IPv4 ou IPv6, en notation CIDR,

  • un mot-clé prédéfini : none (aucun), any (tous), localhost (machine locale), localnets (réseaux de la machine locale),

  • l’identifiant d’une liste définie au préalable (acl),

  • l’un des éléments précédents, précédé du caractère ! pour l’exclure de la liste autorisée.

Pour...