Vous êtes sur la page 1sur 2

TP DNS avancé : TCP/IP over DNS (NSTX ou iodine)

M2 SIR (App)
Jean-Patrick Gelas <jean-patrick.gelas@univ-lyon1.fr>
UCB Lyon 1, Université de Lyon, France

L'objectif premier de ce TP est de consolider vos connaissances autour du service DNS. Dans le
contexte de ce TP nous allons détourner l'usage initial des requêtes DNS et exploiter celles-ci pour y
faire circuler des datagrammes IP ou autrement dit, créer un “tunnel” DNS. Le principe et l'usage est
relativement similaire au fonctionnement des tunnels http.

1.Pré-requis
Commandes de base UNIX ; Connaissances de base des protocoles réseaux et de transport de données
(TCP/IP) ; Principe de fonctionnement du service de résolution de noms (DNS) ; Configuration de base
d'un serveur DNS.

2.Principe de fonctionnement
Le fonctionnement repose sur le principe de la délégation. Toutes les requêtes DNS sont dirigées vers
un sous-domaine (subzone) contenant un autre serveur de nom. Cela signifie que pour obtenir votre
adresse IP, on doit accéder au DNS de votre ISP puis on est redirigé vers votre propre serveur de nom
qui peut alors répondre à la requête. Pour cela, vous avez besoin d'un serveur que vous pouvez
administrer. Autrement dit, toutes les requêtes dirigées vers un sous-domaine particulier sont relayées
vers votre hôte, qui ensuite y répond.
Remarque : Dans les faits, la connexion peut apparaitre plutot de mauvaise qualité et n'offre bien sur
pas la meilleur latence (mais à défaut de rien du tout...).
(En situation réel, on supposera qu'on obtient toujours une adresse IP (via DHCP). Ce service permet
également de connaitre l'adresse du serveur DNS qu'ils veulent que vous utilisiez (cf. /etc/resolv.conf))

3.Matériel et logiciel nécessaires :


Nous utiliserons une première machine qui fera office de DNS officiel fournit par l'ISP (à configurer,
utiliser bind9), une seconde machine qui hébergera le hack (et pas un vrai serveur DNS), qui répondra
effectivement aux requêtes DNS et qui est hébergé par l'ISP. Vous aurez également besoin d'une
machine cliente dont la configuration réseau est modifiée (elle sera capable d'encapsuler les
datagrammes IP dans des requêtes DNS), et enfin un serveur qui hébergera un serveur (par exemple un
Apache) pour valider le bon fonctionnement.

D'un point de vue logiciel on vous propose d'utiliser iodine (un hack pour “tunneler” le trafic IP au-
dessus de datagrammes IP (traduction libre)). iodine utilise le port 53, c'est pourquoi nous ne pouvons
faire tourner un DNS sur la machine qui exécute iodine.

Optionnelement, on pourrait avoir, afin de valider le bon fonctionnement, une dernière machine qui
n'autoriserait que le trafic DNS (si vous avez le temps). On pourra se contenter de surveiller le trafic
avec un Wireshark et constater que seule des requêtes/réponses DNS circulent de et vers la machine
cliente.

4. Objectif
Mettre en oeuvre la dernière version de iodine en salle de TP ! :-)
A rendre : un mini-compte rendu décrivant brièvement la démarche suivit pour configurer l'ensemble
des machines et une rapide évaluation des perf. (overhead en débit et volume).

5.Lien utiles et sources :


iodine : http://code.kryo.se/iodine/
IP over DNS : Contourner les limitations des hotspots : http://geekfault.org/2009/09/26/ip-over-dns/
Une bonne introduction aux tunnels DNS : http://dnstunnel.de/
Pour information les alternatives :
ozymanDNS : http://en.cship.org/wiki/OzymanDNS
nstx-ng : https://alioth.debian.org/projects/nstx-ng/
dns2tcp : http://www.hsc.fr/ressources/outils/dns2tcp/
Dans le même cadre d'usage, si le trafic DNS était filtré (fortement improbable), il est possible d'utiliser
comme alternative ICMPTX (IP-over-ICMP) : http://thomer.com/icmptx