Exit Zen
1 ../../principles/naming.rst:7
English
Nommage et adressage
2 ../../principles/naming.rst:9
English
Les couches réseau et transport s'appuient sur des adresses qui sont codées sous forme de chaînes de bits de taille fixe. Une adresse de la couche réseau identifie de manière unique un hôte. Plusieurs entités de la couche transport peuvent utiliser le service de la même couche réseau. Par exemple, un protocole de transport fiable et un protocole de transport sans connexion peuvent coexister sur le même hôte. Dans ce cas, la couche réseau multiplexe les segments produits par ces deux protocoles. Ce multiplexage est généralement réalisé en plaçant dans l'en-tête du paquet réseau un champ qui indique quel protocole de transport doit traiter le segment. Étant donné qu'il existe peu de protocoles de transport différents, ce champ n'a pas besoin d'être long. Les numéros de port jouent un rôle similaire dans la couche transport puisqu'ils lui permettent de multiplexer les données de plusieurs processus d'application.
3 ../../principles/naming.rst:11
English
Alors que les adresses semblent intuitives pour les entités des couches réseau et transport, les humains préfèrent utiliser des noms lorsqu'ils interagissent avec les services réseau. Les noms peuvent être codés sous forme de chaîne de caractères et un service de mappage permet aux applications de faire correspondre un nom à l'adresse correspondante. L'utilisation des noms est plus conviviale pour les humains, mais elle fournit également un niveau d'indirection qui est très utile dans de nombreuses situations.
5 ../../principles/naming.rst:15
English
Étant donné que les noms sont à plus haut niveau que les adresses, ils permettent (à la fois dans l'exemple de programmation au-dessus, et sur internet) de traiter les adresses comme de simples identifiants techniques qui peuvent changer à volonté. Seuls les noms restent stables.
6 ../../principles/naming.rst:19
English
La première solution permettant aux applications d'utiliser des noms était le fichier :term:`hosts.txt`. Ce fichier est similaire à la table des symboles que l'on trouve dans un code compilé. Il contient la correspondance entre le nom de chaque hôte Internet et son adresse associée [#fhosts]_. Il était maintenu par SRI International qui coordonnait le Network Information Center (NIC). Lorsqu'un nouvel hôte était connecté au réseau, l'administrateur système devait enregistrer son nom et son adresse auprès du NIC. Le NIC mettait à jour le fichier :term:`hosts.txt` sur son serveur. Tous les hôtes Internet récupéraient régulièrement le fichier :term:`hosts.txt` mis à jour sur le serveur SRI_. Ce fichier était stocké à un emplacement bien connu sur chaque hôte Internet (voir :rfc:`952`) et les applications en réseau pouvaient l'utiliser pour trouver l'adresse correspondant à un nom.
7 ../../principles/naming.rst:21
English
Un fichier :term:`hosts.txt` peut être utilisé lorsqu'il y a jusqu'à quelques centaines d'hôtes sur le réseau. Cependant, il n'est clairement pas adapté à un réseau contenant des milliers ou des millions d'hôtes. Un problème clé dans un grand réseau est de définir un schéma de nommage approprié. L'ARPANet utilisait initialement un espace de nommage plat, c'est-à-dire que chaque hôte se voyait attribuer un nom unique. Pour limiter les collisions entre les noms, ces noms contenaient généralement le nom de l'institution et un suffixe permettant d'identifier l'hôte à l'intérieur de l'institution (une sorte de schéma de nommage hiérarchique du pauvre). Sur ARPANet, quelques institutions avaient plusieurs hôtes connectés au réseau.
8 ../../principles/naming.rst:23
English
Cependant, les limites d'un schéma de nommage plat sont apparues clairement avant la fin de l'ARPANet et :rfc:`819` a proposé un schéma de nommage hiérarchique. Alors que la norme :rfc:`819` envisageait la possibilité d'organiser les noms sous la forme d'un graphe dirigé, Internet a opté pour une structure arborescente capable de contenir tous les noms. Dans cette arborescence, les domaines de premier niveau sont ceux qui sont directement rattachés à la racine. Le premier domaine de premier niveau était `.arpa` [#fdnstimeline]_. Ce nom de premier niveau a été initialement ajouté comme suffixe aux noms des hôtes attachés à l'ARPANet et listés dans le fichier `hosts.txt`. En 1984, les noms de domaine génériques de premier niveau `.gov`, `.edu`, `.com`, `.mil` et `.org` ont été ajoutés. La norme :rfc:`1032` proposait l'utilisation des codes pays à deux lettres :term:`ISO-3166` comme noms de domaine de premier niveau. Puisque :term:`ISO-3166` définit un code de deux lettres pour chaque pays reconnu par les Nations Unies, cela permettait à tous les pays d'avoir automatiquement un domaine de premier niveau. Ces domaines incluent `.be` pour la Belgique, `.fr` pour la France, `.us` pour les États-Unis, `.ie` pour l'Irlande ou `.tv` pour Tuvalu, un groupe de petites îles du Pacifique ou `.tm` pour le Turkménistan. L'ensemble des noms de domaine de premier niveau est géré par l'Internet Corporation for Assigned Names and Numbers (:term:`ICANN`). :term:`ICANN` ajoute des domaines de premier niveau génériques qui ne sont pas liés à un pays et le domaine de premier niveau `.cat` a été enregistré pour la langue catalane. Des discussions sont en cours au sein de :term:`ICANN` pour augmenter le nombre de domaines de premier niveau.
9 ../../principles/naming.rst:25
English
Chaque domaine de premier niveau est géré par une organisation qui décide comment les noms de sous-domaines peuvent être enregistrés. La plupart des noms de domaine de premier niveau utilisent un système de premier arrivé, premier servi, et permettent à quiconque d'enregistrer des noms de domaine, mais il existe quelques exceptions. Par exemple, `.gov` est réservé au gouvernement américain, `.int` est réservé aux organisations internationales et les noms dans le `.ca` sont principalement `réservés <http://en.wikipedia.org/wiki/.ca>`_ aux entreprises ou aux utilisateurs qui sont présents au Canada.
10 ../../principles/naming.rst:54
English
La syntaxe des noms de domaine a été définie plus précisément dans :rfc:`1035`. Ce document recommande la :term:`BNF` suivante pour les noms de domaine pleinement qualifiés (les noms de domaine eux-mêmes ont une syntaxe beaucoup plus riche).
11 ../../principles/naming.rst:59
English
BNF du nom d'hôte pleinement qualifié
12 ../../principles/naming.rst:73
English
Cette grammaire spécifie qu'un nom d'hôte est une liste ordonnée d'étiquettes séparées par le caractère point (`.`). Chaque étiquette peut contenir des lettres, des chiffres et le caractère tiret (`-`) [#fidn]_. Les noms de domaine entièrement qualifiés sont lus de gauche à droite. Le premier label est un nom d'hôte ou un nom de domaine, suivi de la hiérarchie des domaines et se terminant par la racine implicitement à droite. Le nom de domaine de premier niveau doit être l'un des TLD enregistrés [#ftld]_. Par exemple, dans la figure ci-dessus, `www.computer-networking.info` correspond à un hôte nommé `www` dans le domaine `computer-networking` qui appartient au domaine de premier niveau `info`.
13 ../../principles/naming.rst:75
English
Il existe des caractères similaires visuellement qui ont des character codes différents
14 ../../principles/naming.rst:77
English
Le système de noms de domaine a été créé à une époque où Internet était principalement utilisé en Amérique du Nord. La conception initiale supposait que tous les noms de domaine seraient composés de lettres et de chiffres :rfc:`1035`. Lorsque l'utilisation d'Internet s'est développée dans d'autres parties du monde, il est devenu important de prendre en charge les caractères non ASCII. Pour cela, des extensions ont été proposées au système de noms de domaine :rfc:`3490`. En résumé, la solution utilisée pour prendre en charge les noms de domaine internationalisés fonctionne comme suit. Tout d'abord, il est possible d'utiliser la plupart des caractères Unicode pour coder les noms de domaine et les noms d'hôte, à quelques exceptions près (par exemple, le caractère point ne peut pas faire partie d'un nom puisqu'il est utilisé comme séparateur). Une fois qu'un nom de domaine a été encodé comme une série de caractères Unicode, il est ensuite converti en une chaîne de caractères qui contient le préfixe ``xn--`` et une séquence de caractères ASCII. Vous trouverez plus de détails sur ces algorithmes dans :rfc:`3490` et :rfc:`3492`.
16 ../../principles/naming.rst:82
English
Ce système de dénomination hiérarchique est un élément clé du système de noms de domaine (DNS). Le DNS est une base de données distribuée qui contient les correspondances entre les noms de domaine entièrement qualifiés et les adresses. Le DNS utilise le modèle client-serveur. Les clients sont des hôtes ou des applications qui doivent récupérer la correspondance pour un nom donné. Chaque :term:`nameserver` stocke une partie de la base de données distribuée et répond aux requêtes envoyées par les clients. Il y a au moins un :term:`nameserver` qui est responsable de chaque domaine. Dans la figure ci-dessous, les domaines sont représentés par des cercles et il y a trois hôtes dans le domaine `dom` (`h1`, `h2` et `h3`) et trois hôtes dans le domaine `a.sdom1.dom`. Comme le montre la figure ci-dessous, un sous-domaine peut contenir à la fois des noms d'hôtes et des sous-domaines.
17 ../../principles/naming.rst:107
English
Un :term:`nameserver` qui est responsable du domaine `dom` peut directement répondre aux requêtes suivantes :
18 ../../principles/naming.rst:109
English
l'adresse de tout hôte résidant directement dans le domaine `dom` (par exemple `h2.dom` dans la figure ci-dessus)
19 ../../principles/naming.rst:110
English
le ou les serveurs de noms qui sont responsables de tout sous-domaine direct du domaine `dom` (c'est-à-dire `sdom1.dom` et `sdom2.dom` dans la figure ci-dessus, mais pas `z.sdom1.dom`)
20 ../../principles/naming.rst:112
English
Pour récupérer le mappage de l'hôte `h2.dom`, un client envoie sa requête au nameserver qui est responsable du domaine `.dom`. Le nameserver répond directement à la requête. Pour récupérer un mappage pour `h3.a.sdom1.dom`, un client DNS envoie d'abord une requête au nameserver qui est responsable du domaine `.dom`. Ce nameserver renvoie le nameserver responsable du domaine `sdom1.dom`. Ce nameserver peut maintenant être contacté pour obtenir le nameserver responsable du domaine `a.sdom1.dom`. Ce nameserver peut être contacté pour récupérer le mapping du nom `h3.a.sdom1.dom`. Grâce à cette structure, il est possible pour un client DNS d'obtenir le mappage de n'importe quel hôte à l'intérieur du domaine `.dom` ou de l'un de ses sous-domaines. Pour garantir que tout client DNS sera en mesure de résoudre tout nom de domaine pleinement qualifié, il existe des nameservers spéciaux qui sont responsables de la racine de la hiérarchie des noms de domaine. Ces nameservers sont appelés :term:`root nameserver`.
21 ../../principles/naming.rst:114
English
Chaque root nameserver maintient la liste [#froot]_ de tous les nameservers qui sont responsables de chacun des noms de domaine de premier niveau et de leurs adresses [#frootv6]_. Tous les root nameservers coopèrent et fournissent les mêmes réponses. En interrogeant l'un des root nameserver, un client DNS peut obtenir le nameserver responsable de n'importe quel nom de domaine de premier niveau. À partir de ce nameserver, il est possible de résoudre n'importe quel nom de domaine.
22 ../../principles/naming.rst:117
English
Pour pouvoir contacter les root nameserver, chaque client DNS doit connaître leurs adresses. Cela implique que les clients DNS doivent maintenir une liste à jour des adresses des root nameserver. Sans cette liste, il est impossible de contacter les root nameserver. Forcer tous les hôtes Internet à maintenir la version la plus récente de cette liste serait difficile d'un point de vue opérationnel. Pour résoudre ce problème, les concepteurs du DNS ont introduit un type spécial de serveur DNS : les résolveurs DNS. Un :term:`résolveur` est un serveur qui fournit le service de résolution de noms pour un ensemble de clients. Un réseau contient généralement quelques résolveurs. Chaque hôte de ces réseaux est configuré pour envoyer toutes ses requêtes DNS via l'un de ses résolveurs locaux. Ces requêtes sont appelées "requêtes récursives" car le :term:`resolver` doit envoyer des requêtes de manière récursive à travers la hiérarchie des nameservers pour obtenir la "réponse".