Configuration de connexion TCP/IP sur LINUX

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.Les Commandes d’Administration et de Configuration TCP/IP

La plupart des commandes introduites sont utilisées dans les fichiers de configuration réseau exécutés à
chaque nouveau démarrage du système (et lancés par init). Ces fichiers sont des scripts de shell qui
créent les interfaces réseaux et configurent des paramètres comme les adresses réseau, le nom de la
machine. Leur emplacement varie considérablement dans les différentes distributions de LINUX. On les
trouve le plus souvent dans le répertoire /etc/rc.d/init.d. Les fichiers rc (rc.inet1 et rc.inet2) sont
employés pour configurer TPC/IP. rc.inet1 s’occupe de configurer les paramètres réseau de base
(adresse IP et routage) et rc.inet2 lance les programmes réseau comme telnetd, ftpd.

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 ?

localhost localhost.localdomain localhost

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 :

ifconfig interface [aftype] options | address ...

Donner les noms de l’ensemble des interfaces présentes dans le noyau.

Quelle est l’adresse IP de votre machine ? A quelle classe appartient-elle ?
Quelle est l’adresse de diffusion du réseau local ?
Quel est le masque du sous-réseau local ?
Quelle est l’adresse du sous-réseau local ?
Combien d’hôtes peuvent être connectés au sous-réseau local ?
Donner la ligne de commande permettant d’activer l’interface loopback.
Donner la ligne de commande permettant d’activer l’interface eth0.
2.4. Routage IP
Dans un réseau à commutation par paquets, le routage est le traitement qui consiste à choisir le chemin
sur lequel transmettre un paquet en fonction de son adresse destination et des informations contenues
dans les tables de routage tandis qu’un protocole de routage permet de construire dynamiquement les
tables de routage. Une table de routage (ou FIB pour Forwarding Information Base) est une structure
complexe qui contient les informations de routage nécessaires pour atteindre toute adresse IP valide.
Pour comprendre le routage IP, un rappel de l’architecture d’un internet TCP/IP est utile : un internet est
composé de plusieurs réseaux interconnectés par des équipements appelés gateways. Chaque gateway
est donc directement connecté à au moins deux réseaux physiques et assure le transfert des paquets
(relaye les paquets) d’un réseau à un autre. Un hôte est quant à lui directement connecté à au moins un
réseau physique mais ne relaye jamais de paquets : contrairement aux gateways, il rejette
systématiquement les paquets qu’il reçoit s’il n’en est pas le destinataire. Cependant, un hôte, même s’il
est connecté à un seul réseau physique participe aussi au routage IP (lorsque par exemple, le réseau local
interconnecte au moins deux réseaux, les hôtes de ce réseau ont le choix entre deux gateways). Par
contre, un hôte n’exécute généralement pas de protocole de routage. En effet, lorsque les informations
de routage ne changent pas ou lorsqu’il existe une seule route possible, les tables de routage sont
construites manuellement par l’administrateur système. Il existe deux types de routage IP. Le processus
de routage est généralement séparé en deux entités :
Le routage direct : transmission d’un paquet IP entre deux machines connectées au même réseau
physique (pas de gateway impliqué). La source encapsule le paquet dans une trame dont l’adresse de
destination est l’adresse MAC (physique) de la destination.

Compléter la figure suivante :

Figure 1 : Routage IP direct

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.

Pourquoi n’est-il pas toujours nécessaire de préciser le masque de sous-réseau de la destination ?

L’argument netmask est inutile si le masque de l’adresse destination peut être directement déduit de la
classe de son adresse IP.

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 :

ifconfig eth0 132.227.61.27 netmask 255.255.255.0

# déjà ajouter par ifconfig

route add -net 132.227.61.0

# dev eth0 inutile

route add default gw 132.227.61.200

# dev eth0 inutile

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

Quelle l’adresse IP de la passerelle du réseau local ?

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

Source Destination Gateway Flags Metric Ref Use Iface

civry 132.227.61.255 132.227.61.255 ibl 0 0 2 lo

hera.lip6.fr antigone.lip6.f antigone.lip6.f il 0 0 41986 lo

ancee 132.227.61.255 132.227.61.255 ibl 0 0 0 lo

ymir 132.227.61.255 132.227.61.255 ibl 0 0 0 lo

phusia 132.227.61.255 132.227.61.255 ibl 0 0 0 lo

antigone.lip6.f rp-dhcp23 rp-dhcp23 0 2 1 eth0

antigone.lip6.f antigone.lip6.f antigone.lip6.f l 0 0 16262 lo

Les deux types de route sont :

- 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

- celles dont la destination est antigone.lip6.fr. ou une adresse de diffusion (132.227.61.255,

255.255.255.255, ALL-SYSTEMS.MCA[1]). Toutes ces routes sont associées à lo puisqu’elles n’ont
pas servi à envoyer de paquets. Le noyau déduit ces routes des paquets reçus par l’hôte. Elles permettent
au noyau de tirer partie des paquets récemment reçus en en enregistrant les routes inverses. Est ainsi
accéléré le routage ( forward) des paquets à destination des adresses/équipements dont il a récemment
reçu des paquets. D’autant qu’après avoir reçu des données d’une source, l’hôte a de forte chance de lui
renvoyer une réponse. 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.

La troisième colonne spécifie, si la destination est un (sous-)réseau le masque de ce (sous-)réseau,

255.255.255.255 si la destination est un hôte et 0.0.0.0 si l’entrée est celle de la route par défaut.
Genmask permet de spécifier la plage d’adresses que la destination référence : Le masque Genmask est
appliqué par le noyau à l’adresse destination du paquet à transmettre (ET logique) pour voir s’il
correspond bien à la valeur de la colonne destination de la table.

La quatrième colonne affiche les drapeaux suivants :

routage indirect si positionné (gateway impliqué), destination directement

G
accessible sinon.
la colonne destination spécifie une adresse d’hôte complète si positionné, une
H
adresse de réseau sinon.
U la route est en service (interface active)
D entrée créée dynamiquement par un protocole/démon de routage
! route en sens interdit, les paquets seront détruits.

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.

Kernel Interface table

Taux de collision = Tx packets/collisions

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.

2.5. Cache ARP

Le protocole ARP (Address Resolution Protocol) permet à un hôte de trouver l’adresse physique d’un
hôte destination connecté au même réseau physique et dont il connaît l’adresse IP. Les hôtes qui utilisent
ARP maintiennent un cache des correspondances adresse IP -> adresse physique récemment obtenues.
Le délai d’expiration d’une entrée dans le cache est de 20 min après sa création.
Pourquoi maintenir un cache ARP ?

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 :

arp -H ether -i eth0 -s [gateway_name or IP] hw_addr

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.

Pourquoi les enregistre-il pour une durée limitée ?

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 ?

Quel est le nom du domaine local ?

Y a-t-il une différence entre ces deux entrées du fichier resolv.conf ?

domain math.cicrp.jussieu.fr

search math.cicrp.jussieu.fr cicrp.jussieu.fr jussieu.fr

Les commandes host et whois

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.

Les commandes nslookup

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).

D’autres options sont décrites dans le RFC 1035.

set [no] recurse indique au serveur de noms interrogé de traiter [non] récursivement les requêtes (valeur
par défaut = recurse).

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.

[login@ippcxxx login]$ nslookup

> set type=NS

> cnn.com
> Non-authoritative answer :
> cnn.com nameserver = NS-02B.ANS.NET
> cnn.com nameserver = NS-02A.ANS.NET
> cnn.com nameserver = NS-01B.ANS.NET
> cnn.com nameserver = NS-01A.ANS.NET
> Authoritative answers can be found from :

> NS-02B.ANS.NET internet address = 207.24.245.178

> NS-02A.ANS.NET internet address = 207.24.245.179

> NS-01B.ANS.NET internet address = 199.221.47.8

> NS-01A.ANS.NET internet address = 199.221.47.7

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 ?

> server 207.24.245.178

Default Server: [207.24.245.178]

Address: 207.24.245.178
> cnn.com

Server: [207.24.245.178]

Address: 207.24.245.178

*** Request to [207.24.245.178] timed-out

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