Documente Academic
Documente Profesional
Documente Cultură
1. Rappels
A l’initialisation (boot time), le noyau essaie de détecter la localisation du ou des périphériques
physiques réseau. Pour pouvoir se servir d’une carte physique, des fonctions spécifiques, sachant
accéder au périphérique sont présentes dans le noyau. La partie logicielle qui implémente ces fonctions
s’appelle pilote (driver).
Pour masquer la variété des équipements réseaux, TCP/IP définit une interface abstraite lui donnant
accès au matériel. Elle offre une série de fonctionnalités identiques pour toutes les catégories de
matériels, dont la tâche essentielle est l’émission et la réception de paquets. Tout périphérique réseau a
son interface au sein du noyau. Les interfaces Ethernet sous Linux ont pour noms eth0, eth1.
L’affectation des interfaces aux périphériques est tributaire de l’ordre dans lequel les composants ont été
configurés. Ces noms d’interface sont utilisés uniquement à des fins de paramétrage pour préciser un
dispositif physique particulier dans une commande de configuration.
lo est l’interface de rebouclage (loopback)locale. Elle sert aux essais et à quelques applications réseaux.
Elle permet à une machine d’établir une communication TCP/IP avec elle-même. Il y a toujours une
interface loopback configurée dans un noyau.
2.1.Nom d’hôte
La majeure partie des applications réseaux se base sur le fait qu’un nom d’hôte est attribué à l’hôte local
en fonction de normes satisfaisantes. En effet, les machines sont généralement identifiées au moyen de
noms « ordinaires » dont les utilisateurs s’accommodent mieux. L’attribution des noms d’hôte est à la
charge de l’administrateur du réseau. Cette attribution se fait au moment du processus d’initialisation en
exécutant la commande hostname. Cette commande permet aussi de vérifier le nom d’hôte. Quel est le
nom d’hôte de votre machine ?
[login@ippcxxxlogin]$ hostname
Le nom d’hôte est également obtenu en exécutant la commande uname qu’il est préférable d’utiliser.
Cette commande permet d’afficher des informations système dont le nom d’hôte. En utilisant la page du
manuel en ligne (commande man) exécuter uname avec l’option permettant d’afficher le nom d’hôte.
[login@ippcxxxlogin]$ uname -a
2.2.Adresse IP
L’adresse IP associé au nom d’hôte local figure dans le fichier /etc/hosts. Ce fichier contient une liste
d’adresses IP et les noms des machines correspondantes. Le plus souvent, /etc/hosts ne renferme que les
entrées de l’hôte local et de quelques ordinateurs « importants » comme le serveur de noms (DNS) ou de
la (ou des) gateway(s). Historiquement, l’examen de ce fichier a été le premier procédé de résolution de
noms. Le procédé actuellement en vigueur utilise une base de données distribuée appelés DNS (Domain
Name Server). Cependant, la présence de ce fichier s’avère toujours utile même en l’absence d’interface
active (comme au démarrage) puisqu’il permet d’utiliser des noms symboliques (ou alias) dans les
scripts rc. Il permet également d’appliquer aisément les modifications d’adresses IP liées à une
renumérotation du réseau. Il suffit de mettre à jour le fichier hosts, de le dupliquer sur les machines du
réseau et de redémarrer ces dernières.
Editer le fichier /etc/hosts. Quelle(s) entrée(s) aurai(en)t été présente(s) si l’hôte n’était pas configuré
pour être en réseau ?
Comme dans le cas des hôtes, un nom symbolique peut être utilisé pour les réseaux. Le fichier
/etc/networks est le pendant du fichier hosts : il fait correspondre aux noms de réseaux leur adresse
(numéro). Editer le fichier /etc/networks.
Un nom symbolique a-t-il été assigné au réseau local ? Si oui, lequel ?
2.3.Configuration de l’interface IP
TCP/IP est flexible en ce sens qu’il peut fonctionner au-dessus de différents réseaux physiques. De ce
fait, il est nécessaire d’indiquer à TCP/IP les interfaces qu’il peut utiliser et de définir les
caractéristiques de chacune de ces interfaces. Contrairement à Ethernet dont les adresses et les
caractéristiques sont déterminées physiquement par le matériel (carte Ethernet), l’attribution des
adresses IP aux interfaces réseaux ainsi que leurs spécifications sont faites par voie logicielle et sont à la
charge des administrateurs systèmes.
Exécutée au démarrage, la commande ifconfig permet de spécifier à TPC/IP chacune des interfaces
réseaux présentes dans le noyau et de leur assigner une adresse IP, le masque et l’adresse de diffusion
(broadcast) du sous-réseau local. Sans argument, ifconfig affiche l’état des interfaces actives. Exécutée
avec l’argument -a, elle affiche les états de toutes les interfaces, y compris celles qui ne sont pas actives
(down) à cet instant. La syntaxe de cette commande est :
Le routage indirect : intervient lorsque la destination n’est pas connectée au même réseau physique que
la source. La transmission du paquet est alors effectuée de proche en proche (hop by hop) : le routage IP
fournit l’adresse du routeur de saut suivant qui se trouve être la gateway la plus proche de la destination.
Les tables de routage IP ne contiennent la route complète d’aucune destination.
Figure 2 : Routage IP indirect
La commande route permet de rajouter ou de retrancher manuellement des routes statiques dans la table
de routage du noyau via une interface juste après qu’elle ait été configurée avec ifconfig. La syntaxe
de cette commande est la suivante :
route add [-net|-host] target [netmask Nm] [gw Gw] ... [[dev] interface]
route del [-net|-host] target [gw Gw] [netmask Nm] ... [[dev] interface]
Les arguments de -net et -host indiquent à la commande si la destination (target) de cette route est un
réseau ou un hôte. target spécifie l’hôte ou le réseau destination joignable via cette route. Elle peut être
spécifiée par son adresse IP ou par son nom s’il figure dans les fichiers /etc/hosts ou /etc/network. Si le
mot-clef default est utilisé comme destination, la commande route crée une route par défaut. L’adresse
réseau destination associée alors à la route par défaut est 0.0.0.0. La route par défaut est utilisée si
aucune autre route de la table de routage n’existe pour une destination donnée. Elle permet de cacher des
informations de topologie du réseau et de réduire la taille des tables de routage en agrégeant plusieurs
entrées en une seule. S’il est nécessaire de préciser le masque de la destination, l’adresse du masque est
précédée du mot-clef netmask. Le mot-clef optionnel gwindique que l’argument qui suit est l’adresse du
routeur de saut suivant (next hop router) appelé aussi passerelle (gateway). Si la destination est ou
appartient au même réseau physique (routage direct), la commande route est exécutée sans argument
gateway de spécifié (un astérisque ou l’adresse par défaut 0.0.0.0 remplace alors l’adresse du routeur de
saut suivant). Si la destination n’appartient pas au même réseau physique (routage indirect), est spécifiée
après gw l’adresse de la gateway la plus proche de la destination. dev force l’association de la route
créée à l’interface spécifiée.
La syntaxe de la commande route indique que l’argument interface est optionnel. Comment le noyau
détermine-t-il à quelle interface associée la route (Pourquoi/Comment le noyau peut-il s’en passer) ?
Le noyau vérifie si la destination est directement accessible via l’une des interfaces déjà configurée
(comparaison entre l’adresse destination (target) et l’adresse réseau de l’interface). Si une des interfaces
partage le même préfixe avec la destination, la route est alors associée à cette interface. Exemples :
Donner la ligne de commande qui permet de créer l’entrée de la table de routage qui permet de joindre
localhost (127.0.0.1) :
Invoquée sans arguments, la commande route affiche la table de routage complète du noyau (-n permet
d’afficher les adresses en notation décimale pointé à la place des noms d’hôtes).
Donner la ligne de commande pour créer l’entrée de la table de routage qui permet de faire connaître au
noyau le réseau accessible par l’interface eth0 :
route add -net 132.227.61.0 qui est ajouté par défaut par ifconfig
Donner la ligne de commande qui a permis de créer l’entrée correspondant à la route par défaut :
Constater qu’encore une fois il n’est pas nécessaire de spécifier l’interface. L’adresse IP de la gateway et
l’adresse IP de l’interface eth0 qui vient d’être configurée partagent le même préfixe /24.
Quelles sont les adresses IP à la place desquelles le nom d’hôte aurait pu être utilisé ? Pourquoi ?
Exécutée avec l’argument -F, la commande route affiche la table de routage du noyau (ou FIB
Forwarding Information Table). L’argument -C affiche le cache de routage maintenu par le noyau. Il
s’agit d’une table de hachage où le noyau enregistre les routes en cours d’utilisation ou récemment
utilisées. Elle permet d’accélérer le processus de routage.
Afficher la FIB et le cache de routage. Quels sont les types de routes que contient le cache de routage.
Expliquer la présence de ces types de routes.
[antigone ~]$/sbin/route -C
Kernel IP routing cache
- celles dont la source est antigone.lip6.fr. Toutes ces routes sont associées à eth0. Il s’agit des routes
récemment (empruntées par les paquets émis sur le réseau) utilisées pour envoyer des paquets sur le
réseau. Leur destination est donnée par la colonne destination. La colonne use donne le nombre de
lookup à chacune des routes cachées
La commande netstat est un outil utile pour contrôler la configuration d’un réseau et son activité.
Invoquée avec l’argument -r, netstat affiche la table de routage de la même manière que route [-F].
La première colonne indique la destination que permet de joindre cette entrée. Il peut s’agir d’une
adresse complète d’hôte ou de réseau.
La seconde colonne indique l’adresse du routeur de saut suivant. Si la destination correspond au réseau
local (est un hôte ou à un réseau directement accessible par une interface locale), apparaît 0.0.0.0 ou un
astérisque.
Les trois colonnes suivantes sont des paramètres appliqués aux connexions TCP établies via cette route.
0 signifie que la valeur par défaut est retenue. (MSS = Maximum Segment Size, Window = fenêtre de
reception de l’hôte, irtt = initial round trip time)
La dernière colonne indique l’interface sur laquelle le paquet doit être transmis pour suivre cette route.
Utiliser avec l’option -i, nestat affiche les statistiques des interfaces réseaux configurées. L’option -s
affiche un résumé des statiques pour chaque protocole.
A l’aide des statistiques de l’interface eth0, calculer le taux de collision observé par l’hôte ?
Exécuter netstat -i.
Sachant qu’un taux de collision dont la valeur excède 3% traduit une surcharge du réseau local (charge
normale si inférieur à 1%), commenter la charge du réseau ? quelle mesure prendre pour réduire la
charge du réseau ?
Envisager la subdivision du réseau.
La diffusion est trop coûteuse pour être utilisée à chaque fois qu’une machine désire transmettre un
paquet à une autre. La cache ARP évite aux machines connectées au réseau de traiter la requête diffusée
et réduit le coût en bande passante de la diffusion.
La commande arp affiche (sans argument ou option -a) ou modifie le contenu du cache ARP.
Consulter la page du manuel en ligne et donner la ligne de commande qui permet de créer manuellement
une entrée permanente faisant correspondre l’adresse IP de la gateway du réseau local à son adresse
physique :
Vérifier que l’entrée a bien été créée. Comment distinguer les entrées permanentes ?
Les entrées permanentes sont marquées du drapeau M. (Les entrées temporaires sont seulement
marquées du drapeau C).
3. DNS et Solveur
3.1. Domaine Name System
Le DNS (Domaine Name Server) est un schéma de nommage hiérarchique fondé sur la notion de
domaine et une base de données répartie utilisée par les applications TCP/IP pour résoudre les noms
d’hôtes. La hiérarchisation de l’espace de nommage permet de distribuer la résolution et l’attribution des
noms d’hôtes à plusieurs autorités tout en garantissant l’autonomie de chaque autorité et en préservant
l’unicité des noms d’hôte attribué. Elle est adaptée à un grand espace d’adressage en expansion rapide
telle que celui d’Internet.
Schéma de nommage hiérarchique
Les processus d’attribution (naming) et de résolution d’un nom[2] sont décentralisés et hiérarchisés :
l’autorité mère (chargée d’attribuer les noms d’hôte) divise l’ensemble des noms qui peuvent être
assignés (ou espace d’adressage name space) en sous-ensembles disjoints appelés domaines (domains).
Cette partition permet à l’autorité mère de déléguer l’attribution et la résolution des noms d’hôte d’un
domaine à des autorités filles (la gestion de chaque domaine est déléguée à des autorités filles). Celles-ci
jouent alors à leur tour le rôle d’autorité mère en divisant l’espace de noms associé à leur domaine, et
ainsi de suite. A chaque étape, l’autorité mère assigne à chacune de ses filles un suffixe unique. Cette
organisation hiérarchique peut être représentée par une arborescence(cf. figure 3). Les domaines de haut
niveau sont de deux types : générique et géographique. Chaque domaine est désigné par le chemin à
suivre pour joindre la racine, les différents composants étant séparés par des points. Les noms de
domaines peuvent être absolus ou relatifs. Un nom de domaine absolu (ADN) ou pleinement qualifié
(FQDN) se termine par un point ce qui n’est pas le cas d’un nom de domaine relatif. Un nom de
domaine renvoie à un noeud spécifique de l’arbre et à l’ensemble du sous-arbre dont il est la racine. La
création d’un nouveau domaine requiert l’autorisation du domaine immédiatement supérieur. Une fois
créé, le domaine peut créer des sous-domaines sans en référer à quiconque.
Figure 3 : Extrait de l’espace des noms de domaines Internet
Cette hiérarchie garantie l’autonomie de chaque autorité tout en préservant l’unicité des noms d’hôte
attribué et permet également de distribuer la résolution des noms d’hôtes.
Dans les internets TCP/IP, DNS est le mécanisme qui implante le nommage hiérarchique des noms. Il
comporte deux aspects conceptuellement différents : il spécifie d’une part la syntaxe des noms et les
règles de délégation de la gestion des noms. D’autre part, il spécifie la réalisation d’un système distribué
qui résout efficacement les noms d’hôte.
A chaque niveau, le DNS est constitué de multiples serveurs de noms responsables de leur partie de
l’espace de noms (sous-arbre). Chaque serveur délègue la résolution des noms concernant une partie de
son espace de noms à un serveur fille. Aucun serveur, ni même ceux à la racine du système hiérarchique
ne connaissent les informations complètes de tous les domaines et sous-domaines.
L’espace des noms DNS est divisé en zones contiguës. Chaque zone contient une partie de l’arbre
(sous-arbre) et l’ensemble des serveurs de noms qui gèrent les informations officielles des domaines de
cette zone. Ce sous-arbre est donc géré par la même autorité : l’attribution et la résolution des noms
d’une zone ne font jamais appel à une autorité extérieure à cette zone. En principe, une zone a un
serveur de noms primaire et un ou plusieurs serveurs de noms secondaires. Ce sont des serveurs
indépendants et redondants. La principale différence entre serveurs primaire et secondaire est que le
serveur primaire charge les informations de la zone depuis des fichiers sur disque tandis que le second
obtient ces informations du primaire par transfert de zone. Pour ajouter un hôte à une zone,
l’administrateur ajoute l’information correspondante au fichier disque du serveur de noms primaire
La plupart des distributions de LINUX intègre l’implantation BIND (Berkeley Internet Name Domain)
des services DNS. BIND est un programme client/serveur : la partie client est appelé le solveur
(resolver) tandis que la partie serveur est un démon (daemon) appelé named. Pour faire correspondre un
nom à une adresse IP, une application fait appel à la procédure gethostbyname de la bibliothèque C
standard de résolution des noms qui est à proprement parler le solveur. Le solveur envoie un paquet
UDP à un de ses serveurs de noms locaux qui cherche le nom localement. Si la demande concerne un
nom de domaine tombant sous sa juridiction, le serveur de noms renvoie l’adresse IP.
Si le domaine est distant et qu’il n’y pas d’information locale qui le concerne par exemple le solveur de
hyperion.lip6.fr veut connaître l’adresse IP de , le solveur envoie la demande au serveur de noms local.
Si celui-ci n’a jamais fait de demande concernant ce domaine et que le client a demandé à ce que sa
requête soit traitée récursivement (recursive query), le serveur de noms local envoie un paquet UDP au
serveur racine que sa base de données lui indique pour le suffixe le plus à droite du nom à résoudre (ici
.edu). Afin que les serveurs de noms Tout serveur de nom connaît l’adresse d’au moins un serveur
racine et éventuellement celui de son serveur père. Le serveur racine connaissant l’ensemble de ses
serveurs fils, la requête est alors envoyée de serveurs de noms en serveurs de noms jusqu’à ce qu’elle
atteigne le serveur responsable de l’hôte dont on cherche l’adresse IP. Le chemin est indiqué par chacun
des composants du nom à résoudre. Une fois l’adresse IP obtenue auprès du serveur de noms
responsable du domaine, la réponse est alors renvoyé le long du chemin inverse jusqu’au serveur de
noms lip6.fr. Ce dernier enregistre alors la réponse dans une mémoire cache pour une durée limitée.
Si la requête émise par le client est itérative et qu’elle ne peut être satisfaite localement, est renvoyée au
client le serveur de noms suivant à contacter et ainsi de suite. Cette méthode donne au client plus de
contrôle sur le processus de recherche.
Pour chaque requête émise, un client DNS enclenche un temporisateur de retransmission. Si aucune
réponse n’a été obtenue à expiration du temporisateur, le client fait l’hypothèse que le serveur de noms
est en panne et essaie un autre serveur plutôt que de retransmettre la requête.
Pourquoi un serveur de noms enregistre-il les informations non locales récemment obtenues ?
Envoyer systématiquement les requêtes concernant des hôtes distants aux serveurs racines est coûteux
en terme de bande passante. L’enregistrement d’informations non locales permet de décharger (alléger)
les serveurs racines et optimise le temps de résolution des noms d’hôtes distants.
Dans certains systèmes plus complexes, les hôtes chargent la base de données complète du serveur de
noms local au démarrage et maintiennent leur propre mémoire cache d’enregistrements récemment
obtenues. Dans ce cas, les hôtes synchronisent leur copie locale en contactant régulièrement le serveur
de noms local. De tels systèmes sont plus robustes aux pannes de serveurs de noms.
Ces enregistrements n’étant pas officielles, d’éventuels changements touchant les domaines distants ne
peuvent être répercutés. Leur durée de vie est donc limitée. Plutôt que d’associer localement une même
durée de vie à l’ensemble des enregistrements des mémoires caches, c’est l’autorité officielle de chaque
enregistrement qui en spécifie la durée de validité : lorsque un serveur de noms résout un nom dont il est
officiellement responsable, il associe à sa réponse la durée de validité qu’il peut garantir. Les autorités
de nommage peuvent ainsi réduire la charge du réseau en spécifiant de longue durée de validité pour des
enregistrements connus pour rester inchangés. Elles peuvent aussi améliorer la correctude des
enregistrements en spécifiant des durées de validité courte pour ceux amenés à évoluer.
Le fichier host.conf
Le fichier /etc/host.conf indique aux fonctions du solveur les différents mécanismes de résolution à
utiliser et dans quel ordre. Ce fichier texte liste les options du solveur, une par ligne. Les champs sont
séparés par des espaces (ou des tabulations). Les options disponibles sont :
order détermine l’ordre suivant lequel les mécanismes de résolution sont mis en oeuvre. bind indique au
solveur qu’il doit contacter le serveur de noms pour résoudre les noms d’hôtes ou de domaines tandis
que hosts lui indique qu’il doit rechercher les noms à résoudre dans le fichier /etc/hosts.
multi autorise l’attribution de plusieurs adresses IP par nom d’hôte dans le fichier /etc/hosts. La
résolution de ces noms d’hôtes renvoie alors toutes les adresses IP.
trim prend en argument les noms de domaine dont les noms d’hôte seront tronqués (de ces domaines)
avant d’être résolus. Cette option permet de résoudre un nom d’hôte sur la base de son alias figurant
dans le fichier /etc/hosts (noms de domaine non spécifié).
nospoof (de spoofing usurpation) Après avoir résolu un nom d’hôte, une résolution inverse[3] de
l’adresse IP retournée est effectuée pour détecter les éventuelles tentatives de spoofing. Si elle ne
renvoie pas le nom d’hôte attendu, il se peut qu’une machine essaie de se faire passer pour l’hôte. Cette
option permet de rejeter les résultats de résolutions échouant ce test.
spoofalert Les tentatives de spoofing détectées sont enregistrées dans le fichier de log
/var/log/messages.
Le fichier resolv.conf
Ce fichier indique au solveur les serveurs de noms à utiliser. En l’absence de ce fichier ou s’il est vide,
le solveur considère que le serveur de noms est sur la même machine.
nameserver indique l’adresse des serveurs de noms à interroger. Les adresses d’au plus trois
serveurs de noms peuvent être spécifiées en répétant l’option nameserver. Les serveurs seront
alors utilisés dans l’ordre indiqué.
search spécifie la liste des domaines à ajouter aux noms d’hôte qui ne sont pas pleinement
qualifiés. Au plus six domaines peuvent être spécifiées. Si cette option n’est pas spécifiée, la liste
des domaines est créée à partir du nom de domaine local et de celui des domaines parents.
domain donne le nom du domaine local de l’hôte (si non spécifié alors déterminé en appelant à
getdomainname).
Quelles sont les adresses du serveur primaire et des serveurs de noms secondaires du réseau local ?
La commande host permet de résoudre les noms d’hôte et les adresses IP.
Résoudre plusieurs fois d’affiler le nom d’hôte du serveur Web de CNN (www.cnn.com). Comparer les
réponses renvoyées. Pourquoi diffèrent-elles ?
Entre deux requêtes successives, les adresses IP de http://www.cnn.com/ sont renvoyées dans un ordre
différent. Les requêtes provenant des clients désirant se connecter sur CNN sont dirigées aléatoirement
sur les sites miroirs mis en place par CNN. La charge globale de http://www.cnn.com/ est ainsi répartie
sur l’ensemble des sites miroirs.
La commande whois permet de savoir si un nom de domaine déterminé a déjà été attribué et qui le
possède. Les organismes chargés de gérer et d’attribuer les noms de domaines (ex : internic),
maintiennent des bases de données d’informations administratives concernant des noms de domaines
sous leur responsabilité.
Taper la commande whois lip6.fr@whois.nic.fr.
nslookup est une commande qui permet d’interroger un serveur de nom. Exécutée sans argument ou
avec comme arguments, un trait d’union (-) suivi de l’adresse IP ou du nom d’un serveur de noms,
nslookup passe en mode interactif et interroge le serveur de noms spécifié. En mode interactif, cette
commande permet d’interroger un serveur de noms afin d’obtenir des informations concernant des hôtes
et des domaines ou d’afficher la liste des hôtes d’un domaine. Le mode non-interactif permet d’afficher
le nom et les informations demandées concernant le nom d’hôte ou de domaine passé en argument. Si
aucun serveur n’est spécifié, le serveur de noms interrogé par défaut est le premier serveur de noms
spécifié dans le fichier /etc/hosts.
Pour interrompre le traitement d’une requête en mode interactif, taper ^C. Pour quitter, taper ^D ou exit.
help permet d’obtenir une aide complète sur la commande.
Pour obtenir des informations concernant un hôte, il suffit de passer le nom de cet hôte. S’il est suivi
d’un nom ou de l’adresse IP d’un serveur de noms, la requête sera envoyée à ce serveur.
server permet de spécifier le nom ou l’adresse IP d’un serveur de noms particulier à qui adresser les
requêtes (à interroger).
set type=value permet de changer le type d’information (enregistrement) demandée (par défaut l’adresse
IP est renvoyée) :
A l’adresse IP de l’hôte
CNAME nom canonique
HINFO CPU et type de système d’exploitation de l’hôte
MINFO boîte de réception ou liste d’information du courrier
MX serveur de mail
NS nom du serveur de noms de la zone spécifiée
PTR si est spécifiée une adresse IP, est renvoyé le nom d’hôte
SOA (start-of-authority) ce type d’enregistrement spécifie l’origine des informations (serveur de
noms responsable de l’hôte), l’email du responsable et des paramètres pour les mémoires caches et
les serveurs secondaires
UINFO information concernant l’utilisateur
WKS les services supportés (well-known services).
ls permet de lister les informations disponibles pour un domaine. Par défaut sont renvoyés les noms des
hôtes du domaine et les adresses IP correspondantes.
Quels sont les serveurs de noms primaire et secondaires du domaine cnn.com ? Interpréter la réponse
obtenue.
Quatre serveurs de noms ont autorité sur le domaine cnn.com (1 serveur primaire + 3 serveurs
secondaires). Il est également indiqué que ces informations ne proviennent pas d’un serveur responsable
du domaine mais qu’elles étaient cachées ailleurs. Une liste des serveurs de noms responsables de ces
informations est donnée.
Renouveler la requête précédente en l’adressant cette fois-ci à un des serveurs de noms responsable du
domaine cnn.com. Qu’observe-t-on ? Pourquoi ?
Address: 207.24.245.178
> cnn.com
Server: [207.24.245.178]
Address: 207.24.245.178
Le serveur de noms responsable du domaine cnn.com n’a pas répondu à la requête avant expiration du
temporisateur associé.
- Les requêtes et réponses étant envoyées dans des paquets UDP, la requête ou la réponse associée a pu
se perdre. La requête n’est pas adressée à un autre serveur de noms, le serveur de noms 207.24.245.178
ayant été spécifié comme étant celui à interroger.
- Les serveurs de noms écoutent sur le numéro de port TCP et UDP 53 sur lequel les clients se
connectent pour envoyer leurs requêtes. Le trafic sortant est filtré sur ce port (comme bien d’autres) par
le pare-feu ( firewall) de Jussieu.
[1] multicast
[2] Traduction des noms d’hôtes en adresses IP
[3] La résolution inverse fait correspondre un nom d’hôte à une adresse IP