Chaque contrôle de surveillance commence de la même manière. Avant qu’un seul octet de votre page d’accueil, réponse API ou bannière SMTP ne revienne, l’agent de surveillance doit transformer un nom d’hôte en une adresse IP. Cette première étape est la résolution DNS, et la façon dont vous la configurez change ce que signifient réellement vos chiffres de disponibilité.
La plupart des équipes ne touchent jamais aux paramètres DNS sur un moniteur. Elles pointent un contrôle sur api.example.com, choisissent un intervalle, et poursuivent. Mais le comportement du résolveur sous-jacent à ce contrôle décide si vous mesurez l’expérience d’un vrai utilisateur, détectez les échecs DNS en quelques secondes, ou produisez des temps de réponse propres que vous pouvez comparer entre les exécutions. Vous ne pouvez pas optimiser les trois à la fois.
Dotcom-Monitor vous propose quatre modes de résolution DNS pour cette raison exactement. Ce guide parcourt chacun d’eux, avec un focus particulier sur le choix que la plupart des gens se trompent : mise en cache versus pas de mise en cache versus mise en cache temporaire (basée sur le TTL).
Pourquoi la résolution DNS s’exécute en premier dans chaque contrôle
Le DNS est la première étape de presque tous les protocoles que vous surveillez. Un contrôle de site web, une surveillance API, une sonde de surveillance de serveur email, un test de surveillance ping ICMP—chacun nécessite une adresse IP avant de pouvoir ouvrir une connexion. Ainsi, l’agent résout d’abord le nom d’hôte, puis exécute TCP, TLS et la requête au niveau applicatif par-dessus.
Cet ordre importe pour deux raisons. Premièrement, le temps de recherche DNS fait partie de votre temps de réponse total, donc un résolveur lent gonfle chaque chiffre en aval. Et deuxièmement, une défaillance DNS interrompt le contrôle avant qu’il ne commence. Si la résolution échoue, il n’y a pas de connexion à tester, pas de certificat à valider, pas de code d’état à lire. Le moniteur reporte une panne sévère, et la cause racine se trouve une couche en dessous de ce que vous pensiez surveiller.
Parce que le DNS est devant tout, la façon dont un agent gère cette recherche est une vraie décision de conception, pas un détail. Le résoudre à neuf pour chaque requête vous permet de détecter rapidement les problèmes de résolveur, mais vous ajoutez une charge et un temps de recherche à chaque exécution. Le mettre en cache rend vos chiffres plus rapides et stables, mais un enregistrement DNS cassé peut se cacher derrière le cache pendant des heures. Les modes de Dotcom-Monitor existent pour vous permettre de choisir le compromis qui correspond à ce que vous surveillez réellement. Pour une analyse approfondie de la réduction de cette première étape, voyez notre guide sur l’amélioration du temps de résolution DNS.
Les quatre modes DNS dans Dotcom-Monitor
Dotcom-Monitor propose quatre modes de résolution DNS sur une tâche de surveillance. Chacun change d’où vient l’adresse IP et combien de temps elle reste valable.
Cache de l’appareil
Cache de l’appareil est le mode par défaut. Pendant un même contrôle sur un appareil, l’agent résout chaque nom d’hôte une fois et partage cette réponse entre toutes les tâches de cet appareil pour le reste de l’exécution. Si une tâche précédente dans le même contrôle a déjà résolu l’hôte, la tâche suivante réutilise l’IP mise en cache. Sinon, l’agent effectue une recherche complète et met en cache le résultat pour la durée du contrôle.
L’avantage est l’efficacité. La plupart des contrôles se terminent en moins d’une minute, il n’y a donc aucune raison de résoudre le même hôte toutes les quelques secondes. L’inconvénient apparaît dans le temps par tâche. Si un appareil surveille deux URLs sur le même hôte, la première URL porte le temps de recherche DNS et la seconde utilise l’IP mise en cache, donc la seconde semble plus rapide même si ce n’est pas le cas. C’est un comportement attendu, pas un bug, mais cela surprend ceux qui lisent un diagramme en cascade pour la première fois.
Pas de cache
Pas de cache ignore complètement le cache de l’appareil. Chaque exécution de tâche effectue sa propre recherche DNS complète, aucune exécution ne réutilise la réponse d’une exécution précédente. Cela vous donne un timing uniforme et comparable car chaque contrôle paye le même coût complet de résolution.
Le compromis est la charge et la latence. Une recherche fraîche à chaque exécution ajoute du temps à chaque tâche et met plus de trafic sur l’infrastructure DNS. Pas de cache n’est pas non plus disponible pour les plateformes BrowserView ou UserView basées sur un navigateur. Une page réelle peut charger des dizaines d’éléments depuis le même hôte, et résoudre ce nom d’hôte des centaines de fois en quelques secondes n’est pas le fonctionnement d’un navigateur, donc résoudre une fois par contrôle est le modèle réaliste là-bas.
Cache TTL
Cache TTL se comporte comme un résolveur réel sur la machine d’un utilisateur. Il respecte le temps de vie de l’enregistrement : l’agent met en cache l’adresse résolue et continue de l’utiliser jusqu’à l’expiration du TTL, puis résout à nouveau via le serveur DNS local. C’est le mode qui imite le plus ce qu’un visiteur réel expérimente, car leur navigateur et système d’exploitation gèrent le cache de la même manière.
Le risque réside dans ce même comportement. Si le serveur DNS supportant l’enregistrement échoue alors qu’une réponse valide est toujours dans le cache, le moniteur peut ne pas s’en apercevoir avant l’expiration du TTL, qui peut être réglé sur des heures, des jours, voire plus. Ainsi, Cache TTL est le bon choix lorsque vous souhaitez un timing réaliste de l’expérience utilisateur, et le mauvais choix lorsque détecter rapidement une panne DNS est l’objectif principal du contrôle.
Serveur DNS externe
Serveur DNS externe pointe la recherche vers une IP de résolveur spécifique que vous choisissez. Si vous savez que la plupart de vos utilisateurs utilisent un résolveur public comme Google (8.8.8.8, 8.8.4.4) ou Cloudflare (1.1.1.1), vous pouvez tester la résolution via ce service exact. Vous pouvez aussi viser un résolveur que vous savez être autoritaire pour la zone afin d’éviter la recherche récursive et obtenir des recherches plus rapides et directes.
La limite est la couverture. Tant que votre résolveur choisi renvoie une réponse valide, le moniteur voit un succès, même si le serveur DNS responsable du domaine se comporte mal. Ce mode teste donc la vision d’un résolveur unique, pas la chaîne complète. Un autre détail à connaître : chaque adresse IP de résolveur distincte possède son propre cache, donc deux tâches pointées vers différents serveurs externes maintiennent des caches séparés.
Mise en cache vs pas de mise en cache vs mise en cache temporaire
C’est la décision qui déroute souvent, il vaut donc la peine de mettre les trois côte à côte. La mise en cache (Cache de l’appareil) optimise pour l’efficacité. Le non-cache (Pas de cache) optimise pour un timing comparable, reproductible et une détection rapide des échecs. La mise en cache temporaire (Cache TTL) optimise pour le réalisme en faisant expirer les enregistrements comme le fait un navigateur.
| Mode | Comment il résout | Meilleur pour | Compromis principal |
|---|---|---|---|
| Cache de l’appareil (mise en cache) | Une fois par contrôle d’appareil, partagé entre ses tâches | Contrôles efficaces ; plusieurs tâches sur le même hôte | La première tâche porte le temps de recherche ; les tâches suivantes semblent plus rapides |
| Pas de cache (pas de mise en cache) | Recherche complète fraîche à chaque exécution | Timing uniforme ; détection rapide des problèmes DNS | Charge DNS plus élevée et latence accrue ; pas pour BrowserView/UserView |
| Cache TTL (mise en cache temporaire) | Respecte le TTL de l’enregistrement, puis résout à nouveau | Correspond à l’expérience utilisateur réelle | Un serveur DNS défaillant peut passer inaperçu jusqu’à l’expiration du TTL |
| Serveur DNS externe | Interroge une IP de résolveur que vous spécifiez | Test d’un résolveur public ou autoritaire spécifique | Voit uniquement la réponse de ce résolveur, pas la chaîne complète |
La version courte : mettez en cache pour la vitesse, skippez le cache pour détecter rapidement les échecs, respectez le TTL pour voir ce que les utilisateurs voient. Choisissez celui qui correspond à la raison d’être du contrôle.
Pourquoi la plupart des outils de surveillance manquent les problèmes DNS
Voici ce qui justifie cette configuration : la plupart des outils de surveillance ne vous laissent pas choisir. Ils résolvent un nom d’hôte une fois, le mettent en cache, et réutilisent cette réponse aussi longtemps que l’enregistrement est valide. Cela fonctionne jusqu’à ce qu’un problème DNS survienne en production — un enregistrement erroné, un serveur autoritaire en panne, un résolveur qui rend une mauvaise IP — car un moniteur en cache continue d’afficher du vert sur une réponse obsolète alors que les vrais utilisateurs rencontrent le problème.
Le contrôle granulaire du mode de résolution est rare dans l’espace de la surveillance. Forcer une recherche fraîche à chaque contrôle, faire expirer les enregistrements selon leur TTL, ou viser un résolveur spécifique est assez unique à Dotcom-Monitor, et c’est la limite entre un moniteur qui suppose que le DNS est OK et un moniteur qui le teste vraiment. Si détecter les problèmes DNS en production est l’objectif du contrôle, le comportement par défaut “mettre tout en cache” dont la plupart des outils se contentent est exactement ce qui les cache.
Comment choisir le bon mode DNS
Le mode que vous choisirez dépend de la question à laquelle répond le moniteur. Voici les scénarios les plus fréquents pour les équipes DevOps et SRE.
Vous voulez détecter les pannes DNS le plus rapidement possible. Utilisez Pas de cache. Quand un contrôle existe pour vous alerter dès que la résolution casse — un changement d’enregistrement raté chez un registrar, une zone expirée, un enregistrement piraté — vous ne voulez pas une réponse obsolète dans le cache. Une résolution fraîche à chaque exécution signifie que la panne apparaît au contrôle suivant, pas après un TTL de plusieurs heures. Associez cela à une alerte rigoureuse pour que le signal atteigne quelqu’un de disponible.
Vous souhaitez un timing qui corresponde à un visiteur réel. Utilisez Cache TTL. Si le contrôle soutient un SLA de disponibilité ou alimente un tableau de bord d’expérience utilisateur réelle, résoudre de la même manière qu’un navigateur rend vos chiffres honnêtes. Acceptez juste que la détection d’une panne DNS prenne jusqu’à un TTL, et ajoutez un contrôle Pas de cache séparé si ce délai compte.
Vous exécutez plusieurs tâches contre le même hôte. Le Cache de l’appareil par défaut est généralement la bonne option. Il maintient la charge DNS raisonnable et résout l’hôte une fois par exécution. Lisez le diagramme par tâche en gardant en tête la mise en cache : la première tâche porte le temps de recherche.
Vous vous souciez d’un résolveur spécifique. Utilisez Serveur DNS externe. Cela convient aux équipes qui valident que les résolveurs publics Google ou Cloudflare renvoient le bon enregistrement, ou qui vérifient un serveur autoritaire spécifique directement. C’est un test ciblé, maintenez donc un contrôle plus large en parallèle. Pour une stratégie plus globale, notre récapitulatif des outils de surveillance DNS explique comment ces contrôles s’articulent.
Quels types d’erreurs DNS chaque mode détecte
Le DNS est un point de défaillance fréquent, et il échoue de plusieurs manières. Les enregistrements changent lors d’une migration. Une zone expire. Un serveur autoritaire tombe en panne. Et dans le pire des cas, un attaquant empoisonne un cache pour diriger votre domaine vers un serveur qu’il contrôle. Votre mode de résolution décide à quelle vitesse ces problèmes apparaissent.
Pas de cache est le plus rapide pour signaler les problèmes de résolution car il ne fait jamais confiance à une réponse antérieure. Cache TTL est le plus lent, car un enregistrement valide en cache peut survivre à la panne derrière lui. Serveur DNS externe détecte les problèmes avec le résolveur ciblé mais peut manquer des soucis ailleurs dans la chaîne. Si vous voulez comprendre comment un contrôle se décompose par couche, notre guide sur les erreurs DNS, TCP, TLS et HTTP cartographie chaque étape. Et si les pannes vous préoccupent, la stratégie sur comment éviter les pannes DNS complète bien un contrôle Pas de cache.
Quel que soit le mode utilisé, l’intérêt de la surveillance DNS est d’être le premier à savoir quand un enregistrement change pour quelque chose que vous n’avez pas configuré. Dotcom-Monitor génère une erreur et déclenche une alerte lorsqu’un nom d’hôte résout vers une IP inattendue, afin que vous puissiez réagir avant que les utilisateurs ne tombent sur le mauvais serveur.
Comment configurer le mode DNS dans Dotcom-Monitor
Changer le mode de résolution prend quelques clics dans la tâche de surveillance. Les libellés exacts varient légèrement selon le type d’appareil, mais le processus est identique.
- Étape 1 : Ouvrez l’appareil ou la tâche que vous souhaitez configurer dans la plateforme Dotcom-Monitor.
- Étape 2 : Éditez les paramètres de la tâche et trouvez la section Mode de résolution DNS (ou Options DNS).
- Étape 3 : Choisissez l’un des quatre modes : Cache de l’appareil, Pas de cache, Cache TTL ou Serveur DNS externe.
- Étape 4 : Si vous avez choisi Serveur DNS externe, saisissez l’adresse IP du résolveur à interroger, comme 8.8.8.8 ou 1.1.1.1.
- Étape 5 : Enregistrez la tâche et laissez-la s’exécuter quelques intervalles, puis vérifiez la répartition du temps de réponse pour confirmer que le timing DNS correspond à vos attentes.
Parce que chaque appareil fonctionne depuis le réseau global de surveillance de Dotcom-Monitor, vous pouvez comparer comment la résolution se comporte depuis différents emplacements une fois le mode défini.
Le résumé
La résolution DNS est la première chose que chaque contrôle fait, donc le mode de résolution n’est pas un paramètre à laisser en pilote automatique. Mettez en cache quand vous voulez des contrôles efficaces contre un hôte partagé. Skippez le cache quand la détection rapide d’une panne DNS est l’objectif. Respectez le TTL quand vous voulez un timing qui correspond à un vrai utilisateur. Et ciblez un résolveur externe quand il vous faut tester la vision d’un service spécifique.
La plupart des équipes finissent par utiliser plusieurs modes sur leurs contrôles, car un seul moniteur répond rarement à toutes les questions. Adaptez le mode à la raison d’existence du contrôle, et vos chiffres commenceront à vous dire la vérité sur le DNS.
Surveillez le DNS avant qu’il ne casse votre disponibilité
Configurez le mode de résolution qui convient à chaque contrôle et soyez alerté dès qu’un enregistrement change. Dotcom-Monitor exécute la surveillance DNS depuis un réseau global avec le contrôle de cache que ce guide explique.
