DNS, DHCP, NTP : services d’infrastructure réseau

Un réseau qui « marche » repose sur une couche de services souvent invisibles tant qu’ils fonctionnent, mais dont la moindre défaillance paralyse tout le reste. Trois d’entre eux forment un socle universel : le DNS (Domain Name System), système hiérarchique et distribué qui traduit les noms de domaine lisibles en adresses IP (Internet Protocol) numériques, le DHCP (Dynamic Host Configuration Protocol), protocole réseau qui distribue automatiquement les paramètres de configuration IP aux hôtes, et le NTP (Network Time Protocol), protocole de synchronisation des horloges des ordinateurs sur un réseau. Ce chapitre explique comment ils s’articulent, où ils cassent, et comment ils deviennent des points de sécurité et d’observation.

→ Lire l’explication complète de la marmotte

Objectif du chapitre

L’objectif est de dépasser la vision « boîte noire » de ces services pour comprendre leurs mécanismes internes, leurs compromis et leurs pièges. Un administrateur qui saisit la chaîne de résolution DNS (Domain Name System), la logique de bail DHCP (Dynamic Host Configuration Protocol) et le rôle critique du temps diagnostique en minutes des pannes qui, autrement, restent inexpliquées pendant des heures. Ces services conditionnent aussi la sécurité : un DNS empoisonné redirige le trafic, un DHCP pirate impose une passerelle malveillante, une horloge décalée invalide des certificats et fausse tous les journaux.

Pour situer ces services dans la pile réseau, il est utile de garder en tête le modèle des couches réseau (page à venir) : DNS, DHCP et NTP (Network Time Protocol) sont des applications qui s’appuient sur les couches de transport UDP (User Datagram Protocol) et TCP (Transmission Control Protocol).

Comment résoudre un nom en adresse ?

Le DNS (Domain Name System) transforme un nom lisible comme tortuetech.com en une adresse machine. Cette traduction n’est pas un simple dictionnaire : c’est une hiérarchie distribuée à l’échelle planétaire. Quand un poste demande une résolution, il interroge d’abord un résolveur récursif, généralement fourni par le fournisseur d’accès ou l’entreprise. Ce résolveur ne connaît presque rien au départ : il questionne les serveurs racine, puis les serveurs de la zone .com, puis les serveurs autoritaires, qui détiennent la réponse définitive. Ce découpage repose sur la notion de zone : une zone DNS est la portion de l’arbre des noms dont l’administration est déléguée à un jeu de serveurs identifiés, et qui s’arrête là où commence une nouvelle délégation. La racine délègue .fr à son registre, qui délègue tortuetech.fr à ses serveurs autoritaires, trois zones distinctes, trois responsables différents, une seule chaîne de résolution. C’est l’enregistrement NS qui matérialise chaque délégation. On distingue donc trois rôles : le résolveur récursif qui mène l’enquête, le serveur autoritaire qui fait foi, et le cache qui mémorise les réponses pour accélérer les demandes suivantes.

Chaque réponse porte une durée de vie, le TTL (Time To Live), durée exprimée en secondes pendant laquelle la réponse peut être conservée en cache avant d’être considérée comme périmée. Un enregistrement avec un TTL de 3600 signifie que la réponse peut être conservée en cache une heure avant d’être revérifiée. C’est un compromis : un TTL long réduit la charge sur les serveurs DNS (Domain Name System) mais ralentit la prise en compte d’un changement ; un TTL court rend les modifications rapides mais multiplie les requêtes. Contrairement à une idée répandue, le TTL ne provoque pas de « propagation » instantanée : il définit seulement quand chaque cache expirera.

Les enregistrements DNS se déclinent selon leur usage. Un enregistrement A associe un nom à une adresse IPv4 (Internet Protocol version 4), un AAAA à une adresse IPv6 (Internet Protocol version 6). Le CNAME (Canonical Name) crée un alias vers un autre nom. Le MX (Mail eXchanger) désigne les serveurs de messagerie électronique, le TXT transporte du texte libre souvent utilisé pour la vérification et l’anti-spam, le NS (Name Server) délègue une zone DNS, le SRV (Service) publie des services avec port et priorité, le CAA (Certification Authority Authorization) restreint quelles autorités de certification peuvent émettre des certificats pour un domaine, et le PTR (Pointer) réalise la résolution inverse d’une adresse IP (Internet Protocol) vers un nom de domaine. Cette résolution inverse s’appuie sur une zone spéciale dite « in-addr.arpa » pour IPv4 (Internet Protocol version 4) ou « ip6.arpa » pour IPv6 (Internet Protocol version 6), et sert notamment à valider la légitimité des serveurs de messagerie.

À cette liste classique s’ajoutent deux types plus récents, SVCB (Service Binding) et sa déclinaison spécialisée HTTPS, normalisés par le RFC 9460 en novembre 2023. Ils publient dans le DNS les paramètres de connexion d’un service, protocoles supportés, port, adresses, et la clé publique utilisée par ECH (Encrypted Client Hello), là où il fallait auparavant se connecter d’abord pour les découvrir. Concrètement, un navigateur apprend qu’un site parle HTTP/3 sans passer par une connexion initiale puis une redirection. L’adoption progresse côté navigateurs et grands hébergeurs, plus lentement côté résolveurs anciens et serveurs DNS d’entreprise, à vérifier avant de s’appuyer dessus en production.

# Interroger l'enregistrement A d'un nom via un résolveur précis
dig @1.1.1.1 tortuetech.fr A +noall +answer
# tortuetech.fr.  3600  IN  A  203.0.113.10   <- le 3600 est le TTL en secondes

# Suivre toute la chaîne récursive depuis la racine
dig tortuetech.fr +trace

# Résolution inverse : d'une IP vers un nom (PTR)
dig -x 203.0.113.10 +short

Une même zone peut aussi ne pas répondre la même chose à tout le monde. Le split-horizon, ou vues DNS, consiste à servir des réponses différentes selon l’origine de la requête : le poste interne obtient l’adresse privée d’un serveur, l’internaute son adresse publique, ou rien du tout, si le nom n’existe que dans la vue interne. Le besoin d’exploitation est réel, mais deux précautions s’imposent. D’abord, ce n’est pas une mesure de sécurité : masquer un nom dans la vue publique ne protège pas la machine, qui reste joignable pour qui connaît son adresse, et les noms internes fuient largement par ailleurs, journaux de transparence des certificats, en-têtes, dépôts publics. Ensuite, c’est une source récurrente de diagnostics faussés : deux dig lancés depuis deux postes peuvent légitimement diverger, et le premier réflexe face à une résolution incohérente est de vérifier depuis quelle vue on interroge.

Sur le plan sécurité, le DNS (Domain Name System) a longtemps circulé en clair et sans signature, ouvrant la porte au cache poisoning (empoisonnement de cache DNS), une attaque où un attaquant insère de fausses réponses dans le cache d’un résolveur, et au DNS spoofing (usurpation de réponse DNS), où des réponses falsifiées sont envoyées à un client. DNSSEC (DNS Security Extensions) répond en signant cryptographiquement les enregistrements DNS, garantissant leur authenticité sans les chiffrer. Le chiffrement du transport DNS, lui, relève de DoT (DNS over TLS, DNS sur Transport Layer Security) et DoH (DNS over HTTPS), qui masquent les requêtes DNS aux observateurs du réseau en les encapsulant respectivement dans TLS (Transport Layer Security) ou HTTPS (HyperText Transfer Protocol Secure). Attention : DoH protège la confidentialité du trajet, il ne procure pas l’anonymat, car le résolveur voit toujours qui demande quoi. Le DNS peut aussi être détourné en canal d’exfiltration de données ou de tunneling, en encodant des données dans des noms de sous-domaines, d’où l’intérêt de journaliser et d’analyser le trafic DNS.

Comment configurer automatiquement un poste ?

Brancher une machine sans rien saisir manuellement repose sur le DHCP (Dynamic Host Configuration Protocol). Le mécanisme suit quatre étapes, le cycle DORA : le client diffuse un message DISCOVER pour trouver un serveur DHCP, un serveur répond par un message OFFER proposant une adresse IP (Internet Protocol), le client envoie un message REQUEST pour demander cette adresse, et le serveur confirme par un message ACK (Acknowledgement). Le client obtient alors un bail (lease) : une adresse IP louée pour une durée définie, avec des seuils de renouvellement à la moitié puis aux sept huitièmes du bail. Ce modèle descend historiquement de BOOTP (Bootstrap Protocol), un protocole plus ancien que le DHCP a étendu et remplacé.

Au-delà de l’adresse IP, le DHCP distribue des options : masque de sous-réseau, passerelle par défaut, serveurs DNS (Domain Name System), nom de domaine, serveurs NTP (Network Time Protocol), ou encore paramètres de démarrage réseau pour le PXE (Preboot eXecution Environment), qui permet d’amorcer un système sans disque dur local. Les réservations lient une adresse IP fixe à une adresse matérielle MAC (Media Access Control), identifiant unique d’une interface réseau, combinant la stabilité de l’adressage statique avec la gestion centralisée du DHCP. En IPv6 (Internet Protocol version 6), on parle de DHCPv6 (Dynamic Host Configuration Protocol version 6), qui coexiste avec l’autoconfiguration sans état (SLAAC (Stateless Address Autoconfiguration)), alors que DHCPv4 (Dynamic Host Configuration Protocol version 4) reste la norme sur IPv4 (Internet Protocol version 4).

# Extrait de configuration ISC DHCP : un sous-réseau avec options et réservation
subnet 192.168.10.0 netmask 255.255.255.0 {
  range 192.168.10.100 192.168.10.200;      # plage dynamique
  option routers 192.168.10.1;              # passerelle par défaut
  option domain-name-servers 192.168.10.2;  # serveur DNS interne
  option ntp-servers 192.168.10.2;          # source de temps NTP
  default-lease-time 3600;                  # bail par défaut (1 heure)
}

host imprimante {
  hardware ethernet 00:11:22:33:44:55;      # adresse MAC ciblée
  fixed-address 192.168.10.50;              # réservation stable
}

Le DHCP (Dynamic Host Configuration Protocol) se relie naturellement à l’inventaire et au DNS dynamique (mise à jour automatique des enregistrements DNS par le serveur DHCP), où le serveur DHCP met à jour automatiquement les enregistrements DNS des clients qu’il configure. Le risque majeur est le DHCP spoofing (usurpation de serveur DHCP) : un serveur pirate branché sur le segment réseau répond plus vite que le serveur légitime et impose une passerelle malveillante, permettant une interception des communications. La parade classique est le DHCP snooping (filtrage des réponses DHCP sur les commutateurs réseau), une fonctionnalité qui n’autorise les réponses DHCP que depuis des ports de confiance configurés. Laisser un service DHCP répondre sur un segment non prévu reste une faute fréquente ; pour bien cloisonner, appuyez-vous sur une segmentation par VLAN (Virtual Local Area Network, page à venir).

Pourquoi le temps et la visibilité sont-ils critiques ?

Le NTP (Network Time Protocol) synchronise les horloges des ordinateurs sur une hiérarchie de sources appelées strates (stratum) : le stratum 0 est une source de référence physique, comme une horloge atomique ou un récepteur GPS (Global Positioning System), le stratum 1 s’y raccorde directement via une connexion dédiée, et chaque niveau suivant (stratum 2, 3, etc.) s’appuie sur le précédent. Le protocole corrige la dérive des horloges en mesurant précisément l’aller-retour des messages, atteignant une précision de l’ordre de quelques millisecondes sur un réseau local Ethernet. Ce n’est pas un luxe : un décalage d’horloge invalide la vérification des certificats TLS (Transport Layer Security), protocole garantissant la confidentialité et l’intégrité des communications sur Internet, désaligne les journaux de plusieurs machines au point de rendre une investigation impossible, et casse des protocoles d’authentification sensibles au temps comme Kerberos (protocole d’authentification réseau basé sur des tickets valides pour une durée limitée), qui repose sur des tickets valides pour une durée limitée. Il faut distinguer l’heure système synchronisée par NTP du fuseau horaire applicatif, qui n’est qu’un affichage local : deux serveurs peuvent afficher des heures différentes tout en partageant la même horloge interne.

La supervision s’appuie souvent sur SNMP (Simple Network Management Protocol), protocole standard de gestion de réseau qui collecte des compteurs et des états auprès des équipements, tandis que Telnet (Telecommunication Network), protocole historique de connexion à distance non chiffrée, ne subsiste que pour du dépannage local isolé et doit être proscrit sur les réseaux exposés. La journalisation conjointe de DNS (Domain Name System), DHCP (Dynamic Host Configuration Protocol) et NTP (Network Time Protocol) constitue une mine pour la détection d’incidents : un pic de requêtes DNS vers des sous-domaines aléatoires trahit un tunneling, une explosion de baux DHCP signale une attaque d’épuisement d’adresses IP (Internet Protocol), et des sauts de temps répétés révèlent un problème matériel ou une manipulation malveillante. Ces flux alimentent naturellement une démarche de supervision et journalisation (page à venir).

Exemples et ateliers

Un atelier simple consiste à comparer une réponse issue du cache d’un résolveur récursif et une réponse d’un serveur autoritaire : la première arrive avec un TTL (Time To Live) décroissant, la seconde avec le TTL d’origine et le drapeau autoritaire (aa) positionné.

# Réponse potentiellement issue du cache (TTL variable, flag ra)
dig tortuetech.fr

# Réponse directe d'un serveur autoritaire (flag aa, TTL d'origine)
dig @ns1.tortuetech.fr tortuetech.fr +norecurse

# Vérifier l'écart d'horloge local par rapport à une source NTP
chronyc tracking   # cherchez "System time" et "Last offset"

Sous Windows, dig n’est pas installé par défaut ; l’équivalent natif est nslookup, moins riche mais suffisant pour les mêmes vérifications.

# Interroger un résolveur précis
nslookup tortuetech.fr 1.1.1.1

# Forcer un type d'enregistrement, puis résolution inverse
nslookup -type=MX tortuetech.fr
nslookup 203.0.113.10

# Vider le cache de résolution local, souvent la vraie cause du symptôme
ipconfig /flushdns

Un second atelier révélateur : forcer une horloge décalée de quelques minutes puis tenter une connexion HTTPS (HyperText Transfer Protocol Secure). Le navigateur refuse le certificat, non parce qu’il est invalide, mais parce que sa période de validité paraît incohérente vis-à-vis de l’heure erronée, démonstration directe du lien entre NTP (Network Time Protocol) et sécurité.

Pièges classiques

Modifier le mauvais serveur DNS (Domain Name System) est un grand classique : sur un poste, la résolution peut passer par un cache local, un résolveur d’entreprise puis un résolveur public, et corriger la mauvaise étape ne change rien. Croire que le TTL (Time To Live) provoque une propagation instantanée conduit à s’impatienter ou à multiplier les changements inutiles alors qu’il faut simplement attendre l’expiration des caches. Enfin, laisser un service DHCP (Dynamic Host Configuration Protocol) répondre sur un segment non prévu déclenche des conflits d’adressage IP (Internet Protocol) et ouvre la voie à l’interception.

À ne pas confondre

Le DNS (Domain Name System) n’est pas un annuaire d’identité : il nomme des machines et des services, pas des utilisateurs. Le DHCP (Dynamic Host Configuration Protocol) dynamique n’est pas équivalent à un adressage statique documenté : le premier gère l’attribution automatique, le second fige et trace une adresse fixe. DoH (DNS over HTTPS) n’apporte pas l’anonymat, seulement la confidentialité du transport. Et le fuseau horaire applicatif ne remplace pas la synchronisation NTP (Network Time Protocol) : afficher la bonne heure locale ne garantit pas que l’horloge interne soit juste. Le split-horizon n’est pas un cloisonnement : il change ce que le DNS répond, pas ce que le réseau laisse passer.

FAQ

Pourquoi mon changement DNS n’est-il pas visible immédiatement ?
Parce que les anciennes réponses restent en cache jusqu’à l’expiration de leur TTL (Time To Live). Réduire le TTL avant une migration, puis attendre cette durée, limite le délai.

DNSSEC chiffre-t-il mes requêtes DNS ?
Non. DNSSEC (DNS Security Extensions) signe les enregistrements pour prouver leur authenticité, mais ne chiffre rien. Pour la confidentialité du transport, il faut DoT (DNS over TLS) ou DoH (DNS over HTTPS).

Pourquoi le NTP est-il indispensable à la sécurité ?
Parce que la validation des certificats TLS (Transport Layer Security), l’authentification et la corrélation des journaux dépendent d’une heure cohérente. Un décalage de quelques minutes suffit à rejeter des connexions légitimes et à rendre une investigation illisible.

Comment empêcher un faux serveur DHCP sur mon réseau ?
En activant le DHCP snooping (filtrage des réponses DHCP sur les commutateurs réseau) sur les commutateurs, qui n’accepte les réponses DHCP que depuis des ports déclarés de confiance, et en segmentant le réseau.

Conclusion

DNS (Domain Name System), DHCP (Dynamic Host Configuration Protocol) et NTP (Network Time Protocol) forment le tissu conjonctif d’un réseau administrable : ils nomment, configurent et synchronisent sans qu’on y pense, jusqu’à ce qu’une panne rappelle leur importance. Maîtriser leurs mécanismes, chaîne de résolution DNS, cycle de bail DHCP, hiérarchie de strates NTP, transforme des incidents opaques en diagnostics rapides. Leur dimension sécurité est indissociable : signature DNSSEC (DNS Security Extensions), chiffrement DoT (DNS over TLS)/DoH (DNS over HTTPS), protections contre le DHCP spoofing (usurpation de serveur DHCP) et fiabilité du temps. Bien exploités, leurs journaux deviennent aussi une source précieuse de détection.

🐝 Ce qui arrive si on s’en passe

Un serveur de configuration pirate ne distribue pas seulement une fausse passerelle : il fournit aussi, dans les mêmes options, le serveur de noms et la source de temps. Faute de filtrage sur les commutateurs, un seul équipement branché sur le segment prend ainsi la main sur les trois services à la fois, redirige les résolutions et décale les horloges, ce qui brouille au passage les journaux qui auraient permis de le repérer. Le bail joue ensuite contre la victime : même une fois l’intrus débranché, les postes gardent la configuration reçue jusqu’à leurs tentatives de renouvellement, avec une fidélité que l’on souhaiterait à d’autres services.

🦫 Explication de la marmotte 🍫

Sur un réseau, les ordinateurs se parlent avec des numéros (adresses IP, Internet Protocol), mais les humains préfèrent des noms (noms de domaine). Le premier service, l’annuaire de noms, transforme un nom facile à retenir en numéro utilisable par les machines : il pose la question à des serveurs de plus en plus précis jusqu’à obtenir la bonne réponse, qu’il garde en mémoire un moment pour aller plus vite ensuite. Ce délai de mémoire explique pourquoi un changement met du temps à être visible partout.

Le deuxième service distribue les réglages : quand une machine arrive sur le réseau, il lui prête un numéro libre et lui indique tous les réglages nécessaires pour circuler sur le réseau, pour une durée limitée. Cela évite de tout configurer à la main et empêche deux machines d’avoir le même numéro.

Le troisième service met tout le monde à la même heure. Cela semble anodin, mais beaucoup de vérifications de sécurité, comme s’assurer qu’un site est bien celui qu’il prétend être, comparent des dates : si l’horloge est fausse, ces contrôles échouent. Les journaux d’activité, eux, deviennent impossibles à remettre dans l’ordre : quand chaque machine note l’heure à sa façon, personne ne peut plus reconstituer ce qui s’est passé pendant un incident.

Pages voisines

La citent

DNS, DHCP, NTP : services d'infrastructure réseau

Elle cite

: les deux pages se citent l’une l’autre.