![\"R\u00e9solution](\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/07\/how-dotcom-monitor-resolves-dns.webp\")
<\/p>\n<\/p>\n
Chaque contr\u00f4le de surveillance commence de la m\u00eame mani\u00e8re. Avant qu’un seul octet de votre page d’accueil, r\u00e9ponse API ou banni\u00e8re SMTP ne revienne, l’agent de surveillance doit transformer un nom d’h\u00f4te en une adresse IP. Cette premi\u00e8re \u00e9tape est la r\u00e9solution DNS, et la fa\u00e7on dont vous la configurez change ce que signifient r\u00e9ellement vos chiffres de disponibilit\u00e9.<\/p>\n
La plupart des \u00e9quipes ne touchent jamais aux param\u00e8tres DNS sur un moniteur. Elles pointent un contr\u00f4le sur Dotcom-Monitor vous propose quatre modes de r\u00e9solution 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\u00e9e sur le TTL).<\/p>\n Le DNS est la premi\u00e8re \u00e9tape de presque tous les protocoles que vous surveillez. Un contr\u00f4le de site web, une surveillance API<\/a>, une sonde de surveillance de serveur email<\/a>, un test de surveillance ping ICMP<\/a>\u2014chacun n\u00e9cessite une adresse IP avant de pouvoir ouvrir une connexion. Ainsi, l’agent r\u00e9sout d’abord le nom d’h\u00f4te, puis ex\u00e9cute TCP, TLS et la requ\u00eate au niveau applicatif par-dessus.<\/p>\n Cet ordre importe pour deux raisons. Premi\u00e8rement, le temps de recherche DNS fait partie de votre temps de r\u00e9ponse total, donc un r\u00e9solveur lent gonfle chaque chiffre en aval. Et deuxi\u00e8mement, une d\u00e9faillance DNS interrompt le contr\u00f4le avant qu’il ne commence. Si la r\u00e9solution \u00e9choue, il n’y a pas de connexion \u00e0 tester, pas de certificat \u00e0 valider, pas de code d’\u00e9tat \u00e0 lire. Le moniteur reporte une panne s\u00e9v\u00e8re, et la cause racine se trouve une couche en dessous de ce que vous pensiez surveiller.<\/p>\n Parce que le DNS est devant tout, la fa\u00e7on dont un agent g\u00e8re cette recherche est une vraie d\u00e9cision de conception, pas un d\u00e9tail. Le r\u00e9soudre \u00e0 neuf pour chaque requ\u00eate vous permet de d\u00e9tecter rapidement les probl\u00e8mes de r\u00e9solveur, mais vous ajoutez une charge et un temps de recherche \u00e0 chaque ex\u00e9cution. Le mettre en cache rend vos chiffres plus rapides et stables, mais un enregistrement DNS cass\u00e9 peut se cacher derri\u00e8re le cache pendant des heures. Les modes de Dotcom-Monitor existent pour vous permettre de choisir le compromis qui correspond \u00e0 ce que vous surveillez r\u00e9ellement. Pour une analyse approfondie de la r\u00e9duction de cette premi\u00e8re \u00e9tape, voyez notre guide sur l’am\u00e9lioration du temps de r\u00e9solution DNS<\/a>.<\/p>\n Dotcom-Monitor propose quatre modes de r\u00e9solution DNS sur une t\u00e2che de surveillance. Chacun change d’o\u00f9 vient l’adresse IP et combien de temps elle reste valable.<\/p>\n Cache de l’appareil est le mode par d\u00e9faut. Pendant un m\u00eame contr\u00f4le sur un appareil, l’agent r\u00e9sout chaque nom d’h\u00f4te une fois et partage cette r\u00e9ponse entre toutes les t\u00e2ches de cet appareil pour le reste de l’ex\u00e9cution. Si une t\u00e2che pr\u00e9c\u00e9dente dans le m\u00eame contr\u00f4le a d\u00e9j\u00e0 r\u00e9solu l’h\u00f4te, la t\u00e2che suivante r\u00e9utilise l’IP mise en cache. Sinon, l’agent effectue une recherche compl\u00e8te et met en cache le r\u00e9sultat pour la dur\u00e9e du contr\u00f4le.<\/p>\n L’avantage est l’efficacit\u00e9. La plupart des contr\u00f4les se terminent en moins d’une minute, il n’y a donc aucune raison de r\u00e9soudre le m\u00eame h\u00f4te toutes les quelques secondes. L’inconv\u00e9nient appara\u00eet dans le temps par t\u00e2che. Si un appareil surveille deux URLs sur le m\u00eame h\u00f4te, la premi\u00e8re URL porte le temps de recherche DNS et la seconde utilise l’IP mise en cache, donc la seconde semble plus rapide m\u00eame 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\u00e8re fois.<\/p>\n Pas de cache ignore compl\u00e8tement le cache de l’appareil. Chaque ex\u00e9cution de t\u00e2che effectue sa propre recherche DNS compl\u00e8te, aucune ex\u00e9cution ne r\u00e9utilise la r\u00e9ponse d’une ex\u00e9cution pr\u00e9c\u00e9dente. Cela vous donne un timing uniforme et comparable car chaque contr\u00f4le paye le m\u00eame co\u00fbt complet de r\u00e9solution.<\/p>\n Le compromis est la charge et la latence. Une recherche fra\u00eeche \u00e0 chaque ex\u00e9cution ajoute du temps \u00e0 chaque t\u00e2che 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\u00e9es sur un navigateur. Une page r\u00e9elle peut charger des dizaines d’\u00e9l\u00e9ments depuis le m\u00eame h\u00f4te, et r\u00e9soudre ce nom d’h\u00f4te des centaines de fois en quelques secondes n’est pas le fonctionnement d’un navigateur, donc r\u00e9soudre une fois par contr\u00f4le est le mod\u00e8le r\u00e9aliste l\u00e0-bas.<\/p>\n Cache TTL se comporte comme un r\u00e9solveur r\u00e9el sur la machine d’un utilisateur. Il respecte le temps de vie de l’enregistrement : l’agent met en cache l’adresse r\u00e9solue et continue de l’utiliser jusqu’\u00e0 l’expiration du TTL, puis r\u00e9sout \u00e0 nouveau via le serveur DNS local. C’est le mode qui imite le plus ce qu’un visiteur r\u00e9el exp\u00e9rimente, car leur navigateur et syst\u00e8me d’exploitation g\u00e8rent le cache de la m\u00eame mani\u00e8re.<\/p>\n Le risque r\u00e9side dans ce m\u00eame comportement. Si le serveur DNS supportant l’enregistrement \u00e9choue alors qu’une r\u00e9ponse valide est toujours dans le cache, le moniteur peut ne pas s’en apercevoir avant l’expiration du TTL, qui peut \u00eatre r\u00e9gl\u00e9 sur des heures, des jours, voire plus. Ainsi, Cache TTL est le bon choix lorsque vous souhaitez un timing r\u00e9aliste de l’exp\u00e9rience utilisateur, et le mauvais choix lorsque d\u00e9tecter rapidement une panne DNS est l’objectif principal du contr\u00f4le.<\/p>\n Serveur DNS externe pointe la recherche vers une IP de r\u00e9solveur sp\u00e9cifique que vous choisissez. Si vous savez que la plupart de vos utilisateurs utilisent un r\u00e9solveur public comme Google (8.8.8.8, 8.8.4.4) ou Cloudflare (1.1.1.1), vous pouvez tester la r\u00e9solution via ce service exact. Vous pouvez aussi viser un r\u00e9solveur que vous savez \u00eatre autoritaire pour la zone afin d’\u00e9viter la recherche r\u00e9cursive et obtenir des recherches plus rapides et directes.<\/p>\n La limite est la couverture. Tant que votre r\u00e9solveur choisi renvoie une r\u00e9ponse valide, le moniteur voit un succ\u00e8s, m\u00eame si le serveur DNS responsable du domaine se comporte mal. Ce mode teste donc la vision d’un r\u00e9solveur unique, pas la cha\u00eene compl\u00e8te. Un autre d\u00e9tail \u00e0 conna\u00eetre : chaque adresse IP de r\u00e9solveur distincte poss\u00e8de son propre cache, donc deux t\u00e2ches point\u00e9es vers diff\u00e9rents serveurs externes maintiennent des caches s\u00e9par\u00e9s.<\/p>\n C’est la d\u00e9cision qui d\u00e9route souvent, il vaut donc la peine de mettre les trois c\u00f4te \u00e0 c\u00f4te. La mise en cache (Cache de l’appareil) optimise pour l’efficacit\u00e9. Le non-cache (Pas de cache) optimise pour un timing comparable, reproductible et une d\u00e9tection rapide des \u00e9checs. La mise en cache temporaire (Cache TTL) optimise pour le r\u00e9alisme en faisant expirer les enregistrements comme le fait un navigateur.<\/p>\napi.example.com<\/code>, choisissent un intervalle, et poursuivent. Mais le comportement du r\u00e9solveur sous-jacent \u00e0 ce contr\u00f4le d\u00e9cide si vous mesurez l’exp\u00e9rience d’un vrai utilisateur, d\u00e9tectez les \u00e9checs DNS en quelques secondes, ou produisez des temps de r\u00e9ponse propres que vous pouvez comparer entre les ex\u00e9cutions. Vous ne pouvez pas optimiser les trois \u00e0 la fois.<\/p>\nPourquoi la r\u00e9solution DNS s’ex\u00e9cute en premier dans chaque contr\u00f4le<\/h2>\n
![\"Cycle](\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/07\/dns-check-lifecycle.webp\")
Les quatre modes DNS dans Dotcom-Monitor<\/h2>\n
Cache de l’appareil<\/h3>\n
Pas de cache<\/h3>\n
Cache TTL<\/h3>\n
Serveur DNS externe<\/h3>\n
Mise en cache vs pas de mise en cache vs mise en cache temporaire<\/h2>\n
\n