DNS
Sommaire status introduction espaces de noms serveurs resolveurs exemple references

dns : rfc 1034 en francais : exemple

6. UN SCENARIO

Dans notre espace de domaine "test", supposez que nous souhaitions obtenir un contrôle administratif autonome pour la racine, et les zones MIL, EDU, MIT.EDU et ISI.EDU. Nous définirions des serveurs de noms comme suit : 
                                   |(C.ISI.EDU,SRI-NIC.ARPA
                                   | A.ISI.EDU)
             +---------------------+------------------+
             |                     |                  |
            MIL                   EDU                ARPA
             |(SRI-NIC.ARPA,       |(SRI-NIC.ARPA,    |
             | A.ISI.EDU           | C.ISI.EDU)       |
       +-----+-----+               |     +------+-----+-----+
       |     |     |               |     |      |           |
      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
                                   |
       +--------+------------------+---------------+--------+
       |        |                  |               |        |
      UCI      MIT                 |              UDEL     YALE
                |(XX.LCS.MIT.EDU, ISI
                |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
            +---+---+              | A.ISI.EDU)
            |       |              |
           LCS   ACHILLES +--+-----+-----+--------+
            |             |  |     |     |        |
Dans cet exemple, le serveur de noms "autorisé" est noté entre parenthèses au point de l'arbre de domaines à partir duquel il prend le contrôle administratif de ce dernier.

Bien que les serveurs de noms pour la racine soient sur C.ISI.EDU, SRI-NIC.ARPA, et A.ISI.EDU. Le domaine MIL est servi par SRI-NIC.ARPA et A.ISI.EDU. Le domaine EDU est servi par SRI-NIC.ARPA. et C.ISI.EDU. Notez que les serveurs peuvent supporter des zones contiguës ou disjointes. Dans notre scénario, C.ISI.EDU gère les zones contiguës de la racine et du domaine EDU. A.ISI.EDU gère les zones contiguës de la racine et du domaine MIL, mais gère une troisième zone non-contiguë aux deux autres, la zone ISI.EDU. 

6.1. Serveur de nom C.ISI.EDU

C.ISI.EDU est un serveur de nom pour les domaines racine, MIL, et EDU pour la classe IN, et maintiendra des zones pour ces domaines. Les données de zone pour le domaine racine seraient : 
    .       IN      SOA     SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
                            870611          ;serial
                            1800            ;refresh every 30 min
                            300             ;retry every 5 min
                            604800          ;expire after a week
                            86400)          ;minimum of a day
                    NS      A.ISI.EDU.
                    NS      C.ISI.EDU.
                    NS      SRI-NIC.ARPA.

    MIL.    86400   NS      SRI-NIC.ARPA.
            86400   NS      A.ISI.EDU.

    EDU.    86400   NS      SRI-NIC.ARPA.
            86400   NS      C.ISI.EDU.

    SRI-NIC.ARPA.   A       26.0.0.73
                    A       10.0.0.51
                    MX      0 SRI-NIC.ARPA.
                    HINFO   DEC-2060 TOPS20

    ACC.ARPA.       A       26.6.0.65
                    HINFO   PDP-11/70 UNIX
                    MX      10 ACC.ARPA.

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

    73.0.0.26.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
    65.0.6.26.IN-ADDR.ARPA.  PTR    ACC.ARPA.
    51.0.0.10.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
    52.0.0.10.IN-ADDR.ARPA.  PTR    C.ISI.EDU.
    103.0.3.26.IN-ADDR.ARPA. PTR    A.ISI.EDU.

    A.ISI.EDU. 86400 A      26.3.0.103
    C.ISI.EDU. 86400 A      10.0.0.52
Ces données sont représentées comme elles seraient écrites dans un fichier maître. La plupart des RR sont des entrées à une ligne ; la seule exception ci-dessus est le RR SOA pour cette zone, qui utilise une "(" pour commencer une définition multi-ligne et une ")" pour indiquer la fin du RR multi-ligne. Comme la classe de tous les RR d'une zone doit être identique, seul le premier RR d'une zone mentionnera la classe. Lorsqu'un serveur de noms charge une zone, il force la durée de vie de tout RR "autorisé" à la valeur indiquée dans le champ MINIMUM du SOA, ici 86400 secondes, soit un jour. Le RR NS indiquant la délégation administrative pour les domaines MIL et EDU, combinés aux RR de "glue" indiquant les adresses des hôtes de ces serveurs, ne font pas partie des données dites "autorisées" de la zone, et de ce fait mentionnent des durées de vies explicites.

Quatre RR sont rattachés au noeud racine : le SOA qui décrit la zone racine et les 3 RR NS qui listent les serveurs de noms pour la racine. Les données dans le RR SOA décrivent comment est gérée la zone. Les données de zone sont maintenues sur l'hôte SRI-NIC.ARPA, et le responsable de cette zone est joignable à l'adresse HOSTMASTER@SRI-NIC.ARPA. Une des données clef de ce SOA est la durée de vie minimum marquée 86400, qui signifie que toutes les données autorisées de cette zone sont valides pendant au moins cette durée, mais que des valeurs plus grandes peuvent être explicitement spécifiées.

Les RR NS pour les domaines MIL et EDU marquent la frontière entre ce qui est du ressort de la zone racine et ce qui est du ressort des sous-domaines MIL et EDU. Notez que dans cet exemple, un zone de niveau inférieure se retrouve gérée par un serveur supportant la zone racine.

Le fichier maître de la zone EDU devra être constitué relativement au point EDU. Les données de zone pour le domaine EDU pourraient être : 

    EDU.  IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
                            870729 ;serial
                            1800 ;refresh every 30 minutes
                            300 ;retry every 5 minutes
                            604800 ;expire after a week
                            86400 ;minimum of a day
                            )
                    NS SRI-NIC.ARPA.
                    NS C.ISI.EDU.

    UCI 172800 NS ICS.UCI
                    172800 NS ROME.UCI
    ICS.UCI 172800 A 192.5.19.1
    ROME.UCI 172800 A 192.5.19.31
    ISI 172800 NS VAXA.ISI
                    172800 NS A.ISI
                    172800 NS VENERA.ISI.EDU.
    VAXA.ISI 172800 A 10.2.0.27
                    172800 A 128.9.0.33
    VENERA.ISI.EDU. 172800 A 10.1.0.52
                    172800 A 128.9.0.32
    A.ISI 172800 A 26.3.0.103

    UDEL.EDU.  172800 NS LOUIE.UDEL.EDU.
                    172800 NS UMN-REI-UC.ARPA.
    LOUIE.UDEL.EDU. 172800 A 10.0.0.96
                    172800 A 192.5.39.3

    YALE.EDU.  172800 NS YALE.ARPA.
    YALE.EDU.  172800 NS YALE-BULLDOG.ARPA.

    MIT.EDU.  43200 NS XX.LCS.MIT.EDU.
                      43200 NS ACHILLES.MIT.EDU.
    XX.LCS.MIT.EDU.  43200 A 10.0.0.44
    ACHILLES.MIT.EDU. 43200 A 18.72.0.8
Notez ici l'utilisation de noms relatifs. Le nom du proprétaire (owner) pour ISI.EDU. est noté en mode relatif, ainsi que le contenu de deux RR relatifs aux serveurs de noms. Les noms de domaines exprimés en relatif et en absolu peuvent être librement mélangés dans un fichier maître. 

6.2. Exemple de requête standard

Les requêtes et réponses suivantes illustrent le comportement d'un serveur de noms. Sauf mention contraire, les requêtes ne demandent pas le mode récursif (RD) dans leur en-tête. Notez que les réponses à des requêtes non-récursives dépendent du serveur de noms contacté, et non de l'identité du requérant. 

6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A

La requête aurait l'aspect suivant : 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY                                     |
                 +---------------------------------------------------+
    Question     | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
                 +---------------------------------------------------+
    Réponse      | <vide>                                            |
                 +---------------------------------------------------+
    Autorisation | <vide>                                            |
                 +---------------------------------------------------+
    Additionnel  | <vide>                                            |
                 +---------------------------------------------------+
La réponse de C.ISI.EDU serait : 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE, AA                       |
                 +---------------------------------------------------+
    Question     | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
                 +---------------------------------------------------+
    Réponse      | SRI-NIC.ARPA. 86400 IN A 26.0.0.73                |
                 |               86400 IN A 10.0.0.51                |
                 +---------------------------------------------------+
    Autorisation | <vide>                                            |
                 +---------------------------------------------------+
    Additionnel  | <vide>                                            |
                 +---------------------------------------------------+
L'en-tête de la réponse ressemble à celle de la requête, excepté que le bit RESPONSE est marqué, indiquant que ce message est bel est bien une réponse, et non une requête, le bit Réponse Autorisée (AUTHORITATIVE ANSWER = AA) est marqué, indiquant que les adresses données dans les RR de la section réponse sont "autorisées". La section question de la réponse est une recopie de la section question de la requête.

Si la même requête avait été envoyée à d'autres serveurs "non autorisés" pour le domaine SRI-NIC.ARPA, la réponse aurait été : 

                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY,RESPONSE                            |
                 +---------------------------------------------------+
    Question     | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
                 +---------------------------------------------------+
    Réponse      | SRI-NIC.ARPA. 1777 IN A 10.0.0.51                 |
                 |               1777 IN A 26.0.0.73                 |
                 +---------------------------------------------------+
    Autorisation | <vide>                                            |
                 +---------------------------------------------------+
    Additionnel  | <vide>                                            |
                 +---------------------------------------------------+
Cette réponse est différente de la précédente à deux titres : l'en-tête ne présente pas le bit AA marqué, et les durées de vie sont différentes. La déduction peut être faite que ces données ne proviennent pas d'une zone, mais plutôt d'un cache. La différence de durée de vie est alors due à l'intervention de la durée passée de stationnement dans le cache. Les différences d'ordre dans lequel les RR de la section Réponse sont présentés n'est pas significative. 

6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*

Une requête similaire à la précédente, mais utilisant un QTYPE "*", recevrait la réponse suivante de la part de C.ISI.EDU: 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE, AA                       |
                 +---------------------------------------------------+
    Question     | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
                 +---------------------------------------------------+
    Réponse      | SRI-NIC.ARPA. 86400 IN  A     26.0.0.73           |
                 |                         A     10.0.0.51           |
                 |                         MX    0 SRI-NIC.ARPA.     |
                 |                         HINFO DEC-2060 TOPS20     |
                 +---------------------------------------------------+
    Autorisation | <vide>                                            |
                 +---------------------------------------------------+
    Additionnel  | <vide>                                            |
                 +---------------------------------------------------+
Si une requête identique était émise vers des serveurs "non autorisés" pour le domaine SRI-NIC.ARPA, la réponse aurait été : 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE                           |
                 +---------------------------------------------------+
    Question     | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
                 +---------------------------------------------------+
    Réponse      | SRI-NIC.ARPA. 12345 IN     A       26.0.0.73      |
                 |                            A       10.0.0.51      |
                 +---------------------------------------------------+
    Autorisation | <vide>                                            |
                 +---------------------------------------------------+
    Additionnel  | <vide>                                            |
                 +---------------------------------------------------+
et 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE                           |
                 +---------------------------------------------------+
    Question     | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
                 +---------------------------------------------------+
    Réponse      | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |
                 +---------------------------------------------------+
    Autorisation | <vide>                                            |
                 +---------------------------------------------------+
    Additionnel  | <vide>                                            |
                 +---------------------------------------------------+
Aucune de ces deux réponse ne présente le bit AA marqué, et donc aucune des deux ne s'est basée sur des données "autorisées". Les différences de contenu et de durées de vie suggèrent que les deux serveurs ont enregistré les données dans leur cache à une date différente, et que le premier serveur à obtenu ces données suite à une requête QTYPE=A, le second les ayant obtenues suite à une requête HINFO. 

6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX

Ce type de requête pourrait émaner d'un agent de courrier électronique essayant de trouver le chemin pour le destinataire de courrier HOSTMASTER@SRI-NIC.ARPA. La réponse de C.ISI.EDU serait : 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE, AA                       |
                 +---------------------------------------------------+
    Question     | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX          |
                 +---------------------------------------------------+
    Réponse      | SRI-NIC.ARPA. 86400 IN     MX      0 SRI-NIC.ARPA.|
                 +---------------------------------------------------+
    Autorisation | <vide>                                            |
                 +---------------------------------------------------+
    Additionnel  | SRI-NIC.ARPA. 86400 IN     A       26.0.0.73      |
                 |                            A       10.0.0.51      |
                 +---------------------------------------------------+
Cette réponse contient un RR MX dans la section Réponse du message. La section additionnelle contient les RR d'adresse car le serveur de nom à C.ISI.EDU devine que le requérant aura besoin de ces adresses pour exploiter correctement les information transmises dans le RR MX. 

6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS

C.ISI.EDU répondrait à la requête par : 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE, AA                       |
                 +---------------------------------------------------+
    Question     | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS          |
                 +---------------------------------------------------+
    Réponse      | <vide>                                            |
                 +---------------------------------------------------+
    Autorisation | <vide>                                            |
                 +---------------------------------------------------+
    Additionnel  | <vide>                                            |
                 +---------------------------------------------------+
La seule différence entre la requête et la réponse est le marquage des bits AA et RESPONSE dans l'en-tête. L'interprétation de cette réponse est que le serveur est bien "autorisé" pour le nom en question, lequel existe, mais pour lequel aucun enregistrement de type NS n'est disponible. 

6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A

Lorsqu'un utilisateur orthographie mal un nom de domaine, nous pourrons voir ce type de requête. C.ISI.EDU répondrait dans ce cas : 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE             |
                 +---------------------------------------------------+
    Question     | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A           |
                 +---------------------------------------------------+
    Réponse      | <vide>                                            |
                 +---------------------------------------------------+
    Autorisation | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.      |
                 |       870611 1800 300 604800 86400                |
                 +---------------------------------------------------+
    Additionnel  | <vide>                                            |
                 +---------------------------------------------------+
Cette réponse indique que le nom demandé n'existe pas. Cette condition est exprimée par le code de réponse (RCODE) dans l'en-tête.

Le RR SOA dans la section Autorisation est l'information optionnelle à enregistrer en cas de cache des réponses négatives, qui permet au résolveur utilisant cette réponse de supposer que le nom recherché n'existera pas pendant au moins SOA MINIMUM (86400) secondes. 

6.2.6. QNAME=BRL.MIL, QTYPE=A

Si cette requête était envoyée à C.ISI.EDU, la réponse serait : 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE                           |
                 +---------------------------------------------------+
    Question     | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A                 |
                 +---------------------------------------------------+
    Réponse      | <vide>                                            |
                 +---------------------------------------------------+
    Autorisation | MIL.             86400 IN NS       SRI-NIC.ARPA.  |
                 |                  86400    NS       A.ISI.EDU.     |
                 +---------------------------------------------------+
    Additionnel  | A.ISI.EDU.                A        26.3.0.103     |
                 | SRI-NIC.ARPA.             A        26.0.0.73      |
                 |                           A        10.0.0.51      |
                 +---------------------------------------------------+
Cette réponse affiche une section Réponse vide, et n'est pas "autorisée". Il s'agit donc d'une redirection. Le serveur de noms à C.ISI.EDU, réalisant qu'il n'est pas "autorisé" pour le domaine MIL, redirige le requérant vers les serveurs à A.ISI.EDU et SRI-NIC.ARPA, qu'il connaît être autorisés pour le domaine MIL. 

6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A

La réponse à cette requête venant de A.ISI.EDU serait : 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE, AA                       |
                 +---------------------------------------------------+
    Question     | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
                 +---------------------------------------------------+
    Réponse      | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
                 | C.ISI.EDU.     86400 IN A          10.0.0.52      |
                 +---------------------------------------------------+
    Autorisation | <vide>                                            |
                 +---------------------------------------------------+
    Additionnel  | <vide>                                            |
                 +---------------------------------------------------+
Notez que le bit AA dans l'en-tête garantit que les données correspondantes au QNAME sont autorisées, mais ne permet pas d'en déduire l'état d'autorisation pour les données concernant C.ISI.EDU. Cette réponse complète est possible car A.ISI.EDU se trouve être autorisé à la fois pour le domaine ARPA ou se trouve USC-ISIC.ARPA et pour le domaine ISI.EDU où l'on trouve C.ISI.EDU.

Si la même requête était envoyée à C.ISI.EDU, la réponse serait la même que celle ci-dessus, dans le cas où il disposerait de ces adresses en cache, mais pourrait aussi prendre la forme : 

                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE, AA                       |
                 +---------------------------------------------------+
    Question     | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
                 +---------------------------------------------------+
    Réponse      | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |
                 +---------------------------------------------------+
    Autorisation | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |
                 |                           NS      A.ISI.EDU.      |
                 |                           NS      VENERA.ISI.EDU. |
                 +---------------------------------------------------+
    Additionnel  | VAXA.ISI.EDU.   172800    A       10.2.0.27       |
                 |                 172800    A       128.9.0.33      |
                 | VENERA.ISI.EDU. 172800    A       10.1.0.52       |
                 |                 172800    A       128.9.0.32      |
                 | A.ISI.EDU.      172800    A       26.3.0.103      |
                 +---------------------------------------------------+
Cette réponse contient des données autorisées pour l'alias USC-ISIC.ARPA, plus des données de redirection vers les serveurs de noms pour ISI.EDU. Cette sorte de réponse ne serait en général pas celle donnée si la requête visait le nom d'hôte du serveur de noms lui-même, mais serait courante pour d'autres alias. 

6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME

Si cette requête est émise vers A.ISI.EDU ou C.ISI.EDU, la réponse serait : 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE, AA                       |
                 +---------------------------------------------------+
    Question     | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
                 +---------------------------------------------------+
    Réponse      | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
                 +---------------------------------------------------+
    Autorisation | <vide>                                            |
                 +---------------------------------------------------+
    Additionnel  | <vide>                                            |
                 +---------------------------------------------------+
Parce que le QTYPE=CNAME, le RR CNAME lui-même répond à la requête, et le serveur de nom ne tentera pas de rechercher quoi que ce soit d'autre concernant C.ISI.EDU. (Sauf éventuellement pour renseigner une section additionnelle). 

6.3. Exemple de résolution

Les exemples suivants illustrent les opérations qu'un résolveur devra effectuer pour son client. Nous supposons que le résolveur part avec un cache vide, ce qui pourrait être le cas après un redémarrage système. Nous supposerons de plus que le système n'est pas l'un des hôtes marqué dans les données de zone et que l'hôte est situé quelque part sur le réseau d'adresse 26, et de plus, que sa structure "ceinture de sécurité" (SBELT) est constituée comme suit : 
    Match count = -1
    SRI-NIC.ARPA.   26.0.0.73       10.0.0.51
    A.ISI.EDU.      26.3.0.103
Ces informations spécifient les serveurs à essayer, leurs adresses, et un décompte de concordance à -1, qui indique que les serveurs ne sont pas "proches" de la cible. Notez que cette valeur -1 n'exprime pas une mesure précise de la "distance", mais juste une valeur conventionnelle sur laquelle se basera l'algorithme au départ.

Les exemples suivants illustrent l'utilisation de la méthode du cache et sa construction, et donc chaque étape suppose que la requête de l'étape précédente a été résolue. 

6.3.1. Résolution de MX pour ISI.EDU.

Supposez que la première demande au résolveur provienne de l'agent de courrier local, qui doit émettre un message à PVM@ISI.EDU. L'agent de courrier demande alors les RR MX pour le domaine ISI.EDU.

Le résolveur va d'abord chercher dans son cache des RR MX RR pour ISI.EDU, mais le cache est vide et cela ne résout rien. Le résolveur va en conclure qu'il doit contacter un serveur de nom distant et doit dans un premier temps déterminer quel est le meilleur serveur à contacter pour cette requête. Cette phase recherche dans le cache des RR NS pour le domaine ISI.EDU ou l'un de ses pères, EDU, et la racine. Le cache étant vide, ces recherches échoueront de la même manière. En dernier ressort, le résolveur va utiliser les informations de la structure SBELT, en les copiant dans la structure SLIST.

Arrivé à ce point, le résolveur devra choisir l'une des trois adresses disponibles et essayer une requête. Du fait que le résolveur est sur le réseau d'adresse 26, il choisira l'une des deux adresses 26.0.0.73 ou 26.3.0.103 en premier. Il émettra donc une requête de la forme : 

                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY                                     |
                 +---------------------------------------------------+
    Question     | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
                 +---------------------------------------------------+
    Réponse      | <vide>                                            |
                 +---------------------------------------------------+
    Autorisation |                                            |
                 +---------------------------------------------------+
    Additionnel  | <vide>                                            |
                 +---------------------------------------------------+
Le résolveur attendra pour cette requête soit une réponse, soit la durée d'une temporisation. Si la temporisation déclenche, il essayera le serveur suivant, ou une adresse différente pour le même serveur, et enfin en réessayant les adresses déjà tentées. Il pourra donc recevoir une réponse du serveur à SRI-NIC.ARPA: 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE                           |
                 +---------------------------------------------------+
    Question     | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
                 +---------------------------------------------------+
    Réponse      | <vide>                                            |
                 +---------------------------------------------------+
    Autorisation | ISI.EDU.        172800 IN NS       VAXA.ISI.EDU.  |
                 |                           NS       A.ISI.EDU.     |
                 |                           NS       VENERA.ISI.EDU.|
                 +---------------------------------------------------+
    Additionnel  | VAXA.ISI.EDU.   172800    A        10.2.0.27      |
                 |                 172800    A        128.9.0.33     |
                 | VENERA.ISI.EDU. 172800    A        10.1.0.52      |
                 |                 172800    A        128.9.0.32     |
                 | A.ISI.EDU.      172800    A        26.3.0.103     |
                 +---------------------------------------------------+
Le résolveur s'apercevra alors que la réponse propose une redirection vers un serveur plus "proche" d'ISI.EDU que ceux qu'il référence dans sa structure SLIST (du fait que trois identifiants correspondent). Le résolveur enregistrera cette information dans son cache et ajoutera ces références à sa SLIST : 
    Match count = 3
    A.ISI.EDU.      26.3.0.103
    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
    VENERA.ISI.EDU. 10.1.0.52       128.9.0.32
A.ISI.EDU apparaît dans cette liste ainsi que le précédent, bien qu'il ne s'agisse ici que d'une coïncidence. Le résolveur recommence la transmission de requêtes et attend des nouvelles réponses. Le cas échéant, il obtient une réponse : 
                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE, AA                       |
                 +---------------------------------------------------+
    Question     | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
                 +---------------------------------------------------+
    Réponse      | ISI.EDU.                MX 10 VENERA.ISI.EDU.     |
                 |                         MX 20 VAXA.ISI.EDU.       |
                 +---------------------------------------------------+
    Autorisation | <vide>                                            |
                 +---------------------------------------------------+
    Additionnel  | VAXA.ISI.EDU.   172800  A  10.2.0.27              |
                 |                 172800  A  128.9.0.33             |
                 | VENERA.ISI.EDU. 172800  A  10.1.0.52              |
                 |                 172800  A  128.9.0.32             |
                 +---------------------------------------------------+
Le résolveur ajoutera cette information à son cache, et renvoie le RR MX obtenu au client. 

6.3.2. Obtenir le nom d'hôte à partir de l'adresse 26.6.0.65

Le résolveur va traduire ceci en une requête sur des RR PTR pour le domaine 65.0.6.26.IN-ADDR.ARPA. Cette information n'est pas dans le cache, et donc le résolveur doit chercher un serveur distant auquel la demander. Aucun serveur du cache ne va correspondre, et il faudra exploiter les données de SBELT une fois encore. (Notez que les serveurs pour le domaine ISI.EDU sont bien mentionnés dans le cache, mais ISI.EDU n'est pas un "ancêtre" du domaine 65.0.6.26.IN-ADDR.ARPA, et donc SBELT sera réutilisé).

Comme l'information recherchée fait partie des données autorisées des deux serveurs mentionnés dans SBELT, l'un d'eux répondra certainement : 

                 +---------------------------------------------------+
    En-tête      | OPCODE=SQUERY, RESPONSE, AA                       |
                 +---------------------------------------------------+
    Question     | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
                 +---------------------------------------------------+
    Réponse      | 65.0.6.26.IN-ADDR.ARPA.    PTR     ACC.ARPA.      |
                 +---------------------------------------------------+
    Autorisation | <vide>                                            |
                 +---------------------------------------------------+
    Additionnel  | <vide>                                            |
                 +---------------------------------------------------+

6.3.3. Obtenir l'adresse de l'hôte du domaine poneria.ISI.EDU

Cette requête se traduira par un requête sur le type A pour le domaine poneria.ISI.EDU. Le résolveur ne tentera pas d'exploiter une quelconque donnée cachée pour ce nom, mais trouvera dans le cache les RR NS pour le serveur relatif à la zone ISI.EDU lorsqu'il y recherche des adresses de serveurs de noms distants. Avec ces données, il construira une SLIST de la forme : 
    Match count = 3

    A.ISI.EDU.      26.3.0.103
    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
    VENERA.ISI.EDU. 10.1.0.52
A.ISI.EDU est choisi en premier, en suivant le raisonnement que le résolveur utilise une méthode hiérarchique préférentielle , et du fait qu'A.ISI.EDU est sur le même réseau.

Un de ces serveurs doit pouvoir répondre à la requête.

Annonces