Les noms de domaines – Concepts et éléments de base

1. STATUT DE CE MEMO
2. INTRODUCTION
2.1. Historique des noms de domaines
2.2. Objectifs de la conception du DNS
2.3. Présupposés concernant l’utilisation
2.4. Eléments du DNS
3. ESPACE DE NOMS DE DOMAINES et ENREGISTREMENTS DE RESSOURCES
3.1. Spécifications et terminologie des Noms de Domaine
3.2. Conseils pour l’administration
3.3. Conseils techniques d’utilisation
3.4. Exemple d’espace de noms
3.5. Syntaxe préférentielle pour les noms
3.6. Enregistrements
3.6.1. Expression des RR sous forme textuelle
3.6.2. Alias et expression canonique des noms
3.7. Requêtes
3.7.1. Requête Standard
3.7.2. Rétro-requêtes (Optionel)
3.8. Requêtes d’état (Expérimental)
3.9. Requêtes de Fin de Traitement (Obsolète)
4. SERVEURS DE NOMS DE DOMAINE
4.1. Introduction
4.2. Comment la base de données est divisée en zones
4.2.1. Considérations techniques
4.2.2. Considérations en termes d’administration
4.3. Serveur de noms – spécifications internes
4.3.1. Requêtes et réponses
4.3.2. Algorithme
4.3.3. Métaenregistrements
4.3.4. Mise en cache de réponses négatives (Optionnel)
4.3.5. Maintenance et transfert de zones
5. RESOLVEURS
5.1. Introduction
5.2. Interface résolveur-client
5.2.1. Fonctions typiques
5.2.2. Alias
5.2.3. Fautes temporaires
5.3. Résolveurs – spécifications internes
5.3.1. Noyau de résolution minimal
5.3.2. Ressources
5.3.3. Algorithme
6. UN SCENARIO
6.1. Serveur de nom C.ISI.EDU
6.2. Exemple de requête standard
6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
6.2.6. QNAME=BRL.MIL, QTYPE=A
6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
6.3. Exemple de résolution
6.3.1. Résolution de MX pour ISI.EDU
6.3.2. Obtenir le nom d’hôte à partir de l’adresse 26.6.0.65
6.3.3. Obtenir l’adresse de l’hôte du domaine poneria.ISI.EDU
7. REFERENCES et BIBLIOGRAPHIE

1. STA TUT DE CE MEMO

Cette RFC est une introduction au système de noms de domaines (Domain Name System) DNS, et passe sous silence de nombreux détails qui pourront être trouvés dans une RFC complémentaire, « Domain Names – Implementation and Specification » [RFC-1035]. Cette dernière suppose que le lecteur est déjà familiarisé avec les concepts énoncés dans le présent.
Un sous-ensemble des fonctions DNS et des types de données associés constitue un protocole officiel. Le protocole officiel comprend la définition des requêtes standard et des réponses qui y sont faites ainsi que la plupart des formats de classes de données Internet (ex., adresses d’hôtes).

Cependant, le système de domaines est intentionnellement extensible. Les chercheurs proposent continuellement, implémentent et expérimentent de nouveaux types de données, types de requêtes, classes, fonctions, etc. De ce fait, alors que les constituants du protocole officiel sont supposés rester stables et pouvoir être utilisés en exploitation, des comportements expérimentaux pourront être observés au delà des limites de la définition officielle. Les RFC concernées mentionnent clairement les fonctions expérimentales, ou obsolètes, et l’information qui y est reportée doit toujours être considérée avec précaution.

2. INTRODUCTION

Cette RFC expose les styles admis pour les noms de domaines, leur utilisation dans le cadre de la messagerie par Internet et pour la recherche d’hôtes, et décrit les protocoles et serveurs utilisés pour les services réseaux liés aux noms de domaines.

2.1. Historique des noms de domaines
La motivation essentielle et impérieuse conduisant à la mise en œuvre du système de domaines a été la croissance exponentielle d’Internet :

• Au début, la transcription de noms d’hôtes en adresses Internet s’appuyait sur une table de correspondance maintenue par le Network Information Center (NIC) sous forme d’un unique fichier (HOSTS.TXT) lequel était transmis par FTP sur tous les hôtes [RFC-952, RFC-953]. La bande passante consommée par la distribution d’une remise à jour de cette base par cette méthode est proportionnelle au carré du nombre d’hôtes sur le réseau, et même lorsque plusieurs niveaux de retransmissions FTP étaient utilisés, le trafic sortant du serveur NIC restait considérable. La croissance explosive du nombre d’hôtes a fait rapidement exploser du même coup ce mécanisme.
• La population internaute changeait dans le même temps de nature. Les hôtes en temps partagé (mainframes) constituant l’ARPANET originel ont été remplacés par une architecture distribuée de stations connectées sur des réseaux et sous-réseaux locaux. Les organismes locaux ont commencé à administrer leurs propres noms et adresses, mais devaient attendre que le NIC reporte les changements dans le fichier HOSTS.TXT..

2.2. Objectifs de la conception du DNS
Les objectifs dans lesquels a été conçu le DNS ont influencé sa structure. Ces objectifs sont les suivants :

• Le but premier est la création d’un espace de noms conséquent utilisables pour référencer des ressources.Pour éviter tout problème de transcodage ou d’encodage, les noms peuvent ne mentionner ou inclure aucun des identificateurs réseau, adresses, chemins, ou information similaire communément utilisés pour l’implémentation technique.
• La taille énorme de la base de données et sa fréquence de mise à jour suggère une maintenance distribuée,avec cache local pour une performance accrue. Toute approche qui tentera d’obtenir une copie intégrale de la base de donnée sera de plus en plus coûteuse et difficile à traiter, et de ce fait devra être écartée. Les mêmes principes courent pour la constitution de l’espace des noms, et en particulier les mécanismes pour créer et supprimer des noms ; ceux-ci devront être également distribués.
• Lorsque l’on doit composer entre le coût technique d’acquisition d’une donnée, la fréquence des mises à jour,et la validité des caches, c’est toujours la source première de données qui contrôle les priorités à donner.
• Le coût important inhérant à l’implémentation d’un tel service suppose qu’il a une utilité générale, qui n’est pas restreinte à une application particulière. Les noms ainsi constitués devront pouvoir servir à identifier des hôtes, récupérer des courriers dans des boîtes aux lettres, et toute autre information non encore identifiée.Toute donnée associée à un nom sera typée, et les requêtes sur ce nom seront limitées à ce seul type.

2.3. Présupposés concernant l’utilisation
L’organisation du système de domaines découle de certains présupposés quant aux besoins et aux schémas d’exploitation de la communauté utilisatrice, et est conçue de sorte à éviter un grand nombre de problèmes classiques des grandes bases de données généralistes.
Les suppositions faites sont :
· La taille totale de la base de données sera initialement proportionnelle au nombre d’hôtes utilisant le système, mais pourra rapidement devenir proportionnelle au nombre d’utilisateurs utilisant ces machines dans la mesure où des informations telles que les boîtes aux lettres y seront intégrées.
· La fréquence de modification de la plupart des données de cette base sera assez basse (ex., les changements de boîtes aux lettres, les adresses d’hôtes), mais le système devra pouvoir traiter des sous ensembles de données nécessitant une période de remise à jour plus élevée (de l’ordre de quelques secondes à quelques minutes).
· Les limites administratives définies pour répartir la responsabilité de gestion de la base de données seront généralement associées à celles d’organisations possédant un ou plusieurs hôtes. Chaque organisation ayant la responsabilité d’un ensemble de domaines particulier
devra mettre en œuvre plusieurs serveurs de domaines redondants, soit sur l’hôte même de l’organisme, ou sur d’autres hôtes dont l’organisme s’occupe ou exploite.
· Les clients du système de domaines devront pouvoir choisir le serveur qu’ils décident d’utiliser parmi un ensemble de serveurs nommés et considérés comme sûrs avant d’accepter de s’appuyer sur un serveur hors de cet ensemble.

Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)
Les noms de domaines – Concepts et éléments de base (239 KO) (Cours PDF)