Aller au contenu principal

3. ESPACE DE NOMS DE DOMAINE et ENREGISTREMENTS DE RESSOURCES (DOMAIN NAME SPACE and RESOURCE RECORDS)

3.1. Spécifications et terminologie de l'espace de noms (Name space specifications and terminology)​

L'espace de noms de domaine est une structure arborescente. Chaque nœud et feuille de l'arbre correspond à un ensemble de ressources (qui peut être vide). Le système de domaine ne fait aucune distinction entre les utilisations des nœuds internes et des feuilles, et ce mémo utilise le terme « nœud (node) » pour désigner les deux.

Chaque nœud a une étiquette (label), dont la longueur varie de zéro à 63 octets. Les nœuds frères ne peuvent pas avoir la même étiquette, bien que la même étiquette puisse être utilisée pour des nœuds qui ne sont pas frères. Une étiquette est réservée, et c'est l'étiquette nulle (c'est-à-dire de longueur zéro) utilisée pour la racine.

Le nom de domaine d'un nœud est la liste des étiquettes sur le chemin du nœud à la racine de l'arbre. Par convention, les étiquettes qui composent un nom de domaine sont imprimées ou lues de gauche à droite, du plus spécifique (le plus bas, le plus éloigné de la racine) au moins spécifique (le plus haut, le plus proche de la racine).

Représentation interne (Internal representation)​

En interne, les programmes qui manipulent les noms de domaine doivent les représenter comme des séquences d'étiquettes, où chaque étiquette est un octet de longueur suivi d'une chaîne d'octets. Étant donné que tous les noms de domaine se terminent à la racine, qui a une chaîne nulle comme étiquette, ces représentations internes peuvent utiliser un octet de longueur de zéro pour terminer un nom de domaine.

Sensibilité à la casse (Case sensitivity)​

Par convention, les noms de domaine peuvent être stockés avec une casse arbitraire, mais les comparaisons de noms de domaine pour toutes les fonctions de domaine actuelles sont effectuées de manière insensible à la casse, en supposant un jeu de caractères ASCII et un bit d'ordre supérieur zéro. Cela signifie que vous êtes libre de créer un nœud avec l'étiquette "A" ou un nœud avec l'étiquette "a", mais pas les deux en tant que frères ; vous pourriez vous référer à l'un ou l'autre en utilisant "a" ou "A". Lorsque vous recevez un nom de domaine ou une étiquette, vous devez préserver sa casse. La raison de ce choix est que nous pourrions un jour avoir besoin d'ajouter des noms de domaine binaires complets pour de nouveaux services ; les services existants ne seraient pas modifiés.

Noms absolus et relatifs (Absolute and relative names)​

Lorsqu'un utilisateur a besoin de taper un nom de domaine, la longueur de chaque étiquette est omise et les étiquettes sont séparées par des points ("."). Étant donné qu'un nom de domaine complet se termine par l'étiquette racine, cela conduit à une forme imprimée qui se termine par un point. Nous utilisons cette propriété pour distinguer entre :

  • Noms absolus (Absolute names) : Une chaîne de caractères qui représente un nom de domaine complet (souvent appelé « absolu »). Par exemple, "poneria.ISI.EDU."

  • Noms relatifs (Relative names) : Une chaîne de caractères qui représente les étiquettes de départ d'un nom de domaine qui est incomplet, et devrait être complété par un logiciel local utilisant la connaissance du domaine local (souvent appelé « relatif »). Par exemple, "poneria" utilisé dans le domaine ISI.EDU.

Les noms relatifs sont pris soit par rapport à une origine bien connue, soit par rapport à une liste de domaines utilisée comme liste de recherche. Les noms relatifs apparaissent principalement à l'interface utilisateur, où leur interprétation varie d'une implémentation à l'autre, et dans les fichiers maîtres, où ils sont relatifs à un seul nom de domaine d'origine. L'interprétation la plus courante utilise la racine "." soit comme origine unique, soit comme l'un des membres de la liste de recherche, de sorte qu'un nom relatif à plusieurs étiquettes est souvent un nom où le point final a été omis pour économiser la frappe.

Limitations de longueur (Length limitations)​

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 d'étiquette et des longueurs d'étiquette) est limité à 255.

Relations entre domaine et sous-domaine (Domain and subdomain relationships)​

Un domaine est identifié par un nom de domaine et se compose de la partie de l'espace de noms de domaine qui est au niveau ou en dessous du nom de domaine qui spécifie le domaine. Un domaine est un sous-domaine d'un autre domaine s'il est contenu dans ce domaine. Cette relation peut être testée en vérifiant si le nom du sous-domaine se termine par le nom du domaine contenant. Par exemple, A.B.C.D est un sous-domaine de B.C.D, C.D, D et " ".

3.2. Directives administratives sur l'utilisation (Administrative guidelines on use)​

En tant que question de politique, les spécifications techniques du DNS n'imposent pas de structure arborescente particulière ou de règles pour la sélection des étiquettes ; son objectif est d'être aussi général que possible, afin qu'il puisse être utilisé pour construire des applications arbitraires. En particulier, le système a été conçu de sorte que l'espace de noms n'ait pas à être organisé selon les lignes des limites réseau, des serveurs de noms, etc. La raison de cela n'est pas que l'espace de noms ne devrait pas avoir de sémantique implicite, mais plutôt que le choix de la sémantique implicite devrait être laissé ouvert pour être utilisé pour le problème à portée de main, et que différentes parties de l'arbre peuvent avoir différentes sémantiques implicites. Par exemple, le domaine IN-ADDR.ARPA est organisé et distribué par réseau et adresse d'hôte car son rôle est de traduire des numéros de réseau ou d'hôte en noms ; les domaines NetBIOS [RFC-1001, RFC-1002] sont plats car cela est approprié pour cette application.

Cependant, il existe des directives qui s'appliquent aux parties « normales » de l'espace de noms utilisées pour les hôtes, les boîtes aux lettres, etc., qui rendront l'espace de noms plus uniforme, permettront la croissance et minimiseront les problèmes lors de la conversion du logiciel de l'ancienne table d'hôtes. Les décisions politiques sur les niveaux supérieurs de l'arbre ont été prises dans RFC-920. La politique actuelle pour les niveaux supérieurs est discutée dans [RFC-1032]. Les problèmes de conversion MILNET sont couverts dans [RFC-1031].

Les domaines inférieurs qui seront éventuellement divisés en plusieurs zones devraient fournir une ramification au sommet du domaine afin que la décomposition éventuelle puisse être effectuée sans renommage. Les étiquettes de nœud qui utilisent des caractères spéciaux, des chiffres en tête, etc., sont susceptibles de casser les anciens logiciels qui dépendent de choix plus restrictifs.

3.3. Directives techniques sur l'utilisation (Technical guidelines on use)​

Avant que le DNS puisse être utilisé pour contenir des informations de nommage pour un certain type d'objet, deux besoins doivent être satisfaits :

  • Une convention pour le mappage entre les noms d'objets et les noms de domaine. Cela décrit comment les informations sur un objet sont accessibles.

  • Les types de RR et les formats de données pour décrire l'objet.

Ces règles peuvent être assez simples ou assez complexes. Très souvent, le concepteur doit prendre en compte les formats existants et planifier la compatibilité ascendante pour l'utilisation existante. Plusieurs mappages ou niveaux de mappage peuvent être nécessaires.

Mappage de nom d'hôte (Host name mapping)​

Pour les hôtes, le mappage dépend de la syntaxe existante pour les noms d'hôtes qui est un sous-ensemble de la représentation textuelle habituelle pour les noms de domaine, ainsi que des formats RR pour décrire les adresses d'hôte, etc. Parce que nous avons besoin d'un mappage inverse fiable de l'adresse au nom d'hôte, un mappage spécial pour les adresses dans le domaine IN-ADDR.ARPA est également défini.

Mappage de boîte aux lettres (Mailbox mapping)​

Pour les boîtes aux lettres, le mappage est légèrement plus complexe. L'adresse mail habituelle <local-part>@<mail-domain> est mappée en un nom de domaine en convertissant <local-part> en une seule étiquette (indépendamment des points qu'elle contient), en convertissant <mail-domain> en un nom de domaine en utilisant le format de texte habituel pour les noms de domaine (les points indiquent les ruptures d'étiquette), et en concaténant les deux pour former un seul nom de domaine. Ainsi, la boîte aux lettres [email protected] est représentée comme un nom de domaine par HOSTMASTER.SRI-NIC.ARPA. Une appréciation des raisons derrière cette conception doit également prendre en compte le schéma pour les échanges de courrier [RFC-974].

L'utilisateur typique n'est pas concerné par la définition de ces règles, mais devrait comprendre qu'elles sont généralement le résultat de nombreux compromis entre les désirs de compatibilité ascendante avec l'ancienne utilisation, les interactions entre différentes définitions d'objets, et l'envie inévitable d'ajouter de nouvelles fonctionnalités lors de la définition des règles. La façon dont le DNS est utilisé pour supporter un objet est souvent plus cruciale que les restrictions inhérentes au DNS.

3.4. Exemple d'espace de noms (Example name space)​

La figure suivante montre une partie de l'espace de noms de domaine actuel, et est utilisée dans de nombreux exemples de ce RFC. Notez que l'arbre est un très petit sous-ensemble de l'espace de noms réel.

                               |
                               |
         +---------------------+------------------+
         |                     |                  |
        MIL                   EDU                ARPA
         |                     |                  |
         |                     |                  |
   +-----+-----+               |     +------+-----+-----+
   |     |     |               |     |      |           |
  BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
                               |
   +--------+------------------+---------------+--------+
   |        |                  |               |        |
  UCI      MIT                 |              UDEL     YALE
            |                 ISI
            |                  |
        +---+---+              |
        |       |              |
       LCS  ACHILLES  +--+-----+-----+--------+
        |             |  |     |     |        |
        XX            A  C   VAXA  VENERA Mockapetris

Dans cet exemple, le domaine racine a trois sous-domaines immédiats : MIL, EDU et ARPA. Le domaine LCS.MIT.EDU a un sous-domaine immédiat nommé XX.LCS.MIT.EDU. Toutes les feuilles sont également des domaines.

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

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 puisse être exprimé comme un nom de domaine avec des modifications minimales. 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 du nommage 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 pour 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, courrier, 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> ::= l'un des 52 caractères alphabétiques A à Z en
             majuscules et a à z en minuscules

<digit> ::= l'un des dix chiffres 0 à 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 des traits d'union. Il y a également des restrictions sur la longueur. Les étiquettes doivent contenir 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

3.6. Enregistrements de ressources (Resource Records)​

Un nom de domaine identifie un nœud. Chaque nœud a un ensemble d'informations de ressources, qui peut être vide. L'ensemble d'informations de ressources associées à un nom particulier est composé d'enregistrements de ressources (RRs) séparés. L'ordre des RRs dans un ensemble n'est pas significatif et n'a pas besoin d'être préservé par les serveurs de noms, les résolveurs ou d'autres parties du DNS.

Lorsque nous parlons d'un RR spécifique, nous supposons qu'il a ce qui suit :

owner (propriétaire)​

Qui est le nom de domaine où le RR est trouvé.

type (type)​

Qui est une valeur codée sur 16 bits qui spécifie le type de la ressource dans cet enregistrement de ressource. Les types se réfèrent à des ressources abstraites.

Ce mémo utilise les types suivants :

  • A : une adresse d'hôte
  • CNAME : identifie le nom canonique d'un alias
  • HINFO : identifie le CPU et l'OS utilisés par un hôte
  • MX : identifie un échange de courrier pour le domaine. Voir [RFC-974] pour les détails.
  • NS : le serveur de noms autoritatif pour le domaine
  • PTR : un pointeur vers une autre partie de l'espace de noms de domaine
  • SOA : identifie le début d'une zone d'autorité

class (classe)​

Qui est une valeur codée sur 16 bits qui identifie une famille de protocoles ou une instance d'un protocole.

Ce mémo utilise les classes suivantes :

  • IN : le système Internet
  • CH : le système Chaos

TTL​

Qui est le temps de vie du RR. Ce champ est un entier 32 bits en unités de secondes, et est principalement utilisé par les résolveurs lorsqu'ils mettent en cache les RRs. Le TTL décrit combien de temps un RR peut être mis en cache avant qu'il ne doive être supprimé.

RDATA​

Qui sont les données dépendantes du type et parfois de la classe qui décrivent la ressource :

  • A : Pour la classe IN, une adresse IP 32 bits. Pour la classe CH, un nom de domaine suivi d'une adresse Chaos octale 16 bits.
  • CNAME : un nom de domaine.
  • MX : une valeur de préférence 16 bits (inférieur est meilleur) suivie d'un nom d'hôte disposé à agir comme échange de courrier pour le domaine propriétaire.
  • NS : un nom d'hôte.
  • PTR : un nom de domaine.
  • SOA : plusieurs champs.

Considérations sur la structure des RR (RR structure considerations)​

Le nom du propriétaire est souvent implicite, plutôt que de former une partie intégrante du RR. Par exemple, de nombreux serveurs de noms forment en interne des structures d'arbre ou de hachage pour l'espace de noms, et chaînent les RRs à partir des nœuds. Les parties RR restantes sont l'en-tête fixe (type, classe, TTL) qui est cohérent pour tous les RRs, et une partie variable (RDATA) qui correspond aux besoins de la ressource décrite.

La signification du champ TTL est une limite de temps sur la durée pendant laquelle un RR peut être conservé dans un cache. Cette limite ne s'applique pas aux données autoritatives dans les zones ; elle est également expirée, mais par les politiques de rafraîchissement pour la zone. Le TTL est attribué par l'administrateur de la zone d'où proviennent les données. Bien que des TTLs courts puissent être utilisés pour minimiser la mise en cache, et qu'un TTL de zéro interdise la mise en cache, les réalités des performances Internet suggèrent que ces temps devraient être de l'ordre de jours pour l'hôte typique. Si un changement peut être anticipé, le TTL peut être réduit avant le changement pour minimiser l'incohérence pendant le changement, puis augmenté à sa valeur précédente après le changement.

Les données dans la section RDATA des RRs sont transportées comme une combinaison de chaînes binaires et de noms de domaine. Les noms de domaine sont fréquemment utilisés comme « pointeurs » vers d'autres données dans le DNS.

3.6.1. Expression textuelle des RRs (Textual expression of RRs)​

Les RRs sont représentés sous forme binaire dans les paquets du protocole DNS, et sont généralement représentés sous une forme hautement codée lorsqu'ils sont stockés dans un serveur de noms ou un résolveur. Dans ce mémo, nous adoptons un style similaire à celui utilisé dans les fichiers maîtres afin de montrer le contenu des RRs. Dans ce format, la plupart des RRs sont affichés sur une seule ligne, bien que les lignes de continuation soient possibles en utilisant des parenthèses.

Le début de la ligne donne le propriétaire du RR. Si une ligne commence par un espace, alors le propriétaire est supposé être le même que celui du RR précédent. Des lignes vides sont souvent incluses pour la lisibilité.

Après le propriétaire, nous listons le TTL, le type et la classe du RR. La classe et le type utilisent les mnémoniques définis ci-dessus, et le TTL est un entier avant le champ de type. Afin d'éviter l'ambiguïté lors de l'analyse, les mnémoniques de type et de classe sont disjoints, les TTLs sont des entiers, et le mnémonique de type est toujours le dernier. La classe IN et les valeurs TTL sont souvent omises des exemples dans l'intérêt de la clarté.

La section de données de ressource ou RDATA du RR est donnée en utilisant la connaissance de la représentation typique des données.

Par exemple, nous pourrions montrer les RRs transportés dans un message comme :

ISI.EDU.        MX      10 VENERA.ISI.EDU.
                MX      10 VAXA.ISI.EDU.
VENERA.ISI.EDU. A       128.9.0.32
                A       10.1.0.52
VAXA.ISI.EDU.   A       10.2.0.27
                A       128.9.0.33

Les RRs MX ont une section RDATA qui se compose d'un nombre 16 bits suivi d'un nom de domaine. Les RRs d'adresse utilisent un format d'adresse IP standard pour contenir une adresse Internet 32 bits.

Cet exemple montre six RRs, avec deux RRs à chacun des trois noms de domaine.

De même, nous pourrions voir :

XX.LCS.MIT.EDU. IN      A       10.0.0.44
                CH      A       MIT.EDU. 2420

Cet exemple montre deux adresses pour XX.LCS.MIT.EDU, chacune d'une classe différente.

3.6.2. Alias et noms canoniques (Aliases and canonical names)​

Dans les systèmes existants, les hôtes et autres ressources ont souvent plusieurs noms qui identifient la même ressource. Par exemple, les noms C.ISI.EDU et USC-ISIC.ARPA identifient tous deux le même hôte. De même, dans le cas des boîtes aux lettres, de nombreuses organisations fournissent de nombreux noms qui vont en fait à la même boîte aux lettres ; par exemple [email protected], [email protected] et [email protected] vont tous à la même boîte aux lettres (bien que le mécanisme derrière cela soit quelque peu compliqué).

La plupart de ces systèmes ont une notion qu'un des ensembles équivalents de noms est le nom canonique ou principal et tous les autres sont des alias.

Enregistrements CNAME (CNAME records)​

Le système de domaine fournit une telle fonctionnalité en utilisant l'enregistrement de nom canonique (CNAME) RR. Un RR CNAME identifie son nom de propriétaire comme un alias, et spécifie le nom canonique correspondant dans la section RDATA du RR. Si un RR CNAME est présent à un nœud, aucune autre donnée ne devrait être présente ; cela garantit que les données pour un nom canonique et ses alias ne peuvent pas être différentes. Cette règle garantit également qu'un CNAME mis en cache peut être utilisé sans vérifier avec un serveur autoritatif pour d'autres types de RR.

Les RRs CNAME provoquent une action spéciale dans le logiciel DNS. Lorsqu'un serveur de noms ne parvient pas à trouver un RR désiré dans l'ensemble de ressources associé au nom de domaine, il vérifie si l'ensemble de ressources se compose d'un enregistrement CNAME avec une classe correspondante. Si tel est le cas, le serveur de noms inclut l'enregistrement CNAME dans la réponse et redémarre la requête au nom de domaine spécifié dans le champ de données de l'enregistrement CNAME. La seule exception à cette règle est que les requêtes qui correspondent au type CNAME ne sont pas redémarrées.

Par exemple, supposons qu'un serveur de noms traitait une requête pour USC-ISIC.ARPA, demandant des informations de type A, et avait les enregistrements de ressources suivants :

USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU

C.ISI.EDU       IN      A       10.0.0.52

Ces deux RRs seraient retournés dans la réponse à la requête de type A, tandis qu'une requête de type CNAME ou * devrait retourner uniquement le CNAME.

Les noms de domaine dans les RRs qui pointent vers un autre nom devraient toujours pointer vers le nom principal et non l'alias. Cela évite les indirections supplémentaires lors de l'accès aux informations. Par exemple, le RR d'adresse vers nom pour l'hôte ci-dessus devrait être :

52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

plutôt que de pointer vers USC-ISIC.ARPA. Bien sûr, selon le principe de robustesse, le logiciel de domaine ne devrait pas échouer lorsqu'il est présenté avec des chaînes ou des boucles CNAME ; les chaînes CNAME devraient être suivies et les boucles CNAME signalées comme une erreur.

3.7. Requêtes (Queries)​

Les requêtes sont des messages qui peuvent être envoyés à un serveur de noms pour provoquer une réponse. Dans Internet, les requêtes sont transportées dans des datagrammes UDP ou sur des connexions TCP. La réponse du serveur de noms répond soit à la question posée dans la requête, renvoie le demandeur à un autre ensemble de serveurs de noms, soit signale une condition d'erreur.

En général, l'utilisateur ne génère pas de requêtes directement, mais fait plutôt une demande à un résolveur qui à son tour envoie une ou plusieurs requêtes aux serveurs de noms et traite les conditions d'erreur et les renvois qui peuvent en résulter. Bien sûr, les questions possibles qui peuvent être posées dans une requête façonnent le type de service qu'un résolveur peut fournir.

Format de message (Message format)​

Les requêtes et réponses DNS sont transportées dans un format de message standard. Le format de message a un en-tête contenant un certain nombre de champs fixes qui sont toujours présents, et quatre sections qui transportent les paramètres de requête et les RRs.

Le champ le plus important dans l'en-tête est un champ de quatre bits appelé opcode qui sépare différentes requêtes. Parmi les 16 valeurs possibles, une (requête standard) fait partie du protocole officiel, deux (requête inverse et requête de statut) sont des options, une (complétion) est obsolète, et le reste est non attribué.

Les quatre sections sont :

  • Question : Transporte le nom de requête et d'autres paramètres de requête.
  • Answer (Réponse) : Transporte les RRs qui répondent directement à la requête.
  • Authority (Autorité) : Transporte les RRs qui décrivent d'autres serveurs autoritatifs. Peut optionnellement transporter le RR SOA pour les données autoritatives dans la section de réponse.
  • Additional (Additionnel) : Transporte les RRs qui peuvent être utiles pour utiliser les RRs dans les autres sections.

Notez que le contenu, mais pas le format, de ces sections varie avec l'opcode d'en-tête.

3.7.1. Requêtes standard (Standard queries)​

Une requête standard spécifie un nom de domaine cible (QNAME), un type de requête (QTYPE) et une classe de requête (QCLASS) et demande les RRs qui correspondent. Ce type de requête constitue une vaste majorité des requêtes DNS que nous utilisons le terme « requête » pour signifier requête standard sauf indication contraire. Les champs QTYPE et QCLASS sont chacun de 16 bits de long, et sont un sur-ensemble de types et classes définis.

Le champ QTYPE peut contenir :

  • <tout type> : correspond uniquement à ce type. (par exemple, A, PTR).
  • AXFR : QTYPE spécial de transfert de zone.
  • MAILB : correspond à tous les RRs liés aux boîtes aux lettres (par exemple MB et MG).
  • * : correspond à tous les types de RR.

Le champ QCLASS peut contenir :

  • <toute classe> : correspond uniquement à cette classe (par exemple, IN, CH).
  • * : correspond à toutes les classes de RR.

En utilisant le nom de domaine de requête, QTYPE et QCLASS, le serveur de noms recherche les RRs correspondants. En plus des enregistrements pertinents, le serveur de noms peut retourner des RRs qui pointent vers un serveur de noms qui a les informations désirées ou des RRs qui devraient être utiles pour interpréter les RRs pertinents. Par exemple, un serveur de noms qui n'a pas les informations demandées peut connaître un serveur de noms qui les a ; un serveur de noms qui retourne un nom de domaine dans un RR pertinent peut également retourner le RR qui lie ce nom de domaine à une adresse.

Exemple de requête et de réponse (Example query and response)​

Par exemple, un programme de messagerie essayant d'envoyer du courrier à [email protected] pourrait demander au résolveur des informations de courrier sur ISI.EDU, résultant en une requête pour QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. La section de réponse de la réponse serait :

ISI.EDU.        MX      10 VENERA.ISI.EDU.
                MX      10 VAXA.ISI.EDU.

tandis que la section additionnelle pourrait être :

VAXA.ISI.EDU.   A       10.2.0.27
                A       128.9.0.33
VENERA.ISI.EDU. A       10.1.0.52
                A       128.9.0.32

Parce que le serveur suppose que si le demandeur veut des informations d'échange de courrier, il voudra probablement les adresses des échanges de courrier peu de temps après.

Notez que la construction QCLASS=* nécessite une interprétation spéciale concernant l'autorité. Étant donné qu'un serveur de noms particulier peut ne pas connaître toutes les classes disponibles dans le système de domaine, il ne peut jamais savoir s'il est autoritatif pour toutes les classes. Par conséquent, les réponses aux requêtes QCLASS=* ne peuvent jamais être autoritatives.

3.7.2. Requêtes inverses (Inverse queries) (Optionnel)​

Les serveurs de noms peuvent également supporter des requêtes inverses qui mappent une ressource particulière à un nom de domaine ou des noms de domaine qui ont cette ressource. Par exemple, alors qu'une requête standard pourrait mapper un nom de domaine à un RR SOA, la requête inverse correspondante pourrait mapper le RR SOA au nom de domaine.

L'implémentation de ce service est optionnelle dans un serveur de noms, mais tous les serveurs de noms doivent au moins être capables de comprendre un message de requête inverse et de retourner une réponse d'erreur non implémentée.

Le système de domaine ne peut pas garantir la complétude ou l'unicité des requêtes inverses car le système de domaine est organisé par nom de domaine plutôt que par adresse d'hôte ou tout autre type de ressource. Les requêtes inverses sont principalement utiles pour les activités de débogage et de maintenance de base de données.

Les requêtes inverses peuvent ne pas retourner le TTL approprié, et n'indiquent pas les cas où le RR identifié est l'un d'un ensemble (par exemple, une adresse pour un hôte ayant plusieurs adresses). Par conséquent, les RRs retournés dans les requêtes inverses ne devraient jamais être mis en cache.

Les requêtes inverses NE sont PAS une méthode acceptable pour mapper les adresses d'hôte aux noms d'hôtes ; utilisez plutôt le domaine IN-ADDR.ARPA.

Une discussion détaillée des requêtes inverses est contenue dans [RFC-1035].

3.8. Requêtes de statut (Status queries) (Expérimental)​

À définir.

3.9. Requêtes de complétion (Completion queries) (Obsolète)​

Les services de complétion optionnels décrits dans les RFCs 882 et 883 ont été supprimés. Des services reconçus peuvent devenir disponibles à l'avenir, ou les opcodes peuvent être récupérés pour une autre utilisation.

Dernière mise à jour le