} catch (UnknownHostException e) {
 // TODO Auto-generated catch block
 e.printStackTrace();
L'usage sera : java Test1 nom_hôte
Il est naturellement possible de l'améliorer, notamment en ce qui concerne la gestion de l'erreur.
TP 2 : Utilisation simple de BIND.
BIND peut avec ses fichiers de configuration comme un peu archaïque. Mais finalement, c'est le serveur DNS libre pouvant fonctionner sous Windows. En plus, il est la référence pour ce genre de logiciel. Donc, il est le plus adapté pour ce TP.
Installation de BIND sous Windows.
Il est possible d'installer BIND sous Windows même sur les versions familiales de XP. Naturellement, il ne s'agit pas d'en faire un serveur de production, mais de manipuler concrètement les fichiers zones. BIND est disponible sur le site de ISC. Pour ce TP, je suis parti de la version 9.3.3, l'archive compressée ne fait que 3.4 Mo. En décompressant, l'archive on trouve un exécutable BINDInstall.exe qu'il faut lancer. L'installation va se faire dans le répertoire c:\Windows\System32\DNS (il peut toujours avoir des variantes suivant la version de Windows). Je conseille de pas cocher lors de l'installation BIND en tant que service "Start BIND Service after Install".
Maintenant BIND installé, il faut pouvoir le démarrer. Il faut ajouter au "path" le répertoire de destination des binaires de BIND. Il comporte notamment dig.exe et named.exe. Ce chemin est probablement "C:\Windows\System32\DNS\bin". Pour l'ajouter au "path", il faut aller dans le panneau de configuration, choisir "système", aller dans l'onglet "avancé" et cliquer sur le bouton "variables d'environnement". À ce niveau, il faut ajouter à la fin du path "c:\Windows\System32\DNS\bin". À la fin de cette opération, en mode dos, les commandes dig et named doivent fonctionner. La commande codice_1 se plante au bout de quelques secondes. Pour voir la log du serveur, il faut le lancer avec l'option "-g" soit "named -g". La log indique qu'il manque des fichiers de configuration.
Installation Sous GNU/Linux.
Sous Fedora
yum install bind9
Sous Debian, Ubuntu, Mint et Trisquel
apt-get install bind9
Présentation du réseau.
Par la suite, nous allons étudier un réseau simple d'un particulier ayant un fixe relié à l'Internet avec un boîtier du style "livebox" et un ordinateur portable relié également à ce boîtier. Nous allons installer le serveur BIND sur le portable en tant que serveur primaire et sur le fixe en tant que serveur secondaire.
Notre réseau se compose :
L'objectif est de définir une zone tld1 et une zone sld1.tld1.
Première configuration du primaire.
Il faut créer dans le répertoire "C:\Windows\System32\DNS\etc", le fichier codice_2. Ce fichier contient la liste des zones et où les trouver. Pour commencer, nous allons simplement déclarer la zone "0.0.127.in-addr.arpa" qui permet d'associer à l'adresse 127.0.0.1, le nom "localhost".
Maintenant, il faut définir le fichier zone "db.127.0.0". Dans le répertoire "c:/windows/system32/dns/etc/namedb". 
À ce niveau, la commande named -g doit fonctionner correctement.
Définition de la zone "tld1" sur le primaire.
Cette zone se compose des éléments :
On modifie le fichier codice_2 pour ajouter la déclaration de la zone "tld1".
Et maintenant, il faut décrire notre zone "tld1" dans le fichier "db.tld1". Cette zone est composée d'un enregistrement SOA, de deux enregistrements déclarant les deux serveurs de noms, des adresses IP et enfin des alias. 
La zone "sld1.tld1" et délégation.
Nous allons imaginer une zone "sld1.tld1" composée des éléments :
Il faut donc modifier le fichier zone "db.tld1" pour prendre en compte cette délégation. Il s'agit de déclarer les serveurs de noms pour la zone "sld1.tld1".
Le nouveau fichier de configuration "named.conf" comporte la déclaration d'une zone supplémentaire.
Il faut maintenant définir le fichier zone "db.sld1.tld1", suivant la configuration de notre zone.
Ajout du lien avec la racine du DNS.
Notre serveur répond bien aux requêtes correspondant aux éléments de notre réseau, mais il est incapable de répondre aux requêtes correspondant avec des éléments extérieurs. Nous allons ajouter un lien avec la racine du DNS. Le fichier named.conf devient :
Il faut définir le fichier db.cache. Attention, il n'a pas de rapport avec la notion de cache du DNS. Son contenu est l'ensemble des serveurs racine et les adresses IP associées.
Fichier zone pour la résolution inverse.
Pour la résolution inverse. Il faut définir la zone "1.168.192.in-addr.arpa.". Il faut donc ajouter une dernière zone au fichier "named.conf".
Maintenant le contenu du fichier zone "db.192.168.1" est assez proche de "db.127.0.0". Il simplement garder à l'esprit que chaque élément possède en fait deux noms. Ce qui donne donc :
Configuration du secondaire.
Le secondaire ne va pas avoir en local les fichiers zones mais va les récupérer lors du démarrage sur le primaire. Les zones concernés sont "tld1", "sld1.tld1" et la zone inverse "1.168.192.in-addr.arpa". Une petite adaptation sera à faire sur le fichier "db.127.0.0". Le nouveau fichier de configuration named.conf est donc :
Si tout se passe bien, les fichiers sont transféré et sont visible sur le secondaire. Lorsqu'on les regarde, on constate qu'ils utilisent un notation simplifiée avec la directive "$ORIGIN". Les noms sont des noms relatifs non terminés par un point. On a par exemple pour "db.bak.tld1" :
Enfin, les serveurs peuvent être testés avec la commande Dig.
TP 3 : QCM de l'AFNIC.
L'AFNIC a mis en place un très bonne présentation d'une DNS. Chaque partie se termine par un questionnaire. je propose donc de bien lire l'intégralité de ce cours et de faire les questionnaires. Attention certaines questions ne sont évidentes pour les personnes débutantes dans le DNS. Le site est http://www.afnic.fr/ext/dns/.
TP 4 : Quand wanadoo.fr devient orange.fr.
En juin 2006, Wanadoo.fr devient orange.fr. Mais pour les clients la messagerie et le site web doivent toujours fonctionner avec la nouvelle adresse et l'ancienne adresse.
Regardons en détail la zone orange.fr
Elle pointe bien vers wanadoo.fr. Regardons en détail la zone wanadoo.fr.
Visiblement wanadoo.fr ne donne pas beaucoup de renseignements. Nous allons l'interroger directement sur l'enregistrement MX.
Donc les deux zones semblent bien pointer pour les serveurs de messagerie vers les mêmes machines. Apparemment, il s'agit d'un important cluster. Regardons maintenant la correspondance inverse, je prends l'adresse 193.252.22.100.
Elle répond smtp.orange. Ce qui semble logique : orange.fr remplace wanadoo.fr. Maintenant regardons le site web. Le site www.wanadoo.fr pointe sur le site de www.orange.fr.
Et www.orange.fr ???
Nous allons regarder qui se cache derrière 193.252.122.103 et 193.252.149.30 
On peut également pour continuer faire des "zonecheck" pour wanadoo.fr et orange.fr http://www.afnic.fr/outils/zonecheck.
La zone wanadoo.fr passe le test sans problème tandis qu'orange.fr pose problème :
La valeur du champ 'retry' est de 7200 sec, et devrait être inférieure au 'refresh' (3600 sec). 
La référence est le RFC1912 (p.4) "The 'retry' value is typically a fraction of the 'refresh'".
L'erreur est considérée comme fatale. Dans le cas présent la zone orange.fr fonctionne en fait correctement. Il est vrai que les TTL sont assez petit.
Un dernier point serait de faire une interrogation des bases Whois pour regarder les contacts techniques (http://www.afnic.fr/outils/whois). En fait dans ce cas le contact technique ne donne pas de renseignements supplémentaires. En effet il s'agit d'une trop grande structure et en général le site web et la gestion de la messagerie sont gérés par des entités différentes.

Réseaux TCP/IP/Analyse des messages
Les messages échangés entre les machines d'un réseau TCP/IP peuvent être analysés et identifiés par certains logiciels, comme .
Il est alors possible de reconnaitre les différents en-têtes et encapsulations des messages.

Technologie/Transmissions mécaniques/Courroies