Construisez d'abord l'idée, puis utilisez l'activité suivante pour la vérifier.
Enregistrements, résolveurs et l'ordre des recherches
Ce qu'un résolveur consulte réellement et dans quel ordre, quels types d'enregistrements vous rencontrerez, et pourquoi un nom peut se résoudre sur un hôte et échouer sur le suivant.
Ce que vous serez capable de faire
- Nommer les types d'enregistrements courants et ce à quoi chacun répond
- Suivre une recherche à travers le cache, le fichier hosts et le résolveur configuré
- Expliquer pourquoi deux hôtes peuvent être en désaccord sur le même nom
Avant cela : Vous avez besoin de « DNS - transformer des noms en adresses » pour l'idée de base, et de la leçon DHCP, car le résolveur utilisé par un hôte arrive généralement dans son bail.
Pourquoi c'est important : « Ça marche depuis ma machine » est presque toujours une réponse DNS qui diffère entre deux hôtes - un enregistrement mis en cache, une entrée du fichier hosts, ou un résolveur différent distribué par une étendue différente. Connaître l'ordre de recherche transforme cela d'un mystère en trois choses à vérifier.
Un résolveur ne consulte pas immédiatement un serveur DNS. Il parcourt une courte liste d'emplacements dans un ordre précis et s'arrête à la première réponse. Presque toutes les pannes DNS déroutantes viennent d'un désaccord sur l'emplacement qui a fourni cette réponse.
Les types d'enregistrements à connaître
| Type | Résultat | Usage courant |
|---|---|---|
| A | Nom vers adresse IPv4 | Recherche habituelle |
| AAAA | Nom vers adresse IPv6 | Équivalent pour IPv6 |
| CNAME | Nom vers un autre nom | Alias qui suit un déplacement |
| MX | Domaine vers serveur de messagerie | Destination du courrier |
| PTR | Adresse vers un nom | Recherche inverse et journalisation |
| NS | Zone vers ses serveurs | Délégation entre zones |
L'ordre d'une recherche
- Le cache propre à l'application, si elle en conserve un.
- Le cache du résolveur du système d'exploitation - une réponse précédente qui n'a pas encore expiré.
- Le fichier hosts, local et statique, consulté avant le réseau.
- Le résolveur configuré, généralement indiqué dans le bail DHCP.
Deux de ces quatre emplacements dépendent de l'hôte. Voilà pourquoi une machine résout un nom et sa voisine échoue : son cache contient encore une ancienne réponse, ou quelqu'un a ajouté une ligne au fichier hosts il y a deux ans et l'a oubliée.
Deux hôtes, un nom, deux réponses
Le système de gestion des stocks passe à une nouvelle adresse comme prévu et l'enregistrement A est mis à jour. Un hôte qui n'a jamais recherché ce nom obtient aussitôt la nouvelle adresse. La machine de l'a recherché une heure avant la bascule, avec un TTL d'un jour. Elle continue donc d'utiliser l'ancienne adresse jusqu'au lendemain. Dele signale une panne du système alors que ses collègues travaillent normalement.
Le TTL indique combien de temps une réponse peut vieillir
Chaque enregistrement porte une durée de vie : le temps pendant lequel un résolveur peut garder la réponse avant de redemander. Un TTL long réduit le nombre de requêtes, mais ralentit la prise en compte des changements. Un TTL court fait l'inverse. Avant une modification prévue, abaisser le TTL à l'avance permet une bascule rapide le moment venu.
Points clés à retenir
- Le résolveur s'arrête à la première réponse du cache, du fichier hosts ou du serveur configuré.
- Deux de ces sources sont propres à chaque hôte, d'où des réponses différentes entre machines.
- Un CNAME renvoie un nom, pas une adresse ; cette indirection simplifie les bascules.
- Le TTL détermine combien de temps une ancienne réponse persiste ; réduisez-le avant un changement prévu, pas pendant.
Prêt à continuer ?
Créez un compte gratuit pour enregistrer votre progression et passer le contrôle de connaissances.