Mise en place d'un serveur DNS (Packet Tracer)

Contexte et besoins

Cet atelier prolonge la série HSRP → DHCP → DNS mise en place sur la même topologie de PME. À ce stade, les postes des VLAN COMPTA et INFO ont une passerelle redondée et reçoivent automatiquement leur configuration IP. Reste un dernier point d’inconfort : pour atteindre l’intranet, la messagerie ou le NAS, les utilisateurs doivent taper l’adresse IP du serveur correspondant.

Le besoin remonté par le support était simple : « On veut que les gens tapent intranet.lab.local au lieu de 192.168.20.200. » L’objectif est donc de mettre en place un serveur DNS interne capable de résoudre les noms des services de la PME, et de le coupler au DHCP pour qu’aucun poste n’ait à être reconfiguré à la main.

Rappel théorique sur DNS

Le DNS (Domain Name System) est défini par les RFC 1034  et RFC 1035 . Il sert à traduire un nom en adresse IP (et inversement). Il fonctionne sur le port 53 UDP pour la majorité des requêtes, et bascule en 53 TCP pour les réponses volumineuses ou les transferts de zone entre serveurs.

Hiérarchie des zones

Le DNS est organisé en arbre. La racine (notée .) est implicite à la fin de chaque nom complet (FQDN).

Sur l’arbre, la résolution se fait de haut en bas : on part de la racine, on descend vers le TLD com, puis vers le domaine example, puis vers l’enregistrement www. Cette même hiérarchie se relit de droite à gauche dans la forme textuelle d’un FQDN comme www.example.com., c’est la même chose, simplement projetée sur une ligne.

Comment se passe une résolution

Quand un poste cherche intranet.lab.local, il interroge son résolveur (le DNS qu’il a reçu par DHCP). Si le résolveur connaît la réponse (zone hébergée localement ou en cache), il répond immédiatement. Sinon, il interroge en cascade les serveurs publics jusqu’à trouver le serveur autoritatif du domaine cible.

Sur un petit LAN, le résolveur héberge directement la zone interne, donc la cascade ne sert que pour les noms publics (google.com etc.).

Principaux types d’enregistrements

TTL et cache

Chaque réponse DNS contient un TTL (Time To Live) en secondes. Tant qu’il n’a pas expiré, les résolveurs et les clients gardent la réponse en cache. Une valeur typique est 3600 s (1 h) pour un enregistrement stable. Avant un changement prévu, on descend à 60-300 s pour accélérer la propagation, puis on remonte une fois la migration terminée.

Topologie de laboratoire

On reprend la topologie HSRP/DHCP, en y ajoutant un serveur générique Packet Tracer qui jouera le rôle de DNS interne pour la zone lab.local.

Le serveur DNS est placé dans le VLAN INFO, où se trouvent déjà les autres services internes. Sa résolution est rendue accessible aux postes COMPTA via le routage inter-VLAN assuré par R1/R2.

Plan d’adressage et zone DNS

Configuration du serveur DNS dans Packet Tracer

L’objet Server-PT de Packet Tracer ne propose pas un BIND complet, mais il sait gérer une zone à plat avec les types A, CNAME, NS, SOA et MX. C’est largement suffisant pour valider la chaîne de résolution.

1. Adressage de l’interface

Dans Config → FastEthernet0 :

IP Address       : 192.168.20.200
Subnet Mask      : 255.255.255.0
Default Gateway  : 192.168.20.254   # VIP HSRP

2. Activation du service et création des enregistrements

Dans Services → DNS :

1. Passer DNS Service sur ON.
2. Ajouter ligne par ligne les enregistrements :

Pour chaque ligne, cliquer sur Add pour valider. Une faute de frappe est fréquente : un point oublié ou un suffixe .local mal copié casse silencieusement la résolution. Toujours relire la table avant de quitter l’écran.

Distribution automatique du DNS via DHCP

Plutôt que de configurer 30 postes à la main, on enrichit les pools DHCP créés à l’atelier précédent pour que l’IP du serveur DNS interne soit poussée à chaque renouvellement de bail.

R1# configure terminal
R1(config)# ip dhcp pool POOL_COMPTA
R1(dhcp-config)# dns-server 192.168.20.200 1.1.1.1
R1(dhcp-config)# domain-name lab.local
R1(dhcp-config)# exit

R1(config)# ip dhcp pool POOL_INFO
R1(dhcp-config)# dns-server 192.168.20.200 1.1.1.1
R1(dhcp-config)# domain-name lab.local
R1(dhcp-config)# end
R1# write memory

Explications ligne par ligne :

• dns-server 192.168.20.200 1.1.1.1 : le poste reçoit deux DNS dans cet ordre. Le premier (interne) résout les noms *.lab.local. Si le serveur interne tombe, le poste bascule sur Cloudflare pour les noms publics. Les noms internes deviennent inaccessibles, mais Internet reste joignable.
• domain-name lab.local : suffixe DNS poussé via l’option DHCP 15. Permet aux postes de taper intranet tout court : le système rajoute automatiquement .lab.local avant la requête.

Pour propager le changement sans attendre l’expiration des baux : clear ip dhcp binding * côté routeur, puis ipconfig /release && ipconfig /renew côté Windows.

Le routeur en client DNS

Le routeur Cisco peut aussi résoudre des noms (utile pour ping intranet.lab.local directement depuis IOS, ou pour des ACL avec FQDN). Il suffit de le configurer comme client DNS :

R1(config)# ip name-server 192.168.20.200 1.1.1.1
R1(config)# ip domain-name lab.local
R1(config)# ip domain-lookup

Tests de résolution

Sur un poste du VLAN COMPTA, ouvrir Command Prompt :

> ipconfig /all
   ...
   DNS Servers . . . . . . . . . . . : 192.168.20.200
                                       1.1.1.1
   Connection-specific DNS Suffix . : lab.local

> nslookup intranet.lab.local
Server:  dns1.lab.local
Address: 192.168.20.200

Name:    intranet.lab.local
Address: 192.168.20.201

> nslookup www.lab.local
Server:  dns1.lab.local
Address: 192.168.20.200

Name:    www.lab.local
Aliases: intranet.lab.local
Address: 192.168.20.201

> ping nas
Pinging nas.lab.local [192.168.20.203] with 32 bytes of data:
Reply from 192.168.20.203: bytes=32 time=2ms TTL=128

Le dernier exemple est intéressant : le poste a tapé ping nas, le système a appliqué le suffixe lab.local pour reconstruire nas.lab.local, puis interrogé 192.168.20.200 qui a renvoyé l’IP. Tout cela sans intervention manuelle sur le poste.

Notions de sécurité

Le DNS est un service critique et historiquement peu protégé. Trois points à connaître :

• Cache poisoning : un attaquant injecte de fausses réponses dans le cache du résolveur pour rediriger les utilisateurs. Atténué par la randomisation du port source (RFC 5452).
• DNSSEC (RFC 4033) : signe cryptographiquement les enregistrements, ce qui permet au résolveur de vérifier qu’une réponse n’a pas été falsifiée. Il ne chiffre pas les requêtes, il garantit seulement l’authenticité.
• DoT / DoH (DNS over TLS / over HTTPS) : chiffrent le transport des requêtes pour la confidentialité. DoT utilise le port 853, DoH se confond avec du HTTPS classique sur le port 443.

En production, l’ANSSI recommande d’activer DNSSEC sur les zones publiques, de séparer strictement les résolveurs internes et externes, et de journaliser le trafic DNS (90 % des malwares utilisent le DNS pour leur communication avec leur serveur de contrôle).

Problèmes rencontrés et solutions

Bonnes pratiques retenues

• Une seule source de vérité : tout nom interne doit exister dans la zone DNS, pas dans des fichiers hosts éparpillés sur les postes.
• TTL bas avant migration : descendre à 60 s 24 h avant un changement d’IP, le remonter à 3600 s après.
• Redondance : prévoir au moins deux serveurs DNS internes en production (Packet Tracer ne le simule pas, mais c’est la règle).
• DNS public en second : le résolveur local doit toujours être interrogé en priorité, sinon les noms internes ne se résolvent plus.
• Surveillance : monitorer le port 53 et le service. Une panne DNS se manifeste par « Internet est cassé » côté utilisateurs alors que le routage fonctionne.

Compétences du bloc 1 mobilisées

Bilan

À l’issue de l’atelier, les postes COMPTA et INFO reçoivent automatiquement leur DNS interne via DHCP, et résolvent l’ensemble des services nommés *.lab.local. La trilogie HSRP + DHCP + DNS est complète : un nouveau collaborateur branché sur le réseau obtient une IP, une passerelle redondée et la résolution des services internes sans qu’aucun paramètre ne soit saisi à la main. C’est exactement ce qu’on attend d’un réseau de PME prêt pour la production.

Au-delà de la configuration, l’atelier a surtout permis de comprendre comment ces trois protocoles s’articulent : DHCP distribue ce que DNS résout, et HSRP garantit que la passerelle distribuée par DHCP reste joignable.

Sources

• RFC 1034 — Domain Names: Concepts and Facilities , IETF, 1987.
• RFC 1035 — Domain Names: Implementation and Specification , IETF, 1987.
• RFC 4033 — DNS Security Introduction and Requirements (DNSSEC) , IETF, 2005.
• Cisco — Configuring DNS on Cisco Routers .
• CCNA 200-301 Official Cert Guide (Volume 1), Wendell Odom, Cisco Press, 2019 , chapitre sur DNS.
• ANSSI — Bonnes pratiques pour l’acquisition et l’exploitation de noms de domaine , ANSSI.

Fichier Packet Tracer

Le fichier .pkt correspondant à cette configuration est disponible ici.