= ERREUR lors de requête DNS de type A puis succès: =

== Constitution de la trace ==

On observe un échange de trames reposant sur ETHERNET-IP-UDP-DNS[[BR]]
2 types de messages échangés: Query A et Query response.

== Pourquoi cet échange? ==

Lors d'un accès via Telnet au switch de l'as 65004(adresse 10.40.3.1), on tape 
{{{
#!rst
ping serveur3
}}}

== Que se passe-t-il ? ==

=== Trame ''1'' ===
{{{
#!rst
recherche adresse de serveur3
}}}

Les flags DNS révèlent:[[BR]]
questions: 1 (oui questions, pas requêtes, car il peut y avoir des requête de questions et des requêtes de réponses :-) )[[BR]]
answer RRs: 0 [[BR]]

Après ces flags, on trouve la "query", requete, "nom recherché, le type de requete, et la classe (pour nous çà sera toujours IN pour internet"

=== Trame ''2'' ===

Le Serveur DNS répond en recopiant la question mais en y incluant pas de réponse.. (il ne connait pas serveur3)[[BR]]
questions: 1[[BR]]
answer RRs: 0 [[BR]]
reply code: 3 => no such name... (nom non trouvé)

=== Trame ''3'' ===

La machine n'ayant pas eu de réponse, avec un flag no such name, il sait que le serveur ne connait pas serveur3, il renvoie une trame en ajoutant le nom de domaine au nom de la machine dont il demandait l'adresse ( ping fait çà sans que l'utilisateur ne le sache)[[BR]]
{{{
#!rst
recherche serveur3.ent2.com
}}}



=== Trame ''4'' ===

Le Serveur DNS répond en recopiant la question et en y incluant une réponse. [[BR]]

questions: 1[[BR]]
answer RRs: 1 [[BR]]
authority RRs: 0 [[BR]]
reply code: 3[[BR]]

La réponse est donnée après avoir répété la question (pour éviter les ambiguités dûes à des requêtes en parallèle) de la forme: "nom, type, classe" avec nom= nom de la machine, type= type de requète dns (ici A pour adresse de machine) et classe= in pour internet. 

Et dans la réponse le serveur dns donne les informations dans l'ordre: nom, type, class, ttl, taille de donnée, addresse. Donc idem pour les premiers champs sauf pour ttl qui indique combien de temps l'information fournie peut etre gardé en cache, taille de donnée: taille de l'information fournie et enfin l'information, ici l'adresse de serveur3.ent2.com 

== Interet de cette trace ==

 * On observe le cas ou une résolution d'adresse fonctionne.
 * On voit que si on fait une requete sans recevoir de réponse, il considère que sa requête est ambigüe et alors il essaie de la rendre plus precise en y ajoutant le ajoutant le nom de domaine.. Ceci est prudent si 2 machines ont le meme nom mais pas dans la même zone(evidemment) [[BR]]
Par exemple: serveur.ent2.com et serveur.core2.com par exemple auraient été resolu alors que serveur seul non.
 * On voit la structure de réponse DNS pour une requete de type A