<!-- Slide number: 1 --> Institut Supérieur des Etudes Technologiques de Bizerte # Protocoles et services réseaux Niveau: SEM2 Enseignante: Mme Ines ABBES A.U: 2015/2016
Notes:
<!-- Slide number: 2 --> # Chapitre 3 DNS (Domain Name Service)
<!-- Slide number: 3 --> # Problématique Avant le DNS, la résolution se faisait grâce à un fichier texte appelé hosts, local à chaque ordinateur. Sous UNIX et ses dérivés, il se trouve dans le répertoire /etc. Sous Windows, il se trouve, par défaut, dans %SystemRoot%\system32\drivers\etc. Dans ce fichier, chaque ligne correspond à une adresse IP à laquelle peuvent être associés un ou plusieurs noms de domaine. Il est ainsi évident que ce système pose un problème de maintenance car le fichier doit être recopié sur tous les ordinateurs du réseau. A l'échelle internet, le fichier hosts était fourni et géré par Arpanet. 3
Notes:
<!-- Slide number: 4 --> # Historique le DNS fait son apparition en 1983 avec Paul Mockapetris, qui en implémenta la première version alors qu'il travaillait à l'Information Sciences Institute (ISI) de l'Université de la Californie du Sud. DNS, est aussi un protocole qui est rattaché aux RFC 882, 883, 1034 et 1035. (RFC=Request For Comment, documents de l'IETF (Internet Engineering Task Force) définissant les standards d'Internet.)
4
<!-- Slide number: 5 --> # Définition Le Domain Name System (ou DNS, système de noms de domaine) est un système permettant d'établir une correspondance entre une adresse IP et un nom de domaine, mais plus généralement de trouver une information à partir d'un nom de domaine.
5
Notes:
<!-- Slide number: 6 --> # Rôle d’un serveur DNS établir une correspondance entre adresses IP, par exemple 147.210.94.197 noms de domaines, www.google.com Résolution, résolution inverse et plus généralement, trouver des informations à partir d’un nom de domaine (par exemple liste des échangeurs de courrier). Système réparti sur des centaines de milliers de serveurs DNS 6
<!-- Slide number: 7 --> # Notions de base: Domaine Domaine: Un domaine est un ensemble d'ordinateurs reliés dans un réseau, par exemple internet et possédant une caractéristique commune. Le domaine est identifié à un nom, appelé nom de domaine. Ce nom est constitué d'au moins un mot appelé label. 7
<!-- Slide number: 8 --> # Notions de base: Sous-domaine Dans la nomenclature d'un nom de domaine, le domaine supérieur est écrit à droite, et le caractère point (.) sépare le nom du domaine supérieur du nom du domaine inférieur. Un domaine appartenant à un autre est appelé sous-domaine de ce domaine. 8
<!-- Slide number: 9 --> # Notions de base: Zone Une zone est une portion d'un domaine dont l'administration est déléguée à une entité faisant partie ou non de l'organisation. Le concept de zone est purement au niveau administratif. La déclaration des machines dans un domaine se fait dans les zones. Le fichier qui contient les enregistrements des machines d'une zone est appelée fichier de zone. Le rôle d’une zone est principalement de simplifier l’administration des domaines. 9
<!-- Slide number: 10 --> # Notions de base: Hôte Chaque domaine contient des ordinateurs ou des serveurs. Ce sont eux les hôtes. Les hôtes sont les points finaux de la chaîne. Leurs noms sont qualifiés de Fully Qualified Domain Name (FQDN), c'est-à-dire Nom de Domaine Totalement Qualifié. La profondeur maximale autorisée pour atteindre l'hôte est de 127 niveaux, et la taille maximale du FQDN est de 255 caractères. Un FQDN doit toujours se terminer par un point (.) Exemple: www.isetbiz.rnu.tn. 10
<!-- Slide number: 11 --> # Fonctionnement Logique D'un point de vue logique, les noms de domaine sont agencés dans une arborescence, voire une hiérarchie. On a au sommet une racine, et une arborescence de nœuds terminée par des feuilles.
 tn com net Google yahoo université iset 11
<!-- Slide number: 12 --> La racine est un point. Elle est gérée par l'ICANN (Internet Corporation for Assigned Names and Numbers). Tous les nœuds fils de la racine sont administrés par cette organisation. Ces nœuds sont appelés Top Level Domain ou TLD. On distingue trois principaux types de TLD : le TLD spécial .arpa les TLD géographiques ou nationaux les TLD génériques 12
<!-- Slide number: 13 --> # Le TLD spécial : c'est un domaine exploité exclusivement à des fins techniques. ARPA signifie Address and Routing Parameters Areas, qui veut dire zone des paramètres d'adressage et de routage.
Les TLD géographiques ou nationaux (cTLD= Country TLD): ce sont des TLD propres à chaque pays du monde. Tous les pays en possèdent un. De façon nationale, ils sont gérés par des bureaux accrédités. Il y en a 250 TLD géographiques: .fr, .tn…
13
<!-- Slide number: 14 --> # Les TLD génériques ou gTLD (Generic TLD): ce sont les autres TLD. On les considère comme 'libres' contrairement aux précédents. Ils sont généralement utilisés par les structures internationales telles que les multinationales, les institutions, les organismes non gouvernementales, etc. La liste totale des TLD génériques valides en Avril 2009 est présentée dans le tableau ci-dessous. Il y en a 15. 14
<!-- Slide number: 15 --> #
15
<!-- Slide number: 16 --> # Le domaine in-addr.arpa (1) Le principe de la résolution de nom, consiste à affecter un nom d’hôte une adresse IP. On parle de résolution de nom directe. Le processus inverse doit pouvoir également être mis en œuvre. On parle de résolution de nom inverse ou reverse. Le processus doit fournir, pour une adresse ip, le nom correspondant. Pour cela il y a une zone particulière, in-addr.arpa, qui permet la résolution inverse d’adresse IP. 16
<!-- Slide number: 17 --> #
17
<!-- Slide number: 18 --> # Le domaine in-addr.arpa (2) Par exemple, pour le réseau 192.168.1.0, on créera une zone inverse dans le domaine inaddr.arpa. La zone de recherche inverse dans le domaine deviendra : 1.168.192.in-addr.arpa. Cette zone devra répondre pour toutes les adresses déclarées dans la tranche 192.168.1.1 à 192.168.1.254. 18
<!-- Slide number: 19 --> # Fonctionnement logique
 www.google.com Google.com www.google.com
19
<!-- Slide number: 20 --> # Principe de fonctionnement Le service DNS est une application client/serveur, c'est à dire que d'un côté on a un client (hôte) qui émet une requête DNS, et de l'autre côté, il y a un serveur (programme) qui répond à cette requête 20
<!-- Slide number: 21 --> # Principe de fonctionnement
21
<!-- Slide number: 22 --> # Fonctionnement du client: le resolver Le resolver permet de communiquer avec les serveurs DNS. il y a 2 modes d'interrogation de serveur: • Récursif • Itératif 22
<!-- Slide number: 23 --> # Requête récursive (1) Une requête récursive est une requête envoyée à un serveur DNS dans laquelle le client DNS demande au serveur de fournir une réponse complète. Dans une requête récursive, le serveur DNS interrogé doit renvoyer l’une des trois réponses suivantes : Les données demandées. Un message d’erreur indiquant que les données du type demandé n’existent pas. Un message indiquant que le nom de domaine spécifié n’existe pas.
23
<!-- Slide number: 24 --> # Requête récursive (2)
24
<!-- Slide number: 25 --> # Requête itérative (1) Une requête itérative est une requête envoyée à un serveur DNS dans laquelle le client DNS demande la meilleure réponse que peut fournir le serveur DNS. Le résultat d’une requête itérative est souvent une référence à un autre serveur DNS situé plus bas dans l’arborescence DNS. 25
<!-- Slide number: 26 --> Requête itérative (2)
Publicité
Notes:
<!-- Slide number: 27 --> # Remarque En général, le mode récursif est utilisé par les applications clientes et le mode itératif par les resolvers des serveurs de noms. Pour des raisons de performance et de sécurité, les administrateurs des serveurs de nom les configurent généralement pour qu'ils n'acceptent les requêtes en mode récursif que pour les machines de la zone pour laquelle ils sont autoritaires. 27
<!-- Slide number: 28 --> #
28
<!-- Slide number: 29 --> Mise en cache d’un serveur DNS (2)
Notes:
<!-- Slide number: 30 --> # Mise en cache d’un serveur DNS (3) Le cache s'enrichit au fur à mesure du traitement des requêtes des clients. Ses données ont une durée de vie limitée qui est spécifiée dans le champ TTL(Time To Live) associé à chaque ressource. Ceci permet de ne pas maintenir dans le cache des informations périmées et de les rafraîchir en fonction de la valeur du TTL. Une configuration minimale d'un serveur cache contient la liste des serveurs de la racine (serveurs root) ainsi que l'enregistrement pour le reverse du loopback (1.0.0.127.in-addr.arpa). 30
<!-- Slide number: 31 --> # Serveur autoritaire (1) Dans l'arbre de nommage, une zone est associée à chaque nœud qui correspond, lui, à un domaine. Le serveur de nom dans lequel est stocké la base de données de la zone est dit "faisant autorité sur la zone". Il est aussi appelé serveur autoritaire. Compte tenu de l'importance de la base de données de zone, il y a en général plusieurs serveurs autoritaires pour chaque zone. 31
<!-- Slide number: 32 --> # Serveur autoritaire (2) Lors de la mise à jour, les modifications des enregistrements ne sont faites que sur un seul serveur autoritaire de la zone. Ce serveur est appelé serveur primaire ; on dit qu'il a l'origine de l'autorité sur la zone (SOA : Start Of Autorithy). Les autres serveurs autoritaires de la zone sont appelés serveurs secondaires et disposent chacun d'une copie de la base de données du serveur primaire. Ces copies sont mises à jour régulièrement suivant un mécanisme appelé transfert de zone. 32
<!-- Slide number: 33 --> # Serveur autoritaire (3) Outre les aspects sécurité et de continuité de service, l'avantage de disposer de plusieurs serveurs autoritaires pour une zone est la répartition de la charge et l'optimisation de l'accès suivant la situation géographique par rapport aux serveurs (en terme de "proximité réseau"). 33
<!-- Slide number: 34 --> # Serveur autoritaire (4)
www.afnic.fr 192.134.4.20
34
<!-- Slide number: 35 --> # Remarque Un serveur peut être à la fois serveur cache et serveur autoritaire pour des zones.Son cache contient alors aussi bien des données locales que non locales. 35
<!-- Slide number: 36 --> #
36
<!-- Slide number: 37 --> # Transport dans DNS: utilisation de UDP Le port serveur utilisé pour l'envoi des datagrammes en UDP est 53. Les datagrammes Dns en UDP sont limités à 512 octets (valeur représentant les données sans l'entête UDP et IP). Les datagramme plus long doivent être tronqué à l'aide du champ Tc. L'utilisation d'Udp n'est pas recommandée pour les transfert de zone, mais uniquement pour les requêtes standards. 37
<!-- Slide number: 38 --> # Transport dans DNS: utilisation de TCP Le port serveur utilisé pour l'envoi des datagrammes en Tcp est 53. Le datagramme inclus alors un champ de deux octets nommé "longueur", il permet de spécifier la longueur totale des données indépendamment de la fragmentation. La longueur est calculée sans les 2 octets de ce même champ. 38
<!-- Slide number: 39 --> # Les fichiers de configuration le fichier /etc/bind/named.conf: décrit la configuration générale du serveur DNS. les fichiers dans /var/named: contiennent les enregistrements de ressources pour la zone dont on a autorité. 39
Publicité
<!-- Slide number: 40 --> # Le fichier /etc/bind/named.conf C’est dans ce fichier que se fait la configuration générale du serveur DNS. Ce fichier est composé de sections qui ont cette forme:
Section { Variable valeur; .. }; 40
<!-- Slide number: 41 --> # Le fichier /etc/bind/named.conf Il existe différentes sortes de sections, les plus utilisées étant: la section options:qui concerne la configuration générale du serveur La section zone: qui définit les zones d’un domaine. 41
<!-- Slide number: 42 --> # la section: options
La déclaration options définit les options globales de configuration serveur et établit des valeurs par défaut pour les autres déclarations. Cette déclaration peut être utilisée entre autres pour spécifier l'emplacement du répertoire de travail named ou pour déterminer les types de requêtes autorisés.
42
<!-- Slide number: 43 --> # la section: options La déclaration options se présente sous le format suivant:
Dans cette déclaration, les directives <option> sont remplacées par une option valide. Ci-dessous figure une liste des options couramment utilisées :
options { <option>; [<option>; ...] }; 43
<!-- Slide number: 44 --> # la section: options allow-query: Spécifie les hôtes autorisés à interroger ce serveur de noms. Par défaut, tous les hôtes sont autorisés à interroger le serveur de noms. Il est possible d'utiliser ici une liste de contrôle d'accès ou un ensemble d'adresses IP ou de réseaux afin de n'autoriser que des hôtes particuliers à interroger le serveur de noms. Directory: Change le répertoire de travail named pour une valeur autre que la valeur par défaut, /var/named/.
options { directory “/var/named”; }; 44
<!-- Slide number: 45 --> # la section: options Une directive listen-on peut ressembler à l'extrait ci-dessous :
Dans cet exemple, seules les requêtes qui proviennent de l'interface réseau servant le réseau privé (10.0.1.1) sont acceptées.
options { Listen-on {10.0.1.1;}; }; 45
<!-- Slide number: 46 --> # la section: options notify — Établit si named notifie les serveurs esclaves lorsqu'une zone est mise à jour. Les options suivantes sont acceptées : yes — Notifie les serveurs esclaves. no — Ne notifie pas les serveurs esclaves. explicit — Notifie seulement les serveurs esclaves spécifiés dans une liste also-notify à l'intérieur d'une déclaration de zone.
46
<!-- Slide number: 47 --> # La section: zone Une déclaration zone définit les caractéristiques d'une zone tels que l'emplacement de ses fichiers de configuration et les options spécifiques à la zone. Cette déclaration peut être utilisée pour remplacer les déclarations globales d'options. Une déclaration zone se présente sous le format suivant :
Dans la déclaration, <zone-name> correspond au nom de la zone, <zone-class> à la classe optionnelle de la zone et <zone-options> représente une liste des options caractérisant la zone.
zone <zone-name> <zone-class> { <zone-options>; [<zone-options>; ...] }; 47
<!-- Slide number: 48 --> # La section zone: exemple
Le IN est optionnel. S’il n’est pas indiqué, il s’agit d’une zone INTERNET (IN) par défaut. On peut donc écrire:
zone “mondomaine.com” IN { type master; file “mondomaine.com”; }; zone “mondomaine.com” { type master; file “mondomaine.com”; }; 48
<!-- Slide number: 49 --> # La section zone: zone-name L'attribut <zone-name> de la déclaration de zone est particulièrement important. Il représente le nom de la zone qui sera utilisé au sein du fichier de zone correspondant qui se trouve dans le répertoire /var/named/. Le démon named ajoute le nom de la zone à tout nom de domaine qui n'est pas pleinement qualifié, énuméré dans le fichier de zone. Par exemple, si une déclaration zone définit l'espace de nom pour example.com, on utilise example.com comme <zone-name> afin qu'il soit placé à la fin des noms d'hôtes au sein du fichier de zone example.com.
49
<!-- Slide number: 50 --> # La section zone: zone-options type — Définit le type de zone. Les types énumérés ci-dessous peuvent être utilisés Type [master|slave|stub|forward|hint] Master définit le serveur DNS comme ayant autorité sur cette zone. Slave une zone esclave est une réplication d’une zone maître. A cette directive s’ajoute une autre directive obligatoirement présente dans cette zone, la directive masters qui définit une liste d’adresse IP qui correspondent aux serveurs DNS maître. 50
<!-- Slide number: 51 --> # La section zone: zone-options Stub identique à slave mais seuls les enregistrements de type NS seront mis à jour. Forward une zone forward n’a qu’un seul but: rediriger toutes les requêtes pour cette zone vers d’autres serveurs. Hint la zone hint définit la zone racine. Lors du démarrage du serveur DNS, cette zone est utilisée pour récupérer la liste la plus récente des serveurs DNS racine.
51
<!-- Slide number: 52 --> # Exemples de configuration Dans ce qui ce qui suit on va considérer deux configurations possibles d’un serveur DNS: Serveur DNS cache Serveur primaire pour le domaine example.com 52
<!-- Slide number: 53 --> # Exemples de configuration: serveur DNS cache Il s’agit de la configuration minimale d’un serveur DNS. Celui-ci ne répond pas aux requêtes. Il les transmet aux serveurs DNS puis récupère les informations pour les transmettre à l’émetteur de la requête et pour les mettre en cache afin de ne pas avoir à les redemander lors de la prochaine requête. 53
<!-- Slide number: 54 --> # Exemples de configuration: serveur DNS cache options { directory "/var/named"; }; zone "." { type hint; file "named.ca"; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; };
54
<!-- Slide number: 55 --> # Exemples de configuration: serveur DNS cache
Cette section représente le domaine racine ("root" ou "."). Les adresses IP des serveurs de ce domaine se trouvent dans le fichier named.ca, fichier fourni avec le serveur DNS, et qui doit ce trouver dans le répertoire /var/named. zone "." { type hint; file "named.ca"; }; 55
<!-- Slide number: 56 --> # Exemples de configuration: serveur DNS cache zone "0.0.127.in-addr.arpa" { type master; file "named.local"; };
Il s’agit de la zone de domaine local. Le fichier named.local permet de résoudre l’adresse de boucle locale (localhost) 56
<!-- Slide number: 57 --> # Exemples de configuration: serveur primaire pour le domaine example.com options { directory "/var/named"; }; zone "." { type hint; file "named.ca"; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; }; zone "example.com" { type master; file "example.com"; }; zone "1.168.192.in-addr.arpa" { type master; file "example.com.rev"; };
57
<!-- Slide number: 58 --> # Les fichiers de zone (1) Les zones sont associées par deux: la zone utilisée pour faire la résolution de nom (nom->adresse IP) et la zone utilisée pour la résolution inverse (adresse IP->nom). Pour cette dernière le nom de la zone possède une syntaxe particulière: il s’agit de l’adresse IP inversée terminée par .in-addr.arpa. Exemple pour le réseau 192.168.1.0 le nom de la zone inverse sera “1.168.192.in-addr.arpa”. Il y a toutefois deux exceptions: la zone “. ” (root) qui n’a pas de zone inverse et la zone “0.0.127.in-addr.arpa” qui n’a pas non plus son inverse. 58
<!-- Slide number: 59 --> # Les fichiers de zone (2)
Les fichiers de zone sont constitués d’enregistrements de ressources DNS nommés RR (Ressource Records) de la forme:
[nom] [TTL] classe type donnée
59
<!-- Slide number: 60 --> # Exemple de fichier de zone
60
<!-- Slide number: 61 --> # Enregistrement de ressources RR: Le nom Nom du domaine où se trouve le RR. Ce champ est implicite lorsqu'un RR est en dessous d'un autre, S’il est absent, cet enregistrement prend le nom du précédent. 61
Publicité
<!-- Slide number: 62 --> # Enregistrement de ressources RR: TTL (Time To Live) TTL:C'est la durée de vie des RRs (32 bits, en secondes), utilisée par les solveurs de noms lorsqu'ils ont un cache des RRs pour connaître la durée de validité des informations du cache.
En son absence, il s’agit de la durée de vie définie en première ligne du fichier de zone ($TTL) 62
<!-- Slide number: 63 --> # Enregistrement de ressources RR: les classes Indique le réseau de transport utilisé. Pour les réseaux TCP/IP, il s’agit de la classe IN (Internet). La classe la plus communément utilisée est la classe IN Sinon il y a en plus la classe HS (hesiod service d’information développé par le projet Arhena) et CH (chaos pour définir différentes données du réseau CHAOS développé par MIT dans les années 70) 63
<!-- Slide number: 64 --> # Enregistrement de ressources RR : les types Ce champ type, codé sur 16 bits, spécifie quel type de donnée sont utilisés dans le RR. Voici les principaux types disponibles: 64
<!-- Slide number: 65 --> # Les types d’enregistrements (1)
SOA : (Start Of Authority) contient certaines informations de la zone. Il y a un seul enregistrement SOA par zone DNS. C'est le premier enregistrement crée dans une zone DNS.
65
<!-- Slide number: 66 --> # Les types d’enregistrements (2) A : (Address) Les enregistrements de ressources A (pour Adresse d'hôte) sont des mappage entre un nom d'hôte et une adresse IPv4 (adresse IP d'une longueur de 32 bits). Ils représentent généralement la majorité des enregistrements de ressources des zones de recherches directes. AAAA : Les enregistrements de ressources de ce type sont des mappages entre un nom d'hôte et une adresse IPv6 (adresse IP d'une longueur de 128 bits).
66
<!-- Slide number: 67 --> # Les types d’enregistrements (2) CNAME : les enregistrements de ressources de type CNAME (Canonical NAME ou nom canonique) sont des mappages entre un nom d'hôte et un autre nom d'hôte. Ils permettent de créer des alias pour un nom d'hôte donné (c'est-à-dire d'associer plusieurs noms d'hôte à une même machine). MX : les enregistrements de ressources de type MX (Mail eXchanger) identifient les serveurs de messageries. Chaque serveur de messagerie doit aussi disposer d'un enregistrement de ressource A. Il est possible de donner une priorité différente à chaque enregistrement MX.
67
<!-- Slide number: 68 --> # Les types d’enregistrements (3) NS : les enregistrements de ressources de type NS (Name Server ou serveur de nom) identifient les serveurs DNS de la zone DNS. Ils sont utilisés dans le cadre de la délégation DNS. PTR : les enregistrements de ressources de type PTR (PoinTeR ou pointeur) sont des mappages entre une adresse IP et un nom d'hôte. Il représentent la majorité des enregistrements des zones de recherches inversées.
68
<!-- Slide number: 69 --> # Enregistrement de ressources RR : données Données identifiant la ressource, ce que l'on met dans ce champs dépend du type de ressources que l'on décrit. A : une adresse IP sur 32 bits. Cname : un nom de domaine. Ptr : Une adresse IP sous forme d'un nom. Ns : Un nom d'hôte 69
<!-- Slide number: 70 --> # Première entrée d’un fichier de zone : $TTL Chaque fichier de zone doit commencer par une ligne de la forme: $TTL durée Cette ligne spécifie aux autres serveurs DNS combien de temps ils doivent garder en cache les enregistrements de cette zone. La valeur durée peut être un nombre représentant la durée en seconde ou une chaîne de caractères composée de nombre suivi de ‘s’ pour seconde, ‘m’ pour minute, ‘h’ pour heure, ‘d’ pour jour (day) et ‘w’ pour semaine (week). 70
<!-- Slide number: 71 --> # Première entrée d’un fichier de zone : $TTL Si cette ligne n’est pas présente, named utilisera la valeur TTL minimale spécifiée dans l’enregistrement SOA. Exemples: $TTL 86400 indique un TTL de 86400 secondes (une journée de 24h) $TTL 1d Idem que exemple1 $TTL 1d12h indique un TTL d’une journée et demi) Les valeurs de TTL sont généralement entre une heure et une journée.
71
<!-- Slide number: 72 --> # Deuxième entrée d’un fichier de zone : L’enregistrement SOA zone IN SOA nom_du_serveur_primaire adresse_mail_de_l_administrateur ( serial rafraichissement nouvel essai expire minimum ) 72
<!-- Slide number: 73 --> # Deuxième entrée d’un fichier de zone : L’enregistrement SOA zone: nom de la zone décrite par ce fichier. zone peut être remplacée par le caractère ‘@’ qui représentera le nom de la zone décrite par ce fichier et correspond à la zone dans le fichier de configuration named.conf. IN: signifie qu’il s’agit d’une zone Internet. Ensuite viennent le serveur de nom puis l’adresse mail de la personne qui gère cette zone. Attention, dans cette adresse mail le ‘@’ est remplacé par un point. Exemple [email protected] devient moi.mondomaine.com. 73
<!-- Slide number: 74 --> # Deuxième entrée d’un fichier de zone : L’enregistrement SOA Serial: il s’agit d’un nombre qui doit être incrémenté à chaque modification. C’est grâce à lui qu’un serveur secondaire sait qu’il y a eu modification et donc qu’il doit se mettre à jour ce nombre est souvent composé d’une date suivie de deux chiffres représentant l’énième modification du jours: YYYYmmddaa (YYYY= année sur 4 chiffres, mm=mois sur 2 chiffres, dd=jour sur 2 chiffres et aa=numéro de la modification).
74
<!-- Slide number: 75 --> # Deuxième entrée d’un fichier de zone : L’enregistrement SOA Rafraichissement: Représente la durée en seconde au bout de laquelle un serveur secondaire va vérifier si le serial a été modifié. Si c’est le cas, le serveur secondaire télécharge le fichier de la zone correspondante à partir du serveur primaire. Nouvel essai: indique le temps en secondes au bout duquel le serveur secondaire essaiera une nouvelle mise à jour, en cas d’ échec du premier rafraichissement. 75
<!-- Slide number: 76 --> # Deuxième entrée d’un fichier de zone : L’enregistrement SOA expire: correspond à la durée de vie des enregistrements de la zone. une valeur entre 1209600 et 2419200 secondes (2 à 4 semaines) est recommandée. minimum: temps minimum en seconde durant lequel les serveurs de noms doivent conserver en cache les réponses négatives à leurs requêtes provenant du serveur de nom ayant autorité sur cette zone. Une valeur de 3600 à 10800 secondes (1 à 3 heures) est recommandée. Une valeur supérieure à un jour peut poser problème. 76
<!-- Slide number: 77 --> # Remarque Il faut toujours ajouter un point à la fin du nom de la machine et de l’adresse mail si vous les spécifiez jusqu’à la racine. Exemple: si vous notez comme nom de machine “dns.mondomaine.com” sans le point, ce nom n’est pas FQDN et désigne en fait “dns.mondomaine.com.mondomaine.com” Tandis que “dns.mondomaine.com.” est FQDN et désigne donc bien “dns.mondomaine.com” .
77
<!-- Slide number: 78 --> # Troisième entrée dans le fichier de zone: l’enregistrement NS Après le SOA , se trouvent un ou plusieurs enregistrement(s) NS qui désignent le ou les serveur(s) de nom de cette zone. Ils sont de la forme: zone IN NS nom.du.serveur.de.noms Zone: le nom de la zone décrite dans ce fichier, peut aussi être remplacé par @, comme au niveau de l’enregistrement SOA. Il peut aussi être omis et dans ce cas sa valeur sera celle du champ zone de l’enregistrement précédent (l’enregistrement SOA ou un enregistrement NS)
78
<!-- Slide number: 79 --> # Exemple de fichier de zone: résolution directe
79
<!-- Slide number: 80 --> # Exemple de fichier de zone: résolution inverse Question: Déduire du fichier de zone directe, le fichier de zone inversé. 80
<!-- Slide number: 81 --> # Exemple de fichier de zone: résolution inverse
 81
<!-- Slide number: 82 --> # Délégation d’une zone Pour de grands domaines, il peut être utile de mettre en place plusieurs serveurs DNS, chacun gérant sa zone correspondant à son sous-domaine. Supposons que le domaine mondomaine.com veut déléguer la gestion des sous-domaines zone1.mondomaine.com et zone2.mondomaine.com aux serveurs de noms dns.zone1.mondomaine.com (192.168.1.1) et dns.zone2.mondomaine.com (192.168.2.1), il faut que dans le fichier de zone de mondomaine.com figurent les lignes suivantes: 82
<!-- Slide number: 83 --> # Délégation d’une zone
Le mécanisme qui permet d'établir un lien entre un nom de domaine et une adresse IP pour les serveurs de noms des zones déléguées s’appelle la glue. zone1.mondomaine.com IN NS dns.zone1.mondomaine.com zone2.mondomaine.com IN NS dns.zone2.mondomaine.com
dns.zone1.mondomaine.com IN A 192.168.1.1 dns.zone2.mondomaine.com IN A 192.168.2.1 83
<!-- Slide number: 84 --> # Les outils de diagnostic de DNS named-checkconf: c’est un outil fourni avec BIND par défaut qui permet de vérifier la syntaxe d’un fichier de configuration. Syntaxe: named-checkconf /etc/named.conf named-checkzone: Une fois que la configuration de BIND est correcte, l’outil named-checkzone permet de vérifier la syntaxe d’une zone. Syntaxe
named-checkzone mondomaine.com /var/named/mondomaine.com
84
<!-- Slide number: 85 --> # Les outils de diagnostic de DNS Dig : La commande dig permet d’interroger sélectivement des serveurs DNS. Nslookup : est un utilitaire de ligne de commandes employé pour diagnostiquer les éventuels problèmes liés à l’infrastructure DNS.
85
<!-- Slide number: 86 --> # Configuration côté client Au niveau du client, il faut ajouter au niveau du fichier /etc/resolv.con: Domain mondomaine.com Nameserver 192.168.1.1 86