T.P N°3
Etude détaillée du protocole TCP
Principe :
Le but de
ce TP est de comprendre l’utilisation et le fonctionnement de l’application
réseau DNS (Domaine Name System).
Configuration de
la plate-forme :
Nous avons besoin de connecter un
PC au réseau du bâtiment afin de
pouvoir interroger les serveurs DNS d’Internet.
Devant nous connecter au réseau
de l’UFR un certain nombre d’adresse nous ont été affectées. Ces adresse sont
comprise entre 195.221.226.1 et 195.221.226.100.
L’adresse du routeur vers
l’extérieur ainsi que le serveur ufrima se
trouve sur le même réseau que les machines.
Câble
RJ45 simple
Pour que la machine A puisse communiquer avec les autres machines de l’UFR il est nécessaire de :
- Choisir une adresse non utilisé : 195.221.226.1
- Configurer l’interface de la machine avec la commande :
ifconfig
elxl0 plumb 195.221.226.1 up
-
Completer la
table de routage a l’aide de la commande :
route add 0.0.0.0 195.221.226.254–
netmask 0.0.0.0
La machine A peut à présent communiquer avec le réseau global.
I. Configuration
d’une machine utilisateur :
La consultation du fichier /etc/resolv.conf de la machine nous donne les données ci-dessous :
Domaine imag.fr
Nameserver 129.88.30.1
La réalisation de telnet sur les différents serveurs nous permet de consulter les informations contenues dans les fichiers resolv.conf de chaque serveur.
-
Kernighan (@IP : 195.221.225.6)
domain imag.fr
nameserver 195.221.225.1
Le serveur Kernighan appartient au domaine imag.fr et s’adresse a la machine d’@ IP 195.221.225.1 pour trouver les @IP correspondant aux noms donnés. C’est un client DNS.
-
Ritchie
domain imag.fr
nameserver 195.221.224.1 (ufrima-224.imag.fr)
nameserver 129.88.30.1 (ufrima.imag.fr)
Le serveur Ritchie appartient au domaine imag.fr et s’adresse aux machines d’@ IP 195.221.224.1 et 129.88.30.1 pour trouver les @IP correspondant aux noms donnés. C’est aussi un client DNS.
-
Ufrima (@IP : 195.221.225.1)
domain imag.fr
nameserver 129.88.30.1
nameserver 127.0. 0.1
Le serveur Ufrima appartient au domaine imag.fr et s’adresse a la machine d’@ IP 129.88.30.1 et 127.0.0.1 qui est l’adresse locale de la machine, pour trouver les @IP correspondant aux noms donnés. On peut donc en conclure que Ufrima est un serveur DNS. On remarque aussi que l’adresse du serveur DNS de Kernighan correspond aussi au serveur Ufrima.
- Boole (@IP : 195.221.225.1)
domain imag.fr
nameserver 129.88.30.1
nameserver 127.0.0.1
Le serveur Boole à la même @ IP que le serveur Ufrima de plus on trouve les même @ IP pour les noms de serveur DNS, on peut donc penser que Boole n’est en faite qu’un alias du serveur Ufrima.
Sur chaque serveur le domaine est imag.fr se qui fait que sur chaque machine un suffixe est ajouté sur les noms symboliques, le suffixe est du type :
<nom>.imag.fr
Le fichier /etc/hosts de ufrima n’est pas accessible, mais on sait qu’il contient toutes les adresses du domaine imag.fr.
Si on change le fichier /etc/resolv.conf de la machine utilisée par les informations ci-dessous :
domain imag.fr
nameserver 127.0.0.1
les pings vers boole et www ne marche plus. Tandis que les pings avec les @IP en decimal continu à marcher.
Le rajout de la ligne « hosts : files dns » dans le fichier /etc/nsswitch.conf l’utilisation des pings fonctionne.
On constate aussi que les majuscules ne sont pas significative dans les noms symbolique.
En conclusion de cette manipulation, on peut voir qu’une machine regarde en priorité dans son fichier /etc/hosts si elle possède une entrée correspondant au nom recherché. Dans le cas contraire, elle envoie une requête au serveur DNS dont elle possède l’@IP dans son fichier /etc/resolv.conf.
Cet ordre peut être modifié en changeant l’ordre des options après hosts dans le fichier /etc/nsswitch.conf.
On peut donc également en déduire que le serveur DNS possède les @IP associées aux noms symboliques dans son fichier /etc/hosts ou celui-ci est capable de contacter un autre serveur de nom qui pourra lui donner la réponse si la machine n’appartient pas à sa zone.
II. Interrogation
DNS :
Lors du lancement de la commande système nslookup qui permet de comprendre comment fonctionne l’application DNS en visualisant les paquets émis et reçus lors d’une interrogation, on voit apparaître le nom est l’@IP du serveur DNS auquel la machine va s’adresser pour effectuer les résolutions de noms. On obtient les lignes suivantes :
nslookup
Default Server : Brahma.imag.fr
Adress : 129.88.30.10
Brahma est donc le serveur DNS de l’UFR
On questionne le serveur DNS en donnant les noms pour lesquels on desire connître la correspondance.
-
toto : can’t find toto.imag.fr
-
ftp :
Server :
brahma.imag.fr
Address : 129.88.30.10
Name : brahma.imag.fr
Address : 129.88.30.10
Aliases ftp.imag.fr
L’adresse ftp correspond aussi au serveur DNS.
-
www :
Server :
brahma.imag.fr
Address : 129.88.30.10
Name : suprisette.imag.fr
Address :
Aliases : www.imag.fr
Le suffixe .imag.fr est ajouté a l’adresse donné.
-
www. : can’t find www.
Ici, le serveur DNS demande à la racine d’accéder à www mais il n’y a pas de machine appelée www à la racine.
- altavista : can’t find altavista
Ici, comme précédemment il n’y a pas de machine appelée altavista et il n’en trouve pas non plus une dans le domaine imag.fr.
- www.altavista.com :
Server :
brahma.imag.fr
Address : 129.88.30.10
Non-authoritative answer :
Name : altavista.com
Address : 209.73.180.8
Aliases : www.altavista.com
-
altavista.com
Server : brahma.imag.fr
Address : 129.88.30.10
Non-authoritative answer :
Name : altavista.com
Address : 20.9.73.164.90
Le ping sur www.multimania.com est normalement interdit et ne marche donc pas afin d’éviter la saturation du serveur de site par des boucles ping. Tandis que le ping marche sur www.caramail.com n’étant qu’un serveur de mail et donc non protégé.
III. Serveur de
zone DNS :
Pour connaître les serveurs DNS qui sont susceptibles de répondre à une requête pour une zone donnée, on utilise la commande nslookup et set q = ns.
Pour la zone racine (.) le test nous permet de trouver 13 serveurs DNS tandis que pour la zone fr., on trouve 8 serveurs DNS. L’intérêt d’en avoir un nombre assez important est que, d’une part, en cas de panne tout le réseau n’est pas bloqué, les autres serveurs pouvant prendre le relais et d’autre part que cela permet de désengorger ces serveurs ce qui permet de réduire les risques de collision. En effet on peut remarquer que l’ordre d’apparition de ces serveurs est aléatoire, ceci évitant que toutes les requêtes DNS se dirige vers le même serveur, ce qui le congestionnerait et abaisserait les performances pour le client.
Pour la zone imag.fr, il y a 4 serveurs DNS différents dont deux appartiennent à la zone imag.fr. De plus, il connaît déjà leur @IP. L’intérêt d’utiliser des serveurs DNS n’appartenant pas à la zone est que si un ensemble de machines du domaine tombe en panne, on peut toujours accéder aux autres machines.
En utilisant la commande ls on peut connaître la liste des machines gérées par un domaine. On trouve 3 machines dans le domaine imag.fr. Ces 3 machines connaissent les mêmes machines. En effet elles contiennent les mêmes informations dans leur cache pour le cas où la principale tombe en panne. En effet la machine principale est modifié manuellement puis elle transmet les informations aux autres serveurs.
Pour obtenir une réponse directe du serveur qui connaît la correspondance nom/adresse, il faut entrer la commande nslookup (set q = ns). On cherche ensuite les serveurs correspondants à la zone racine (.). Puis on tape « server <un des serveurs précédemment trouvés> » puis « www.altavista.com ». A ce moment la les paquets est directement envoyé au serveur donner lors de la commande précédente évitant ainsi un trafic trop important.
Non-authoritative answer signifie que la réponse obtenue provient du cache d’un des serveurs intermédiaires et non pas du serveur qui gère la zone à laquelle appartient le nom recherché.
IV. Les requêtes
DNS :
L’observation des types de requêtes DNS est réalisé grâce au mode debug sous nslookup. Pour cela on réalise l’ensemble des commande suivantes :
# nslookup
Default Server: ufrima-224.imag.fr
Address: 195.221.224.1
> set debug
> set q=a
> www.altavista.com
Autorisation du mode récursif
Server:
ufrima-224.imag.fr
Address: 195.221.224.1
;; res_mkquery(0, www.altavista.com, 1, 1)
------------
Got answer:
HEADER:
opcode = QUERY, id = 35880,
rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 11, authority records = 3,
additional = 3
QUESTIONS:
www.altavista.com, type = A,
class = IN
ANSWERS:
-> www.altavista.com
Type de l’interrogation
canonical
name = altavista.com
ttl = 533 (533)
-> altavista.com
internet address =
209.73.164.95
ttl = 600 (10M)
-> altavista.com
internet address =
209.73.164.96
ttl = 600 (10M)
-> altavista.com
internet address =
209.73.180.8
ttl = 600 (10M)
-> altavista.com
internet address =
209.73.180.9
ttl = 600 (10M)
-> altavista.com
internet address =
209.73.180.10
ttl = 600 (10M)
-> altavista.com
internet address =
209.73.164.90
ttl = 600 (10M)
-> altavista.com
internet address =
209.73.164.91
ttl = 600 (10M)
-> altavista.com
internet address =
209.73.164.92
ttl = 600 (10M)
-> altavista.com
internet address =
209.73.164.93
ttl = 600 (10M)
-> altavista.com
internet address =
209.73.164.94
ttl = 600 (10M)
AUTHORITY RECORDS:
-> altavista.com
nameserver =
NS2.altavista.com
ttl = 89485 (89485)
-> altavista.com
nameserver =
NS1.altavista.com
Serveur de la zone www.altavista.com
ttl = 89485
(89485)
-> altavista.com
nameserver =
NS3.altavista.com
ttl = 89485 (89485)
ADDITIONAL RECORDS:
-> NS2.altavista.com
internet address =
209.73.164.7
ttl = 89485 (89485)
-> NS1.altavista.com
internet address =
209.73.164.76
ttl = 89485 (89485)
-> NS3.altavista.com
internet address =
209.73.176.204
ttl = 89485 (89485)
------------
Non-authoritative answer:
Name: altavista.com
Addresses: 209.73.164.95,
209.73.164.96, 209.73.180.8, 209.73.180.9
209.73.180.10, 209.73.164.90, 209.73.164.91, 209.73.164.92,
209.73.164.93
209.73.164.94
Aliases: www.altavista.com
Il y a 14 machines correspondant au nom www.altavista.com contenue dans les parties ANSWER et ADDITIONAL RECORDS. Et 3 serveur dont les informations sont contenu dans la partie AUTHORITY RECORDS.
La liste des adresse des différentes machines www.altavista.com est décalé à chaque nouveau test , cela permet de ne pas interroger toujours la même machine et par conséquence de répartir les requêtes sur les différentes machines.
Les messages sont transporté par la couche de transport UDP.
De même on réalise les opérations sur la machine imag.fr.
On peut observer ci-dessous les paquets obtenus :
3 0.00804 195.221.226.1 -> brahma.imag.fr
ETHER Type=0800 (IP), size = 71 bytes
3 0.00804 195.221.226.1 -> brahma.imag.fr
IP D=129.88.30.10 S=195.221.226.1
LEN=57, ID=61625
3 0.00804 195.221.226.1 -> brahma.imag.fr
UDP D=53 S=33018 LEN=37
3 0.00804 195.221.226.1 -> brahma.imag.fr
DNS C ftp.imag.fr. Internet Addr ?
________________________________
4 0.03640 brahma.imag.fr -> 195.221.226.1
ETHER Type=0800 (IP), size = 224 bytes
4 0.03640 brahma.imag.fr -> 195.221.226.1
IP D=195.221.226.1 S=129.88.30.10 LEN=210, ID=17533
4 0.03640 brahma.imag.fr -> 195.221.226.1
UDP D=33018 S=53 LEN=190
4 0.03640 brahma.imag.fr -> 195.221.226.1
DNS R ftp.imag.fr. Internet CNAME brahma.imag.fr.
Comme la machine appartient au domaine du serveur DNS interrogé, il consulte son propre fichier /etc/hosts. On peut donc dire que c’est une réponse « non-authoritative ».
Seul le serveur brahma a été interrogé, ceci a été réalisé à l’aide de 2 paquets DNS / UDP, mais normalement 2 paquets ARP aurait du être envoyé au débuts.
On recherche maintenant la machine truc en ré interrogant le serveur :
3 3.72176 195.221.226.1 ->
brahma.imag.fr ETHER Type=0800 (IP), size = 72 bytes
3 3.72176 195.221.226.1 ->
brahma.imag.fr IP D=129.88.30.10
S=195.221.226.1 LEN=58, ID=57195
3 3.72176 195.221.226.1 ->
brahma.imag.fr UDP D=53 S=33021 LEN=38
3 3.72176 195.221.226.1 ->
brahma.imag.fr DNS C truc.imag.fr. Internet Addr ?
________________________________
4 0.00216 brahma.imag.fr ->
195.221.226.1 ETHER Type=0800 (IP), size = 134 bytes
4 0.00216 brahma.imag.fr ->
195.221.226.1 IP D=195.221.226.1
S=129.88.30.10 LEN=120, ID=13013
4 0.00216 brahma.imag.fr ->
195.221.226.1 UDP D=33021 S=53 LEN=100
4 0.00216 brahma.imag.fr ->
195.221.226.1 DNS R Error: 3(Name
Error)
________________________________
5 0.00092 195.221.226.1 ->
brahma.imag.fr ETHER Type=0800 (IP), size = 64 bytes
5 0.00092 195.221.226.1 ->
brahma.imag.fr IP D=129.88.30.10
S=195.221.226.1 LEN=50, ID=57196
5 0.00092 195.221.226.1 ->
brahma.imag.fr UDP D=53 S=33022 LEN=30
5 0.00092 195.221.226.1 ->
brahma.imag.fr DNS C truc. Internet Addr ?
________________________________
6 0.00170 brahma.imag.fr ->
195.221.226.1 ETHER Type=0800 (IP), size = 139 bytes
6 0.00170 brahma.imag.fr ->
195.221.226.1 IP D=195.221.226.1
S=129.88.30.10 LEN=125, ID=13014
6 0.00170 brahma.imag.fr ->
195.221.226.1 UDP D=33022 S=53 LEN=105
6 0.00170 brahma.imag.fr -> 195.221.226.1 DNS R Error: 3(Name Error)
Plusieurs essais sont réalisés dans ce cas, on interroge d’abord le serveur brahma en lui donnant l’adresse truc.imag.fr, celui-ci lui répond qu’il ne connaît pas la machine, la requête est alors renvoyée par notre machine sur le domaine . qui nous renvoi à son tour qu’il ne connaît pas la machine truc.
Il existe différent type d’interrogation, on va donc les tester tour à tour ces types de querry :
- Liste de serveurs de noms associée à une zone (q = ns)
En zone racine, on trouve 13 serveurs cache dont 4 où on trouve la correspondance dans leur fichier /etc/hosts.
En zone fr, il y a uniquement 8 serveurs cache.
- Serveur de courrier (q = mx)
En zone imag.fr., il y a 3 serveurs MX, chacun ayant une priorité d’accès pour indiquer quel est le serveur principal. Cette configuration est mise en place pour éviter les échecs d’envoi et des pertes de mails en cas de panne.
En zone fr., il n’y en a pas.
- Nom canonique (q = cname)
La machine boole a pour nom canonique ufrima.imag.fr.
La machine Kernighan a pour nom canonique Kernighan. Grâce à ce type de requête on peut donc connaître le véritable nom de la machine.
- Interrogation inverse : nom associé à une adresse (q = a)
L’@ 192.9.9.1 correspond au nom sun-barr.sun.com et l’@ à dns.inria.fr.
Le type des questions est A c’est à dire @IP ® Nom.
Les serveurs qui envoient les réponses sont des serveurs relais ou cache.
Pour ce type d’interrogation, la base de données est répartie par zone.
Serveur DNS
Zone de chaque
serveur DNS
Chaque serveur DNS connaît et est responsable de toute sa zone.
V. Configuration
d’un serveur DNS :
A.
Observation des fichiers de configuration :
L’installation d’un serveur DNS nécessite la création de fichiers de configuration contenant à l’application DNS serveur de faire son travail.
On se connecte donc au serveur de l’UFR-IMA pour consulter ces fichiers.
Fichier root.cache :
more root.cache
; <<>> DiG 8.1 <<>> @b.root-servers.net . ns
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;; ., type = NS, class = IN
;; ANSWER SECTION:
. 6D IN
NS M.ROOT-SERVERS.NET.
. 6D IN
NS I.ROOT-SERVERS.NET.
. 6D IN
NS E.ROOT-SERVERS.NET.
. 6D IN
NS D.ROOT-SERVERS.NET.
. 6D IN
NS A.ROOT-SERVERS.NET.
. 6D IN
NS H.ROOT-SERVERS.NET.
. 6D IN
NS C.ROOT-SERVERS.NET.
. 6D IN
NS G.ROOT-SERVERS.NET.
. 6D IN
NS F.ROOT-SERVERS.NET.
. 6D IN
NS B.ROOT-SERVERS.NET.
. 6D IN
NS J.ROOT-SERVERS.NET.
. 6D IN
NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
M.ROOT-SERVERS.NET. 5w6d16h
IN A 202.12.27.33
I.ROOT-SERVERS.NET. 5w6d16h
IN A 192.36.148.17
E.ROOT-SERVERS.NET. 5w6d16h
IN A 192.203.230.10
D.ROOT-SERVERS.NET. 5w6d16h
IN A 128.8.10.90
A.ROOT-SERVERS.NET. 5w6d16h
IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h
IN A 128.63.2.53
C.ROOT-SERVERS.NET. 5w6d16h
IN A 192.33.4.12
G.ROOT-SERVERS.NET. 5w6d16h
IN A 192.112.36.4
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
B.ROOT-SERVERS.NET. 5w6d16h
IN A 128.9.0.107
J.ROOT-SERVERS.NET. 5w6d16h
IN A 198.41.0.10
K.ROOT-SERVERS.NET. 5w6d16h
IN A 193.0.14.129
L.ROOT-SERVERS.NET. 5w6d16h
IN A 198.32.64.12
;; Total query time: 176 msec
;; FROM: horus.imag.fr to SERVER: b.root-servers.net 128.9.0.107
;; WHEN: Wed Aug 11 15:22:12 1999
;; MSG SIZE sent: 17 rcvd: 436
Ce fichier indique quels sont les différents serveurs de la zone imag.fr.
Fichier name.conf :
// generated by named-bootconf.pl
// @(#)named.conf 97/05/29 BRAHMA
// boot file for secondary
name server
include "/etc/rndc.key";
controls {
inet * allow { localhost;
129.88.30.1; } keys { rndc_key; };
};
options {
directory
"/var/spool/named";
auth-nxdomain no;
// forwarders {
147.171.130.1; };
// forwarders { 129.88.30.1;
129.88.32.24; };
};
// Note: the following will be supported in a future release.
// host { any; } {
// topology { 129.88.0.0/8;
};
// };
zone "0.0.127.in-addr.arpa" { type master;
file
"rev.127.0.0";
};
zone "imag.fr" {
type slave;
file "imag.fr.bk";
masters { 129.88.30.1; };
};
zone "ujf-grenoble.fr" { type slave;
file
"ujf-grenoble.fr.bk";
masters { 193.54.232.33;
129.88.30.1; 152.77.6.1; 193.54.238.24; 193.54.238.22; 193.54.232.78; }; // imag.imag.fr, ujf-iab adm
};
zone "88.129.in-addr.arpa" { type slave;
file
"129.88.bk";
masters { 129.88.30.1; };
};
zone "77.152.in-addr.arpa" { type slave;
file
"152.77.bk";
masters { 129.88.30.1; };
};
……………
zone "72.77.152.in-addr.arpa" { type slave;
file
"152.77.72.bk";
masters { 129.88.30.1; };
};
zone "200.77.152.in-addr.arpa" { type slave;
file
"152.77.200.bk";
masters { 129.88.30.1; };
};
zone "201.77.152.in-addr.arpa" { type slave;
file
"152.77.201.bk";
masters { 129.88.30.1; };
};
zone "." { type
hint;
file "root.cache";
};
Ce fichier contient l’ensemble des fichiers contenu sur le serveur permettant de connaître pour chaque sous réseaux l’ensemble de correspondance et des adresses réseaux de ce sous réseaux.
Par exemple :
zone "88.129.in-addr.arpa" { type slave;
file "129.88.bk";
masters { 129.88.30.1; };
};
Ces lignes permette de savoir que toutes les adresse 129.88. … . … sont contenu dans le fichier appelé 129.88.bk Ces fichiers sont mis à jours plusieurs fois par jour et proviennent du serveur imag.imag.fr (@IP 129.88.30.1).
Le serveur principal est marqué avec le type master, on peut voir que l’adresse 127.0.0 qui correspond a lui-même, ufrima est donc le serveur principal de la zone imag.fr, tandis que les secondaire sont ceux marqué en slave comme par exemple imag.fr et ujf-grenoble.fr.
B.
Configuration d’un serveur DNS :
Pour configurer la machine B pour qu’elle devienne elle-même son serveur DNS, on va dans le fichier resol.conf de la machine B et on le modifie pour avoir ceci :
nameserver @machineB
Pour configurer le serveur DNS, on doit en plus récupérer les fichiers :
/etc/rndc.key
/etc/rndc.conf
Mais la configuration ne marche pas.
En effet, il y a un problème car en lançant le démon sur la machine B, on ne récupère pas le fichier imag.fr.zone.
En capturant les paquets sur le réseau, on constate toujours les mêmes paquets DNS correspondants à une question et ayant pour adresse source l’adresse de la machine B et pour adresse destination l’adresse 129.88.30.1.
Le contenu du paquet DNS est le suivant :
Domain Name : imag.fr Class : 1 ( Internet ) Type : 2 ( Authoritative Name Server )
La machine ne reçoit jamais de réponse.
C.
Création d’un nouvelle zone :
Tout d’abord on modifie les fichiers host des machines A, B et C.
On modifie ensuite le fichier mazone.fr.bk de la machine B en rajoutant :
$ORIGIN
mazone.fr. B 7200 IN NS 195.221.226.50 B 7200 IN A 195.221.226.50 A 7200 IN A 195.221.226.51 C 7200 IN A 195.221.226.52
On modifie ensuite le fichier /etc/named.conf de la machine B en rajoutant :
Zone “mazone.fr” { type
slave ; file “mazone.fr.bk” ; masters { 129.88.30.1; } };
On va ensuite dans le fichier resolv.conf de la machine C et on le remplie avec les lignes suivantes :
search
mazone.fr nameserver
moi.mazone.fr
Lorsqu’on lance nslookup, la machine n’arrive pas a trouver le serveur.
On se trouve à nouveau confronté au même problème que dans la question 5.2. .
La configuration du serveur DNS et la création d’une nouvelle zone ont échoué.