TD réseau: DNS
Exercice 1 dns
L'outil host accessible en ligne sous linux vous permet d'effectuer des requetes dns. Il est possible de préciser le RR demander en utilisant l'option -t. Exemple: host -t NS google.fr : liste des dns du domaine google.fr. On peut aussi utiliser l'outil nslookup disponible sous windows avec la syntaxe suivante : nslookup -querytype=NS google.fr. Vous pouvez aussi utiliser l'outil dig sous linux s'il est installé. Utilisez l'un de ces outils pour :
● trouver l'adresse ip de la machine ns-quad.ibisc.fr
● ftp.shayol.org est un alias (CNAME). Quel est le nom canonique de cette machine ?
● donnez son adresse IP.
● que vous inspire 52.90.199.194.in-addr.arpa. ?
● quel est le relais de courrier entrant du domaine univ-evry.fr ?
● quel est le numéro de série de la zone ibisc.fr ?
● Quels sont les serveurs dns de la zone ibisc.fr ? donnez aussi leur adresse ip. faites plusieurs fois la requête pour trouver les dns de la zone ibisc.fr. Que remarquez-vous ?
Eléments de correction :
$ host -t A ns-quad.ibisc.fr
ns-quad.ibisc.fr has address 195.221.162.126
$ host -t CNAME ftp.shayol.org
ftp.shayol.org is an alias for abbadingo.shayol.org.
$ host -t A abbadingo.shayol.org.
abbadingo.shayol.org has address 88.176.64.22
# ou d'un seul coup :
$ host ftp.shayol.org
ftp.shayol.org is an alias for abbadingo.shayol.org.
abbadingo.shayol.org has address 88.176.64.22
abbadingo.shayol.org mail is handled by 0 abbadingo.shayol.org.
# 52.90.199.194.in-addr.arpa. : on reconnaît une entrée inversée (adresse → nom avec
l'adresse écrite à l'envers sous l'arborescence in-addr.arpa). On cherche donc le nom associé à 194.199.90.52.
# on demande explicitement l'enregistrement PTR
$ host -t PTR 52.90.199.194.in-addr.arpa.
52.90.199.194.in-addr.arpa domain name pointer hyperion2.univ-evry.fr.
# la commande host peut prendre aussi comme argument l'ip directement :
$ host 194.199.90.52
52.90.199.194.in-addr.arpa domain name pointer hyperion2.univ-evry.fr.
$ host -t MX univ-evry.fr
univ-evry.fr mail is handled by 10 smtp.univ-evry.fr.
# un seul MX pour l'université d'Evry. Il n'y a pas de serveur de courrier entrant de secours (c'est conforme aux bonnes pratiques actuelles : si le serveur est HS, les émetteurs essaieront durant un certain temps d'envoyer leurs messages, 4h00 en général)
# une requête avec un site qui a plusieurs MX. On notera que la liste est triée par poids croissants. L'émetteur essaiera le premier puis le 2e puis le 3e, … (encore que le standard précise qu'il faut en essayer au moins 3 mais n'impose pas d'en essayer plus).
$ host -t MX gmail.com
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 20 alt2.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 30 alt3.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 40 alt4.gmail-smtp-in.l.google.com.
# le No de série est une valeur qui augmente à chaque modification de la zone.
# cette valeur est stockée dans l'enregistrement SOA (start of authority)
# au moment où j'ai écrit ces éléments de correction, le No de série valait 2013092001 (donc modif le 20/09/2013)
$ host -t SOA ibisc.fr
ibisc.fr has SOA record ns-quad.ibisc.fr. hostmaster.ibisc.fr. 2013092001 28800 7200 604800 86400
$ host -t NS ibisc.fr
ibisc.fr name server gip.u-picardie.fr.
ibisc.fr name server ns-quad.ibisc.fr.
#si on fait plusieurs requête, on remarque que la liste n'est pas le même ordre.
# c'est une méthode naïve pour répartir les requêtes sur les serveurs de noms de la zone
# un serveur qui a l'information en cache fera de même en interrogeant à chaque fois un serveur différent.
$ host gip.u-picardie.fr.
gip.u-picardie.fr has address 193.49.184.17
$ host ns-quad.ibisc.fr.
ns-quad.ibisc.fr has address 195.221.162.126
ns-quad.ibisc.fr mail is handled by 0 ns-quad.ibisc.fr.
$ host -t NS ibisc.fr
ibisc.fr name server ns-quad.ibisc.fr.
ibisc.fr name server gip.u-picardie.fr.
$ host -t NS ibisc.fr
ibisc.fr name server gip.u-picardie.fr.
ibisc.fr name server ns-quad.ibisc.fr.
Exercice 2 dns: analyse de trames
fichier dns-pp.cap:
● trames 3: quel objet ? de qui à qui ?
● trames 6 à 12: expliquez l'enchaînement.
● quel est le routeur utilisé par le poste 192.168.0.237 ?
● trames 15 à 20: mettre en relation les questions et les réponses (qui répond à qui ?)
● comparez le processus des trames 73 à 76 avec celui des trames 6 à 12 puis avec celui des trames 83 à 88.
éléments de correction :
trame 3: de 192.168.0.15 à 192.168.0.237. requete récursive. Probablement d'un client à son serveur dns de site
trame 6 à 12: faire les liens entre requetes et réponse, trouver les noms des serveurs interrogés, noter que l'interrogation est itérative:
• trame 6 interrogation des serveurs racines qui fournissent les serveurs de fr. en réponse (trame 7)
• trame 8: interrogation des serveurs de fr. qui fournissent les serveurs de lip6.fr. En réponse (trame 9)
• trame 10: interrogation des serveurs de lip6.fr qui fournissent la réponse (trame 11)
• trame 12: réponse donnée au poste client (répond à la trame 3)
les trames 4 et 5 sont une requete ARP pour connaître l'adresse MAC de 192.168.0.254. D'un point de vue couche liaison, la trame 6 est tranmise à l'adresse MAC obtenue en trame 5 qui est probablement l'adresse du routeur du poste : 192.168.0.254 car différente de l'ip
destination de la trame 6.
trames 15 à 20: on utilise le champ transaction Id pour mettre en relation question et réponse.
Trames 73 à 76 et 83 à 88: on note l'effet du cache : la recherche ne repart pas de la racine mais du niveau le plus bas connu: lip6.fr dans le premier cas, fr. dans le second.
fichier dns-ixfr.cap:
● expliquez le processus en jeu dans les trames 3 à 6.
éléments de correction :
Après avoir été notifié, le serveur esclave se passe de requête SOA et fait une demande de transfert de zone. Là, c'est un transfert incrémental (IXFR) qui ne transfert que ce qui a changé entre le No de série actuel de la zone et celui transmis par le serveur esclave dans la requête IXFR.
