2. Noms

Nom de domaine (Domain name): La section 3.1 de [RFC1034] parle de "l'espace de noms de domaine" comme d'une structure arborescente. "Chaque nœud a un label, qui fait de zéro à 63 octets de longueur. ... Le nom de domaine d'un nœud est la liste des labels sur le chemin du nœud à la racine de l'arbre. ... Pour simplifier les implémentations, le nombre total d'octets qui représentent un nom de domaine (c'est-à-dire la somme de tous les octets de label et des longueurs de label) est limité à 255." Tout label dans un nom de domaine peut contenir n'importe quelle valeur d'octet.

Nom de domaine entièrement qualifié (Fully qualified domain name, FQDN): Ceci est souvent juste une façon claire de dire la même chose que "nom de domaine d'un nœud", comme indiqué ci-dessus. Cependant, le terme est ambigu. Strictement parlant, un nom de domaine entièrement qualifié inclurait chaque label, y compris le label final de longueur zéro de la racine: un tel nom serait écrit "www.example.net." (notez le point de fin). Mais parce que chaque nom partage finalement la racine commune, les noms sont souvent écrits relativement à la racine (comme "www.example.net") et sont toujours appelés "entièrement qualifiés". Ce terme est apparu pour la première fois dans [RFC819]. Dans ce document, les noms sont souvent écrits relativement à la racine.

Le besoin du terme "nom de domaine entièrement qualifié" vient de l'existence de noms de domaine partiellement qualifiés, qui sont des noms où certains des noms les plus à droite sont omis et ne sont compris que par le contexte.

Label: L'identifiant d'un nœud individuel dans la séquence de nœuds identifiés par un nom de domaine entièrement qualifié.

Nom d'hôte (Host name): Ce terme et son équivalent, "hostname", ont été largement utilisés mais ne sont pas définis dans [RFC1034], [RFC1035], [RFC1123] ou [RFC2181]. Le DNS a été initialement déployé dans l'environnement des tables d'hôtes comme indiqué dans [RFC952], et il est probable que le terme ait suivi de manière informelle de la définition là-bas. Au fil du temps, la définition semble avoir changé. "Nom d'hôte" est souvent censé être un nom de domaine qui suit les règles de la section 3.5 de [RFC1034], la "syntaxe de nom préférée". Notez que tout label dans un nom de domaine peut contenir n'importe quelle valeur d'octet; les noms d'hôtes sont généralement considérés comme des noms de domaine où chaque label suit les règles de la "syntaxe de nom préférée", avec l'amendement que les labels peuvent commencer par des chiffres ASCII (cet amendement provient de la section 2.1 de [RFC1123]).

Les gens utilisent aussi parfois le terme hostname pour faire référence uniquement au premier label d'un FQDN, comme "printer" dans "printer.admin.example.com". (Parfois, ceci est formalisé dans la configuration dans les systèmes d'exploitation.) De plus, les gens utilisent parfois ce terme pour décrire tout nom qui fait référence à une machine, et ceux-ci peuvent inclure des labels qui ne sont pas conformes à la "syntaxe de nom préférée".

TLD: Un domaine de premier niveau (Top-Level Domain), signifiant une zone qui est un niveau en dessous de la racine, comme "com" ou "jp". Il n'y a rien de spécial, du point de vue du DNS, concernant les TLD. La plupart d'entre eux sont également des zones centrées sur la délégation, et il existe des problèmes politiques importants concernant leur exploitation. Les TLD sont souvent divisés en sous-groupes tels que les domaines de premier niveau de code de pays (ccTLD), les domaines de premier niveau génériques (gTLD) et autres; la division est une question de politique et dépasse le cadre de ce document.

IDN: L'abréviation courante pour "Nom de domaine internationalisé" (Internationalized Domain Name). Le protocole IDNA est le mécanisme standard pour gérer les noms de domaine avec des caractères non-ASCII dans les applications DNS. La norme actuelle, normalement appelée "IDNA2008", est définie dans [RFC5890], [RFC5891], [RFC5892], [RFC5893] et [RFC5894]. Ces documents définissent de nombreux termes spécifiques à IDN tels que "label LDH", "A-label" et "U-label". [RFC6365] définit plus de termes qui se rapportent à l'internationalisation (dont certains se rapportent aux IDN), et [RFC6055] contient une discussion beaucoup plus étendue des IDN, y compris une nouvelle terminologie.

Sous-domaine (Subdomain): "Un domaine est un sous-domaine d'un autre domaine s'il est contenu dans ce domaine. Cette relation peut être testée en voyant si le nom du sous-domaine se termine par le nom du domaine contenant." (Cité de [RFC1034], section 3.1). Par exemple, dans le nom d'hôte "nnn.mmm.example.com", à la fois "mmm.example.com" et "nnn.mmm.example.com" sont des sous-domaines de "example.com".

Alias: Le propriétaire d'un enregistrement de ressource CNAME, ou un sous-domaine du propriétaire d'un enregistrement de ressource DNAME [RFC6672]. Voir aussi "nom canonique".

Nom canonique (Canonical name): Un enregistrement de ressource CNAME "identifie son nom de propriétaire comme un alias et spécifie le nom canonique correspondant dans la section RDATA du RR." (Cité de [RFC1034], section 3.6.2) Cette utilisation du mot "canonique" est liée au concept mathématique de "forme canonique".

CNAME: "Il est traditionnel de faire référence au propriétaire d'un enregistrement CNAME comme 'un CNAME'. C'est malheureux, car 'CNAME' est une abréviation de 'nom canonique', et le propriétaire d'un enregistrement CNAME est un alias, pas un nom canonique." (Cité de [RFC2181], section 10.1.1)

Suffixe public (Public suffix): "Un domaine qui est contrôlé par un registre public." (Cité de [RFC6265], section 5.3) Une définition commune de ce terme est un domaine sous lequel des sous-domaines peuvent être enregistrés et sur lequel les cookies HTTP ([RFC6265]) ne doivent pas être définis. Il n'y a aucune indication dans un nom de domaine s'il s'agit d'un suffixe public; cela ne peut être déterminé que par des moyens externes. En fait, à la fois un domaine et un sous-domaine de ce domaine peuvent être des suffixes publics. Au moment de la publication de ce document, le groupe de travail IETF DBOUND [DBOUND] traite des problèmes concernant les suffixes publics.

Il n'y a rien d'inhérent à un nom de domaine pour indiquer s'il s'agit d'un suffixe public. Une ressource pour identifier les suffixes publics est la liste des suffixes publics (PSL) maintenue par Mozilla (http://publicsuffix.org/).

Par exemple, au moment de la publication de ce document, le domaine "com.au" est répertorié comme un suffixe public dans la PSL. (Notez que cet exemple pourrait changer à l'avenir.)

Notez que le terme "suffixe public" est controversé dans la communauté DNS pour de nombreuses raisons et peut être considérablement modifié à l'avenir. Un exemple de la difficulté d'appeler un domaine un suffixe public est que cette désignation peut changer au fil du temps à mesure que la politique d'enregistrement pour la zone change, comme le cas du TLD "uk" au moment de la publication de ce document.