ERREUR lors de requête DNS de type A à un serveur DNS:

Constitution de la trace

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

Pourquoi cet échange?

Au niveau de la machine 10.40.5.2, on ouvre un terminal et on tape

ping smtp.ent2.com

Que se passe-t-il ?

Trame 1

recherche adresse de smtp.ent2.com

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

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 smtp.ent2.com)
questions: 1
answer RRs: 0
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 smtp.ent2.com, 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)

recherche smtp.ent2.com.ent2.com

Trame 4

Evidemment, le Serveur DNS répond en recopiant la question mais en y incluant pas de réponse..
Cepandant dans ce message, il inclut un "authority RRs: 1"
questions: 1
answer RRs: 0
authority RRs: 1
reply code: 3

Cet authority RR contient éventuellement le nom d'un autre serveur DNS "ayant authorité dans la zone" afin que la recherche puisse être effectuée par le client sur cet autre serveur.

Ce n'est pas le cas, je n'ai installé qu'un serveur DNS dans ent2, c'est pour cela que l'on obtient un seul autority RR

Interet de cette trace

• On observe le cas ou une résolution ne marche pas.
• 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 le domaine (evidemment)
  

Par exemple: serveur.ent2.com et serveur.core2.com par exemple auraient été resolu alors que serveur seul non.

• On voit que authority RRs apparait afin de permettre au client de reiterer sa requete au serveur ayant autorité dans la zone, le cas échéant il sait que smtp.ent2.com n'existe pas.

En réalité

Voilà, par le hazard, comment obtenir une trace interessante :)
J'avais oublié d'ajouter ce serveur dans la base

Mais je l'ai fait par la suite, heureusement, pour configurer un client mail, c'est plus simple :-)