RFC: 1034
Statut : Standard
Retour à l'index français
L'espace de noms de domaines est une structure arborescente. Chaque noeud et feuille de l'arbre correspond à un ensemble de ressources (qui peut être vide). Le système de domaines ne fait aucune distinction entre l'utilisation des feuilles et de la partie information des noeuds, ce mémo n'utilisant par la suite que le terme "noeud" pour référencer les deux types d'entités.
Chaque noeud dispose d'un identifiant, d'une longueur de zéro à 63 octets. Des noeuds "frères" ne peuvent pas avoir le même identifiant, bien que le même identifiant puisse se retrouver dans deux noeuds distincts (mais sans relation de fratrie). L'identifiant nul (c-à-d., de longueur zéro) est réservé pour désigner la racine.
Le nom de domaine d'un noeud est constitué de la liste des identifiants de tous les noeuds constituant le chemin entre ce noeud et la racine de l'arbre. Par convention, les identifiants qui composent un nom de domaine seront exprimés ou lus de gauche à droite, du plus spécifique (le plus bas, le plus éloigné de la racine) au plus globalisant (le plus haut, le plus proche de la racine).
En interne, les programmes manipulant les noms de domaines peuvent les représenter comme des séquences d'étiquettes, chacune comportant une octet de longueur suivi d'une chaîne d'octets. Comme tous les noms de domaines se terminent par la racine, laquelle éant identifiée par une chaîne de longueur nulle, ces représentations internes peuvent utiliser l'octet nul pour terminer un nom de domaine (à considérer comme l'octet de longueur du dernier identifiant, qui vaut zéro).
Par convention, les noms de domaines peuvent être stockés avec une casse arbitraire, mais toute comparaison de noms de domaines pour ce qui est des fonctions actuelles sont faites indépendamment de la casse, en supposant l'usage du jeu de caractères ASCII, et le bit de poids fort à zéro dans chque octet. Ceci signifie que vous serez libre de créer un noeud d'identifiant "A" ou encore "a", mais pas les deux en tant que frères l'un de l'autre ; ces deux domaines pourront être références par "a" ou "A" indistinctement. Cependant, lorsque vous recevez un nom de domaine ou un identifiant, il faudra en préserver la casse. La raison en est qu'il sera peut être nécessaire, dans un futur proche d'étendre les noms de domaines à une représentation binaire complète, dans le but d'accueillir de nouveaux services ; les services existants devant pouvoir rester inchangés.
Lorsqu'un utilisateur doit entrer un nom de domaine, la longueur de chaque identifiant est omise et les identifiants devront être séparés par des points ("."). Un nom de domaine complet atteignant toujours la racine, la forme écrite exacte de tout domaine entièrement qualifié se termine par un point. Nous utiliserons cette propriété pour distinguer les cas :
Les noms relatifs sont exprimés soit par rapport à une référence absolue connue, ou par rapport à une liste de domaines constituant ainsi une liste de recherche. Les noms relatifs existent souvent au niveau de l'interface utilisateur, où leur interprétation varie d'une implémentation à l'autre, ainsi que dans les fichiers principaux, dans lesquels sont exprimées des domaines relativement à un nom de domaine de référence. L'interprétation la plus courant utilise la racine "." soit comme l'origine simple soit comme l'un des membres d'une liste de recherche, et un nom à multiple identifiants est souvent exprimé sans le point final par "paresse".
Pour simplifier les implémentations, le nombre total d'octets composant un nom de domaine entièrement qualifié (c'est à dire la somme de tous les identifiants plus la mention des longueurs d'identifiants) est limité à 255.
Un domaine est identifié par un nom de domaine, et consiste de la portion de l'espace de domaine située au niveau et en dessous du noeud spécifié par le domaine. Un domaine est le sous-domaine d'un autre domaine s'il est contenu ans ce dernier. Cette relation peut être vérifiée en regardant si le nom du sous-domaine se termine par le nom du domaine le contenant. Par exemple, A.B.C.D est un sous-domaine de B.C.D, C.D, D, et "".
En matière de politique d'administration, les spécifications techniques du DNS n'imposent aucune structure d'arbre particulière ni de règles pour le choix des identifiants ; son but est d'être le plus général possible, et il doit pouvoir servir à toutes sortes d'applications. En particulier, le système était conçu de sorte que l'espace de noms n'ait pas nécessairement à suivre les limites physiques de la constitution du réseau, des serveurs de noms, etc. La motivation de ceci ne signifie pas que le système de noms refuse toute notion de sémantique, mais plutôt que le choix d'une sémantique implicite puisse rester ouvert pour pouvoir s'adapter aux problèmes particuliers lorsqu'ils se présenteraient, et qu'il reste acceptable que certaines sous parties de l'arbre puisse user de sémantiques différentes. Par exemple, le domaine IN-ADDR.ARPA est organisé et distribué en réseaux et adresses d'hôtes car son rôle est la traduction d'adresses complètes d'hôtes en noms ; Les domaines NetBIOS [RFC-1001, RFC- 1002] sont des domaines plats conformément aux besoins de cette application.
Cependant, nous pouvons donner quelques règles à suivre pour des parties "normales" du domaine de noms qui utilisent le schéma réseau/hôte, ou boîtes aux lettres, etc., qui permettent de maintenir l'espace de noms uniforme, préserve sa capacité de croissance, et minimise les problèmes lorsque des logiciels sont mis à jour à partir de tables anciennes. Les premières décisions "politiques" concernant les niveaux haut de l'arbre ont été données dans la RFC-920. La politique actuelle pour les niveaux haut sont discutées dans la [RFC-1032]. Les conversions pour l'espace MILNET sont couvertes dans la [RFC-1031].
Les domaines de plus bas niveaux qui peuvent à leur tour être subdivisés en zones multiples devront pouvoir proposer des branchements vers le haut du domaine de telle sorte que d'éventuelles décompositions puissent se faire sans changement de noms. Les identifiants de noeuds utilisant des caractères spéciaux, des chiffres en tête, etc., risquent de poser des problèmes à des programmes plus anciens basés sur des choix plus restrictifs.
Avant que le DNS puisse être utilisé pour accueillir les informations de nommage de quelque catégorie d'objets que ce soit, deux besoins doivent être remplis :
Ces règles peuvent être du plus simple au plus complexe. Très souvent, le concepteur doit prendre en compte les formats existants et doit planifier une compatibilité ascendante pour les utilisations actuelles. Plusieurs conversions et niveaux de conversion peuvent devenir nécessaires.
Pour les hôtes, la conversion dépends de la syntaxe actuelle pour les noms d'hôtes, elle-même un sous ensemble de la représentation textuelle courante pour les noms de domaine, ainsi que des formats RR décrivant les adresses des hôtes. Dans la mesure ou nous souhaitons pouvoir disposer d'un transcodage inverse fiable depuis les adresses d'hôtes vers les noms d'hôtes, un codage particulier pour les adresses du domaine IN-ADDR.ARPA est défini.
Pour les boîtes aux lettres, le transcodage est légèrement plus complexe. L'adresse Mail habituelle L'utilisateur type n'est pas concerné par l'établissement de ces règles, mais doit néanmoins comprendre qu'elles résultent de nombreux compromis entre des contraintes de compatibilité ascendante pour d'anciennes applications toujours en service, des interactions entre les différentes définitions d'objets, et l'incontournable urgence qu'il y a à développer de nouvelles fonctionnalités lorsque de nouvelles règles sont établies. La manière dont le DNS est exploité pour prendre en compte tel ou tel objet est souvent plus importante que les restrictions inhérentes au DNS.
La figure suivante montre une partie de l'espace de noms de domaines actuel, et sert de base d'exemple à de nombreuses reprises dans cette RFC. Notez que cet arbre est un tout petit sous ensemble de l'étendue réelle de l'espace des noms de domaines.
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 appelé XX.LCS.MIT.EDU. Toutes les feuilles sont également des domaines.
Les spécifications du DNS tentent d'être aussi génériques que possible pour ce qui concerne les règles de construction des noms de domaines. L'idée de base est que le nom existant pour un objet puisse être utilisé pour exprimer un nom de domaine avec le minimum de transformation. Cependant, au moment d'assigner un nom de domaine à un objet, l'utilisateur prudent choisira un nom qui d'une part respecte les règles de construction du système de domaines et d'autre part respecte les règles inhérentes à l'objet à nommer lui-même, que ces règles aient été publiées ou existent de façon implicite par le fait qu'elles sont utilisées par certains programmes.
Par exemple, pour nommer un domaine de courrier, l'utilisateur devra respecter les règles de ce mémo ainsi que celles établies par la RFC-822. Pour nommer un hôte, les anciennes règles instaurées pour les fichiers HOSTS.TXT d'alors devront être suivies. Ceci permet d'éviter des problèmes lorsque d'anciens programmes sont transformés pour prendre en compte les noms de domaine.
La syntaxe suivante diminuera notablement le risque de problèmes avec toute application utilisant les noms de domaine (ex., mail, TELNET).
Notez que, bien que tant les majuscules que les minuscules soient autorisées dans des noms de domaines, aucune importance n'est accordée à la casse. C'est-à-dire, deux noms lexicographiquement identiques, mais écrit dans une casse différente seront considérés comme identiques.
Les identifiants doivent suivre les règles définies pour les noms d'hôtes ARPANET. Ils doivent commencer par une lettre, terminer par une lettre ou un digit, et n'avoir à l'intérieur que des lettres, des digits, et éventuellement le caractère Hyphénation (-). On notera de plus quelques restrictions à propos de la longueur. Un identifiant doit avoir au plus 63 caractères.
Par exemple, les chaînes suivantes identifient des hôtes d'Internet :
Un nom de domaine identifie un noeud. A chaque noeud est attribué un ensemble d'informations sur des ressource, lequel peut être vide. L'ensemble d'informations de ressources associé à un nom particulier est composé de quatre enregistrements de ressources séparés (RR). L'ordre des RR dans un ensemble n'est pas significatif, et ne doit pas nécessairement être préservé par les serveurs de noms, les résolveurs, ou tout autre partie du DNS.
Lorsque nous parlons d'un RR spécifique, nous supposons qu'il contient les éléments suivants :
Ce mémo définit les types suivants :
Ce mémo définit les classes suivantes :
Le nom du propriétaire (owner) est souvent implicite, plutôt que formant une partie intégrante du RR. Par exemple, de nombreux serveurs de noms représentent l'espace de nom en interne sous forme d'arbre ou de tableaux associatifs, et pointent les RR à partir des noeuds. Le restant des données des RR, soit l'en-tête fixe (type, classe, TTL) valable pour tous les RR, et la partie variable (RDATA) adaptée au type de ressource décrite, étant habituellement stockée à l'extérieur de la représentation de la structure de l'espace.
La signification du champ TTL est la durée limite pendant laquelle un RR peut être conservé dans un cache local. Cette limite ne s'applique pas aux données "autorisées" stockées dans les zones ; celles-ci disposent aussi d'une temporisation, mais définie par la politique de rafraîchissement de la zone elle-même. La TTL est définie par l'administrateur pour toute la zone contenant cet enregistrement. Alors qu'une valeur faible de la TTL peut être utilisée pour diminuer la durée de cache, et qu'une valeur de zéro empêche tout stockage local, l'analyse réelle des performances d'Internet suggère que cette valeur soit de l'ordre de quelques jours pour un hôte type. Lorsque l'on peut anticiper sur une modification, la TTL pourra être réduite juste avant d'effectuer la modification pour optimiser la consistance de l'information au moment du changement, puis être rétablie à sa valeur d'origine après un certain délai.
Les données dans la section RDATA d'un RR est stockée comme une combinaison de chaînes binaires et de noms de domaines. Les noms de domaines seront souvent utilisés à titre de "pointeurs" sur d'autres structures de données du DNS.
Les RR sont représentés sous forme binaire dans les paquets du protocole DNS, et sont habituellement représentés sous une forme fortement compactée lorsque stockés par un serveur de noms ou un résolveur. Dans ce document, nous adopterons une notation similaire à celle utilisée dans les fichiers principaux de façon a exprimer le contenu des RR. Dans ce format, la plupart des RR peuvent être exprimés sur une seule ligne, bien qu'une extension sur plusieurs lignes soit possible par l'utilisation de parenthèses.
Au début de la ligne est mentionné le propriétaire du RR. Si une ligne commence par un esapce, alors on suppose que le propriétaire de l'enregistrement est le même que celui du RR précédent. Des lignes vides sont aussi souvent insérées pour augmenter la lisibilité.
Après le propriétaire, nous exprimerons la TTL, le type, et la classe du RR. Classe et type utilisent les mnémoniques définis ci-avant, la TTL étant exprimée sous forme d'entier apparaissant avant le champ type. De façon à éviter des ambiguïtés d'interprétation lors de l'analyse des lignes, les mnémoniques du type et de la classe sont disjoints, la TTL est un entier, et le mnémonique de type apparaît toujours en dernier. La classe IN et les valeurs de la TTL seront souvent omises dans les exemples par souci de clarté.
Les données de ressource ou section RDATA de l'enregistrement sont exprimées selon la connaissance que nous avons de la représentation classique de ces données.
Par exemple, nous exprimerons un RR transporté par un message sous la forme suivante :
Le RR MX a une section RDATA consistant en un entier sur 16 bits suivi par un nom de domaine. L'adresse du RR utilise la représentation standard d'une adresse IP sur 32 bits.
Cet exemple montre donc six RR, répartis en groupes de deux RR pour chacun des trois noms de domaines.
De la même manière nous pourrions voir :
représentant deux adresses pour l'hôte XX.LCS.MIT.EDU, chacune d'une classe différente.
Dans des systèmes existants, les hôtes et autres ressources peuvent avoir plusieurs noms différents pour les désigner. Par exemple, les noms C.ISI.EDU et USC-ISIC.ARPA pointent sur le même hôte. De la même manière, dans le cas de boîtes aux lettres, de nombreuses organisations font pointer sur la même boîte aux lettres de multiples noms; par exemple Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU, et PVM@ISI.EDU pointent toutes la même boîte aux lettres (bien que l mécanisme derrière tout ça soit légèrement plus compliqué que cela).
La plupart de ces systèmes manipulent une notion selon laquelle l'un de ces noms est dit primaire (ou canonique), et tous les autres sont des alias.
Le système de domaines dispose d'une telle fonctionnalité par l'utilisation du nom canonique (CNAME) RR. Un RR CNAME identifie son propriétaire comme étant un alias, et spécifie le nom canonique correspondant dans la section RDATA du RR. Si un RR CNAME est présent dans un noeud, aucune autre donnée ne peut y être inscrite; cette restriction garantit que les données relatives à un nom canonique et son alias seront toujours identiques. Cette règle assure de plus qu'un enregistrement CNAME peut être utilisé sans nécessité de consulter un serveur "autorisé" pour obtenir d'autres types de RR.
Les RR CNAME provoquent des actions particulières dans un processus DNS. Lorsqu'un serveur de noms échoue lorsqu'il cherche un enregistrement particulier dans l'ensemble des informations associées au nom de domaine, il vérifie si la ressource n'est pas un enregistrement CNAME avec la bonne classe. Si c'est le cas, le serveur de noms répond à la requête en retournant l'enregistrement CNAME dans la réponse et relance une résolution sur le nom de domaine mentionné dans la section RDATA de l'enregistrement CNAME (donc sur le domaine canonique). La seule exception admise pour cette règle est lorsque la requête initiale demande déjà une information de type CNAME, auquel cas la redirection n'est pas effectuée.
Par exemple, supposez qu'un serveur de noms traite une requête sur le domaine USC-ISIC.ARPA, pour un type d'information A, et dispose des enregistrements suivants :
Les deux RR seraient retournés pour une requête sur le type A, tandis qu'une requête sur le type CNAME ou * se verrait répondre par l'enregistrement CNAME uniquement. Les noms de domaine dans les RR pointant sur un autre nom de domaine devra toujours pointer sur un nom canonique et jamais sur un alias. Ceci évitera une multiplication inutile des étapes d'indirection. Par exemple, l'adresse à utiliser dans les RR pour pointer sur l'hôte ci-dessus serait :
plutôt qu'un pointeur sur USC-ISIC.ARPA. Bien sûr, selon le principe de robustesse, les logiciels de domaines ne devraient pas échouer face à des chaînes ou des boucles de CNAME; Les enchaînement de CNAME devront être suivis et les bouclages de CNAME signalées par une erreur.
Les requêtes sont des messages qui sont envoyées à un serveur de noms pour obtenir une réponse. Dans Internet, les requêtes sont transportées par des datagrammes UDP ou sur via des connexions TCP. La réponse du serveur de nom peut soit répondre à la question posée par la requête, rediriger le requérant vers un autre serveur de noms, ou signaler une condition d'erreur.
En général, l'utilisateur ne pourra émettre lui-même directement des requêtes, mais passera par un résolveur qui émettra une ou plusieurs requêtes vers des serveurs de noms et sera en mesure de traiter les conditions d'erreur ou les redirections qui pourraient en résulter. Bien sûr, les questions possibles qui peuvent être posées dans une requête doivent correspondre au type de service pour lequel le résolveur est conçu.
Les requêtes et réponses DNS sont transportées dans un message de format standardisé. Le format de message définit une en-tête contenant un certain nombre de champs fixes toujours présents, et quatre sections pour transporter les paramètres et les RR.
Le champ d'en-tête le plus important est un champ de 4 bits appelé "code opération", permettant de distinguer les différentes requêtes. Parmi les 16 valeurs possibles, une (requête standard) fait partie du protocole officiel, deux autres (requête inverse et requête d'état) sont optionnelles, une autre (fin de traitement) est obsolète, les autres restant non assignées à l'heure actuelle.
Les quatre sections sont :
Notez que le contenu, (mais pas le format) de ces sections peut varier suivant le code opération de l'en-tête.
Une requête standard contient un nom de domaine cible (QNAME), un type de requête (QTYPE), et une classe de requête (QCLASS) et requiert les RR correspondants. Ce type de requête représente la très grande majorité des requêtes qui peuvent arriver à un DNS et nous les appellerons "requête" sans autre mention qualificative. Les requêtes plus particulières seront explicitement qualifiées. Les champs QTYPE et QCLASS font chacun 16 bits de long, et sont un surensemble des types et classes définies. Le champ QTYPE peut contenir :
Le champ QCLASS peut contenir :
A partir du nom de domaine cible, du QTYPE, et QCLASS, le serveur de noms recherche les RR correspondants. En plus des enregistrements trouvés, le serveur de noms de domaines peut renvoyer les RR pointant vers un serveur de noms détenant l'information demandée ainsi que tout RR qui peut aider à l'interprétation des RR renvoyés. Par exemple, un serveur de noms de domaines ne disposant pas de l'information demandée peut connaître un autre serveur de nom qui la détient ; un serveur de noms qui renvoie des RR pertinents peut aussi y adjoindre d'autres RR qui relient le nom de domaine vers une adresse.
Par exemple, un agent de courrier tentant d'envoyer un message dans la boîte aux lettres Mockapetris@ISI.EDU peut demander à son résolveur des informations sur le serveur de courrier de ISI.EDU, constituant pour cela la requête QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. La section réponse renvoyée serait dans ce cas :
et la section additionnelle :
Comme le serveur suppose que si le requérant désire des informations sur un échangeur de courrier, il désirera obtenir les adresses de ces échangeurs peu après.
Notez que l'écriture QCLASS=* nécessite une interprétation particulière notamment concernant les "autorisations". Dans la mesure où un serveur de nom ne connaît pas nécessairement toutes les classes disponibles dans le système de domaines, il ne peut jamais savoir si il est "autorisé" pour toutes les classes. Par voie de conséquence, aucune réponse à une requête QCLASS=* peut se qualifier "d'autorisée".
Les serveurs de noms peuvent également supporter des requêtes inverses ou "rétro-requêtes" transcodant une ressource particulière en un nom de domaine ou les noms de domaines disposant de cette ressource. par exemple, alors qu'une requête standard peut transcoder un nom de domaine en un RR SOA, la rétro-requête correspondante transcodera ce RR SOA vers le nom de domaine.
L'implémentation de ce service est optionnel dans un serveur de noms de domaines, bien que tous les serveurs de noms doivent au moins être capable d'identifier une requête inverse et renvoyer le message d'erreur "not-implemented". Le système de domaines ne peut pas garantir le résultat ou l'unicité de la réponse à une rétro-requête du fait de son organisation basée sur une hiérarchie de noms de domaines, et non sur une adresse d'hôte ou tout autre type de ressource. Les rétro-requêtes sont principalement utiles pour des fonctions de débogage et la maintenance des bases de données.
Les réponses à rétro-requêtes ne devront pas renvoyer la TTL, et ne doit pas indiquer les cas où le RR identifié fait partie d'un ensemble corrélé (par exemple, une adresse d'un hôte disposant de plusieurs adresses). De ce fait, les RR renvoyés par des rétro-requêtes ne doivent jamais être stockés.
Les rétro-requêtes NE sont PAS une méthode acceptable pour transcoder des adresses d'hôtes en noms d'hôtes ; utiliser plutôt le domaine IN-ADDR.ARPA.
Une discussion détaillée sur les rétro-requêtes peut être consultée dans la [RFC-1035].
Le service optionnel de mention de fin de traitement défini dans les RFC 882 et 883 a été supprimé. Un service de ce type complètement rénové sera peut être rétabli dans le futur, ou bien les codes opération réservés par cet ancienne fonctionnalité seront réaffectés.
3.4. Exemple d'espace de noms
|
|
+---------------------+------------------+
| | |
MIL EDU ARPA
| | |
| | |
+-----+-----+ | +------+-----+-----+
| | | | | | |
BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
|
+--------+------------------+---------------+--------+
| | | | |
UCI MIT | UDEL YALE
| ISI
| |
+---+---+ |
| | |
LCS ACHILLES +--+-----+-----+--------+
| | | | | |
XX A C VAXA VENERA Mockapetris
3.5. Syntaxe préférentielle pour les noms
<domaine> ::= <sous-domaine> | " "
<sous-domaine> ::= <identifiant> | <sous-domaine> "." <identifiant>
<identifiant> ::= <lettre> [ [ <ch-ldh> ] <let-dig> ]
<ch-ldh> ::= <let-dig-hyp> | <let-dig-hyp> <ch-ldh>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <lettre> | <digit>
<lettre> ::= un des 52 caractères alphabetiques de "A" à "Z" (majuscules) ou de
"a" à "z" (minuscules)
<digit> ::= un des dix digits de "0" à "9"
A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
3.6. Enregistrements
owner
le nom de domaine où le RR est trouvé.
Type
une valeur encodée sur16 bits spécifiant le type de ressource décrit par cet enregistrement. Les types se réfèrent à une définition abstraite des ressources.
A
une adresse d'hôte
CNAME
le nom canonique d'un alias
HINFO
le CPU et le système d'exploitation (OS) d'un hôte
MX
un schéma d'échange de courrier pour ce domaine. Voir [RFC-974] pour plus de détails.
NS
le serveur de noms "autorisé" pour le domaine
PTR
un pointeur vers une autre partie de l'espace de noms de domaines
SOA
le début d'une sphère d'autorité
class
une valeur encodée sur 16 bits identifiant une famille de protocoles ou une instance d'un protocole.
IN
le système Internet
CH
le système Chaotique
TTL
la durée de vie du RR. Cette valeur est représentée sous forme d'un entier sur 32 bits et est exprimée en secondes, et est principalement utilisée par les résolveurs lorsqu'ils mémorisent temporairement des RR. Le champ TTL définit combien de temps un RR peut être gardé localement avant de devoir être considéré comme obsolète.
RDATA le type et parfois les données dépendantes de la classe décrivant la ressource :
A
Pour la classe IN, une adresse IP sur 32 bits. Pour la classe CH, un nom de domaine suivi d'une adresse octale Chaotique sur 16 bits.
CNAME
un nom de domaine.
MX
une valeur de préférence sur 16 bits (la plus basse possible) suivie d'un nom d'hôte souhaitant servir d'échangeur de courrier pour le domaine de l'owner.
NS
un nom d'hôte.
PTR
un nom de domaine.
SOA
plusieurs champs.
3.6.1. Expression des RR sous forme textuelle
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
XX.LCS.MIT.EDU. IN A 10.0.0.44
CH A MIT.EDU. 2420
3.6.2. Alias et expression canonique des noms
USC-ISIC.ARPA IN CNAME C.ISI.EDU
C.ISI.EDU IN A 10.0.0.52
52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU
3.7. Requêtes
Question
contient le nom de la requête et ses autres paramètres.
Réponse
contient les RR qui répondent directement à la requête.
Autorisation
contient les RR décrivant d'autres serveurs "autorisés". Peut aussi contenir un RR SOA contenant les données d'autorisation dans la section réponse.
Additionnel
contient les RR qui peuvent aider à exploiter les RR contenus dans les autres sections.
3.7.1. Requête Standard
<tout type>
demande la correspondance sur ce type. (ex., A, PTR).
AXFR
QTYPE spécial pour transfert de zone.
MAILB
demande la correspondance pour toutes les RR de boîtes aux lettres (ex. MB et MG).
*
demande la correspondance sur tous les types de RR.
<toute classe>
demande la correspondance sur cette classe uniquement (e., IN, CH).
*
demande la correspondance sur toutes les classes de RR.
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
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
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)