2. Introduction

2. Introduction

2.1. Overview (Vue d'ensemble)

L'objectif des noms de domaine (domain names) est de fournir un mécanisme pour nommer les ressources de manière à ce que les noms soient utilisables sur différents hôtes (hosts), réseaux (networks), familles de protocoles (protocol families), internets et organisations administratives (administrative organizations).

Du point de vue de l'utilisateur, les noms de domaine sont utiles comme arguments à un agent local (local agent), appelé résolveur (resolver), qui récupère les informations associées au nom de domaine. Ainsi, un utilisateur peut demander l'adresse d'hôte ou les informations de messagerie associées à un nom de domaine particulier. Pour permettre à l'utilisateur de demander un type particulier d'informations, un type de requête (query type) approprié est transmis au résolveur avec le nom de domaine. Pour l'utilisateur, l'arbre de domaine (domain tree) est un espace d'information unique (information space); le résolveur est responsable de cacher à l'utilisateur la distribution des données entre les serveurs de noms (name servers).

Du point de vue du résolveur, la base de données qui constitue l'espace de domaine (domain space) est distribuée entre divers serveurs de noms. Différentes parties de l'espace de domaine sont stockées dans différents serveurs de noms, bien qu'un élément de données particulier soit stocké de manière redondante (redundantly) dans deux serveurs de noms ou plus. Le résolveur commence avec la connaissance d'au moins un serveur de noms. Lorsque le résolveur traite une requête utilisateur, il demande les informations à un serveur de noms connu; en retour, le résolveur reçoit soit les informations souhaitées, soit une référence (referral) à un autre serveur de noms. En utilisant ces références, les résolveurs apprennent les identités et le contenu d'autres serveurs de noms. Les résolveurs sont responsables de gérer la distribution de l'espace de domaine et de gérer les effets de la défaillance d'un serveur de noms en consultant des bases de données redondantes dans d'autres serveurs.

Les serveurs de noms gèrent deux types de données. Le premier type de données est contenu dans des ensembles appelés zones (zones); chaque zone est la base de données complète pour un sous-arbre "élagué" (pruned) particulier de l'espace de domaine. Ces données sont appelées autoritatives (authoritative). Un serveur de noms vérifie périodiquement que ses zones sont à jour et, sinon, obtient une nouvelle copie des zones mises à jour à partir de fichiers maîtres (master files) stockés localement ou dans un autre serveur de noms. Le deuxième type de données est les données mises en cache (cached data) qui ont été acquises par un résolveur local. Ces données peuvent être incomplètes, mais améliorent les performances du processus de récupération lorsque des données non locales sont accédées de manière répétée. Les données mises en cache sont finalement supprimées par un mécanisme de délai d'expiration (timeout mechanism).

Cette structure fonctionnelle isole les problèmes d'interface utilisateur (user interface), de récupération après défaillance (failure recovery) et de distribution dans les résolveurs et isole les problèmes de mise à jour et de rafraîchissement de la base de données dans les serveurs de noms.

2.2. Common configurations (Configurations courantes)

Un hôte peut participer au système de noms de domaine de plusieurs manières, selon que l'hôte exécute des programmes qui récupèrent des informations du système de domaine, des serveurs de noms qui répondent aux requêtes d'autres hôtes, ou diverses combinaisons des deux fonctions. La configuration la plus simple, et peut-être la plus typique, est illustrée ci-dessous:

             Local Host                        |  Foreign
                                               |
+---------+               +----------+         |  +--------+
|         | user queries  |          |queries  |  |        |
|  User   |-------------->|          |---------|->|Foreign |
| Program |               | Resolver |         |  |  Name  |
|         |<--------------|          |<--------|--| Server |
|         | user responses|          |responses|  |        |
+---------+               +----------+         |  +--------+
                            |     A            |
            cache additions |     | references |
                            V     |            |
                          +----------+         |
                          |  cache   |         |
                          +----------+         |

Les programmes utilisateur interagissent avec l'espace de noms de domaine via des résolveurs; le format des requêtes utilisateur et des réponses utilisateur est spécifique à l'hôte et à son système d'exploitation. Les requêtes utilisateur seront généralement des appels système (operating system calls), et le résolveur et son cache feront partie du système d'exploitation de l'hôte. Les hôtes moins capables peuvent choisir d'implémenter le résolveur comme une sous-routine (subroutine) à lier avec chaque programme qui a besoin de ses services. Les résolveurs répondent aux requêtes utilisateur avec les informations qu'ils acquièrent via des requêtes aux serveurs de noms étrangers et au cache local.

Notez que le résolveur peut devoir effectuer plusieurs requêtes à plusieurs serveurs de noms étrangers différents pour répondre à une requête utilisateur particulière, et donc la résolution d'une requête utilisateur peut impliquer plusieurs accès réseau et une durée arbitraire. Les requêtes aux serveurs de noms étrangers et les réponses correspondantes ont un format standard décrit dans ce mémo, et peuvent être des datagrammes (datagrams).

Selon ses capacités, un serveur de noms peut être un programme autonome sur une machine dédiée ou un processus ou des processus sur un hôte à temps partagé important. Une configuration simple pourrait être:

             Local Host                        |  Foreign
                                               |
  +---------+                                  |
 /         /|                                  |
+---------+ |             +----------+         |  +--------+
|         | |             |          |responses|  |        |
|         | |             |   Name   |---------|->|Foreign |
|  Master |-------------->|  Server  |         |  |Resolver|
|  files  | |             |          |<--------|--|        |
|         |/              |          | queries |  +--------+
+---------+               +----------+         |

Ici, un serveur de noms primaire (primary name server) acquiert des informations sur une ou plusieurs zones en lisant les fichiers maîtres de son système de fichiers local, et répond aux requêtes concernant ces zones qui arrivent des résolveurs étrangers.

Le DNS exige que toutes les zones soient prises en charge de manière redondante par plus d'un serveur de noms. Les serveurs secondaires désignés (secondary servers) peuvent acquérir des zones et vérifier les mises à jour à partir du serveur primaire en utilisant le protocole de transfert de zone (zone transfer protocol) du DNS. Cette configuration est illustrée ci-dessous:

             Local Host                        |  Foreign
                                               |
  +---------+                                  |
 /         /|                                  |
+---------+ |             +----------+         |  +--------+
|         | |             |          |responses|  |        |
|         | |             |   Name   |---------|->|Foreign |
|  Master |-------------->|  Server  |         |  |Resolver|
|  files  | |             |          |<--------|--|        |
|         |/              |          | queries |  +--------+
+---------+               +----------+         |
                            A     |maintenance |  +--------+
                            |     +------------|->|        |
                            |      queries     |  |Foreign |
                            |                  |  |  Name  |
                            +------------------|--| Server |
                         maintenance responses |  +--------+

Dans cette configuration, le serveur de noms établit périodiquement un circuit virtuel (virtual circuit) vers un serveur de noms étranger pour acquérir une copie d'une zone ou pour vérifier qu'une copie existante n'a pas changé. Les messages envoyés pour ces activités de maintenance suivent la même forme que les requêtes et les réponses, mais les séquences de messages sont quelque peu différentes.

Le flux d'informations dans un hôte qui prend en charge tous les aspects du système de noms de domaine est illustré ci-dessous:

             Local Host                        |  Foreign
                                               |
+---------+               +----------+         |  +--------+
|         | user queries  |          |queries  |  |        |
|  User   |-------------->|          |---------|->|Foreign |
| Program |               | Resolver |         |  |  Name  |
|         |<--------------|          |<--------|--| Server |
|         | user responses|          |responses|  |        |
+---------+               +----------+         |  +--------+
                            |     A            |
            cache additions |     | references |
                            V     |            |
                          +----------+         |
                          |  Shared  |         |
                          | database |         |
                          +----------+         |
                            A     |            |
  +---------+     refreshes |     | references |
 /         /|               |     V            |
+---------+ |             +----------+         |  +--------+
|         | |             |          |responses|  |        |
|         | |             |   Name   |---------|->|Foreign |
|  Master |-------------->|  Server  |         |  |Resolver|
|  files  | |             |          |<--------|--|        |
|         |/              |          | queries |  +--------+
+---------+               +----------+         |
                            A     |maintenance |  +--------+
                            |     +------------|->|        |
                            |      queries     |  |Foreign |
                            |                  |  |  Name  |
                            +------------------|--| Server |
                         maintenance responses |  +--------+

La base de données partagée (shared database) contient les données de l'espace de domaine pour le serveur de noms local et le résolveur. Le contenu de la base de données partagée sera généralement un mélange de données autoritatives maintenues par les opérations de rafraîchissement périodiques du serveur de noms et de données mises en cache provenant de demandes de résolveur précédentes. La structure des données de domaine et la nécessité de synchronisation entre les serveurs de noms et les résolveurs impliquent les caractéristiques générales de cette base de données, mais le format réel dépend de l'implémenteur local.

Le flux d'informations peut également être adapté de sorte qu'un groupe d'hôtes agisse ensemble pour optimiser les activités. Parfois, cela est fait pour décharger les hôtes moins capables afin qu'ils n'aient pas à implémenter un résolveur complet. Cela peut être approprié pour les PC ou les hôtes qui souhaitent minimiser la quantité de nouveau code réseau requis. Ce schéma peut également permettre à un groupe d'hôtes de partager un petit nombre de caches plutôt que de maintenir un grand nombre de caches séparés, en partant du principe que les caches centralisés auront un taux de réussite (hit ratio) plus élevé. Dans les deux cas, les résolveurs sont remplacés par des résolveurs stub (stub resolvers) qui agissent comme des interfaces pour les résolveurs situés dans un serveur récursif (recursive server) dans un ou plusieurs serveurs de noms connus pour effectuer ce service:

               Local Hosts                     |  Foreign
                                               |
+---------+                                    |
|         | responses                          |
| Stub    |<--------------------+              |
| Resolver|                     |              |
|         |----------------+    |              |
+---------+ recursive      |    |              |
            queries        |    |              |
                           V    |              |
+---------+ recursive     +----------+         |  +--------+
|         | queries       |          |queries  |  |        |
| Stub    |-------------->| Recursive|---------|->|Foreign |
| Resolver|               | Server   |         |  |  Name  |
|         |<--------------|          |<--------|--| Server |
+---------+ responses     |          |responses|  |        |
                          +----------+         |  +--------+
                          |  Central |         |
                          |   cache  |         |
                          +----------+         |

Dans tous les cas, notez que les composants de domaine sont toujours répliqués pour la fiabilité chaque fois que possible.

2.3. Conventions

Le système de domaine a plusieurs conventions traitant de problèmes de bas niveau, mais fondamentaux. Bien que l'implémenteur soit libre de violer ces conventions DANS SON PROPRE SYSTÈME, il doit observer ces conventions dans TOUT comportement observé depuis d'autres hôtes.

2.3.1. Preferred name syntax (Syntaxe de nom préférée)

Les spécifications DNS tentent d'être aussi générales que possible dans les règles de construction des noms de domaine. L'idée est que le nom de tout objet existant peut être exprimé comme un nom de domaine avec des changements minimes.

Cependant, lors de l'attribution d'un nom de domaine à un objet, l'utilisateur prudent sélectionnera un nom qui satisfait à la fois les règles du système de domaine et toutes les règles existantes pour l'objet, que ces règles soient publiées ou implicites par les programmes existants.

Par exemple, lors de la dénomination d'un domaine de messagerie, l'utilisateur doit satisfaire à la fois les règles de ce mémo et celles de RFC-822. Lors de la création d'un nouveau nom d'hôte, les anciennes règles de HOSTS.TXT doivent être suivies. Cela évite les problèmes lorsque les anciens logiciels sont convertis pour utiliser les noms de domaine.

La syntaxe suivante entraînera moins de problèmes avec de nombreuses applications qui utilisent des noms de domaine (par exemple, mail, TELNET).

<domain> ::= <subdomain> | " "

<subdomain> ::= <label> | <subdomain> "." <label>

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig> ::= <letter> | <digit>

<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case

<digit> ::= any one of the ten digits 0 through 9

Notez que bien que les lettres majuscules et minuscules soient autorisées dans les noms de domaine, aucune importance n'est attachée à la casse. C'est-à-dire que deux noms avec la même orthographe mais une casse différente doivent être traités comme identiques.

Les étiquettes doivent suivre les règles des noms d'hôtes ARPANET. Elles doivent commencer par une lettre, se terminer par une lettre ou un chiffre, et n'avoir comme caractères intérieurs que des lettres, des chiffres et un trait d'union (hyphen). Il existe également certaines restrictions sur la longueur. Les étiquettes doivent comporter 63 caractères ou moins.

Par exemple, les chaînes suivantes identifient des hôtes dans Internet:

A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA

2.3.2. Data Transmission Order (Ordre de transmission des données)

L'ordre de transmission de l'en-tête et des données décrits dans ce document est résolu au niveau de l'octet (octet). Chaque fois qu'un diagramme montre un groupe d'octets, l'ordre de transmission de ces octets est l'ordre normal dans lequel ils sont lus en anglais. Par exemple, dans le diagramme suivant, les octets sont transmis dans l'ordre dans lequel ils sont numérotés.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       1       |       2       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       3       |       4       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       5       |       6       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chaque fois qu'un octet représente une quantité numérique, le bit le plus à gauche dans le diagramme est le bit d'ordre élevé ou le bit le plus significatif (most significant bit). C'est-à-dire que le bit étiqueté 0 est le bit le plus significatif. Par exemple, le diagramme suivant représente la valeur 170 (décimal).

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+

De même, chaque fois qu'un champ multi-octets représente une quantité numérique, le bit le plus à gauche du champ entier est le bit le plus significatif. Lorsqu'une quantité multi-octets est transmise, l'octet le plus significatif est transmis en premier.

2.3.3. Character Case (Casse des caractères)

Pour toutes les parties du DNS qui font partie du protocole officiel, toutes les comparaisons entre les chaînes de caractères (par exemple, étiquettes, noms de domaine, etc.) sont effectuées de manière insensible à la casse (case-insensitive). À l'heure actuelle, cette règle est en vigueur dans tout le système de domaine sans exception. Cependant, les ajouts futurs au-delà de l'utilisation actuelle peuvent avoir besoin d'utiliser les capacités complètes d'octets binaires dans les noms, donc les tentatives de stocker des noms de domaine en ASCII 7 bits ou l'utilisation d'octets spéciaux pour terminer les étiquettes, etc., doivent être évitées.

Lorsque des données entrent dans le système de domaine, leur casse d'origine doit être préservée dans la mesure du possible. Dans certaines circonstances, cela ne peut pas être fait. Par exemple, si deux RR sont stockés dans une base de données, l'un à x.y et l'autre à X.Y, ils sont en fait stockés au même endroit dans la base de données, et donc une seule casse serait préservée. La règle de base est que la casse ne peut être supprimée que lorsque les données sont utilisées pour définir la structure dans une base de données, et deux noms sont identiques lorsqu'ils sont comparés de manière insensible à la casse.

La perte de données sensibles à la casse doit être minimisée. Ainsi, bien que les données pour x.y et X.Y puissent toutes deux être stockées sous un seul emplacement x.y ou X.Y, les données pour a.x et B.X ne seraient jamais stockées sous A.x, A.X, b.x ou b.X. En général, cela préserve la casse de la première étiquette d'un nom de domaine, mais force la standardisation des étiquettes de nœuds intérieurs.

Les administrateurs système qui entrent des données dans la base de données de domaine doivent veiller à représenter les données qu'ils fournissent au système de domaine de manière cohérente en matière de casse si leur système est sensible à la casse. Le système de distribution de données dans le système de domaine garantira que les représentations cohérentes sont préservées.

2.3.4. Size limits (Limites de taille)

Divers objets et paramètres dans le DNS ont des limites de taille. Ils sont énumérés ci-dessous. Certains pourraient être facilement modifiés, d'autres sont plus fondamentaux.

Objet	Limite
labels (étiquettes)	63 octets ou moins
names (noms)	255 octets ou moins
TTL	valeurs positives d'un nombre signé de 32 bits
UDP messages (messages UDP)	512 octets ou moins