Résous un nom avec un DNS local

L’idée reçue

« DNS est l’annuaire qui contient tous les sites Internet. »

DNS est un système distribué de zones, serveurs et résolveurs. Dans ce laboratoire, tu vas isoler une fonction précise : répondre localement qu’un nom correspond à une adresse IPv4.

Tu vas publier intranet.soria.test → 10.30.0.20, puis prouver qu’une résolution réussie ne signifie pas encore que le service web répond.

Clientsoria-cli10.30.0.100

→ DNS 53

Résolveur localsoria-svc10.30.0.1

→ HTTP 8080

Applicationsoria-web10.30.0.20

01Préparer le LAN

sudo apt update
sudo apt install -y dnsmasq-base dnsutils tcpdump curl python3
chmod +x module3-services-lab.sh
sudo ./module3-services-lab.sh up

sudo ip -n soria-cli addr add 10.30.0.100/24 dev eth0

Le client possède ici une adresse statique afin que la leçon DNS reste indépendante du serveur DHCP.

02Décrire la résolution locale

cat >/tmp/soria-dnsmasq.conf <<'EOF'
interface=eth0
bind-interfaces
no-resolv
no-hosts
domain-needed
bogus-priv
local=/soria.test/
host-record=dns.soria.test,10.30.0.1
host-record=intranet.soria.test,10.30.0.20
log-queries
log-facility=-
pid-file=/tmp/soria-dnsmasq-dns.pid
EOF

Comprends ce que ce serveur sait réellement

Ce dnsmasq connaît deux noms locaux. Avec local=/soria.test/, les noms inconnus de ce domaine reçoivent une réponse négative locale au lieu d’être transmis ailleurs. Ce laboratoire ne prétend pas reproduire toute la hiérarchie DNS publique.

03Lancer et interroger le serveur

Terminal 1

Lance dnsmasq dans son namespace

sudo ip netns exec soria-svc dnsmasq --no-daemon --conf-file=/tmp/soria-dnsmasq.conf

Terminal 2

Demande l’enregistrement A

sudo ip netns exec soria-cli dig @10.30.0.1 intranet.soria.test A

sudo ip netns exec soria-cli dig @10.30.0.1 intranet.soria.test A +short

Observe

10.30.0.20

04Observer UDP puis TCP

Terminal 3

Capture le port 53

sudo tcpdump -ni br-soria-svc -vv 'port 53'

Dans le terminal client :

sudo ip netns exec soria-cli dig @10.30.0.1 intranet.soria.test A

sudo ip netns exec soria-cli dig @10.30.0.1 intranet.soria.test A +tcp

DNS utilise couramment UDP pour les requêtes ordinaires, mais TCP fait aussi partie du protocole. Le port 53 ne signifie donc pas « UDP uniquement ».

05Lire une réponse négative

sudo ip netns exec soria-cli dig @10.30.0.1 absent.soria.test A

Repère le statut NXDOMAIN. Il signifie que le serveur affirme que ce nom n’existe pas dans l’espace qu’il traite. Un timeout serait différent : il indiquerait l’absence de réponse, pas une réponse négative.

06Distinguer DNS et HTTP

Lance un vrai service web :

sudo ip netns exec soria-web python3 -m http.server 8080 --bind 10.30.0.20

Dans un autre terminal, résous d’abord le nom puis contacte l’adresse obtenue :

IP=$(sudo ip netns exec soria-cli dig @10.30.0.1 intranet.soria.test A +short)

sudo ip netns exec soria-cli curl -v "http://${IP}:8080/" -H 'Host: intranet.soria.test'

La première commande valide DNS. La seconde valide le service HTTP. Les séparer évite de conclure « DNS est cassé » lorsque le serveur web est simplement arrêté.

Panne volontaire

Publie une mauvaise adresse

remplace 10.30.0.20 par 10.30.0.21 dans la configuration ;
redémarre dnsmasq ;
montre que dig réussit malgré l’échec de curl ;
corrige l’enregistrement ;
valide à nouveau DNS puis HTTP.

Note : les network namespaces partagent le système de fichiers de la VM. Pour ne pas modifier le /etc/resolv.conf de l’hôte, cette leçon interroge explicitement @10.30.0.1.

07Nettoyer

sudo ./module3-services-lab.sh down

✓Ce que tu retiens

DNS transforme un nom en donnée exploitable par le client, ici une adresse A. Une réponse positive, une réponse NXDOMAIN et un timeout décrivent trois situations différentes. La disponibilité du nom et celle de l’application doivent être testées séparément.