Les utilisateurs de Dotcom-Monitor ont un contrôle étendu sur la façon dont une résolution DNS est effectuée pour leurs tâches de surveillance. Sur la base de commentaires complets des utilisateurs, quatre options DNS différentes pour résoudre les noms d’hôtes sont disponibles pour les tâches de surveillance.

Dispositif mis en cache

L’appareil mis en cache est l’option par défaut et signifie que l’adresse du serveur de noms mis en cache (NS) récupérée lors de la surveillance d’une tâche précédente (cache d’appareil) sera initialement utilisée pour la surveillance. Si le cache de périphérique n’a pas l’adresse nécessaire, une enquête automatique pour l’adresse à partir des serveurs DNS racine sera effectuée. Lorsque cette option est définie, Dotcom-Monitor résoudra un nom d’hôte une fois par instance d’une vérification de périphérique. Ainsi, s’il y a des références au même nom d’hôte dans une ou plusieurs tâches dans le même appareil, alors la recherche DNS se produira une fois, puis sera mise en cache pour la durée de l’enregistrement de cet appareil.

La plupart des contrôles sont assez rapides et effectués 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 de cette option est que les données de performances peuvent varier par tâche dans le même appareil. Si vous surveillez deux URL dans le même appareil qui sont sur le même hôte, la première URL sera toujours plus lente, car elle inclura le temps de rechercher DNS, tandis que la deuxième URL utilisera l’adresse IP DNS mise en cache et la résolution DNS sera très rapide.

Ce type de cache est commun pour seulement les tâches avec un mode DNS Resolve identique.

Non mis en cache

Non mis en cache signifie que le cache de périphérique (cache des tâches précédentes) ne sera pas utilisé, de sorte que chaque nouvelle exécution exige une enquête distincte sur les serveurs racine DNS. Cette option est utile pour assurer des temps uniformes puisque la recherche DNS sera effectuée à chaque fois. Toutefois, l’option non-cache peut augmenter considérablement la charge sur les serveurs DNS et augmente également le temps de réponse pour les tâches de surveillance.

Cette option n’est pas disponible pour les plateformes de surveillance BrowserView ou UserView basées sur le navigateur puisqu’il n’est pas pratique de résoudre le même nom d’hôte des centaines de fois dans les quelques secondes qui ont suivi la vérification. Par exemple, pensez à une page Web qui contient de nombreux éléments sur le même serveur et qui ont toutes des résolutions DNS distinctes du serveur root. Dans ce type de scénario, la résolution une fois par vérification est suffisante.

TTL Mis en cache

TTL Cached signifie que le cache NS formé lors de la surveillance des tâches précédentes (cache d’appareil) sera initialement utilisé pour la surveillance. Si le cache de l’appareil n’a pas l’adresse nécessaire, une enquête automatique pour l’adresse sera effectuée à partir du serveur DNS local. Cette option imite le mieux l’expérience d’un utilisateur réel.

Il est important de noter que si l’option TTL est définie et que le serveur DNS spécifié échoue, dotcom-monitor peut ne pas détecter la défaillance jusqu’à l’expiration du TTL (ce qui peut prendre des jours ou des semaines). Cette option n’est recommandée que si la surveillance d’une résolution DNS appropriée n’est pas une priorité.

Ce type de cache est commun pour seulement les tâches avec un mode DNS Resolve identique.

Serveur DNS externe

DNS Server externe signifie qu’une adresse IP spécifiée sera considérée comme une adresse serveur DNS et sondée pour les données NS. Ceci est utile dans des situations spécifiques, par exemple, si vous savez que la plupart de vos clients utilisent un service public de mise en cache, comme Google (8.8.8.8, 8.8.4.4) ou Cloudflare (1.1.1.1). Dans ce cas, vous pouvez configurer le serveur DNS sur l’un des adresses IP de Google. Tant que le Google DNS spécifié fournit une réponse valide Dotcom-Monitor ne détectera pas une erreur DNS, même si un serveur DNS responsable du domaine ne fonctionne pas correctement.

Une autre situation implique si vous connaissez les serveurs responsables de la résolution des noms et ne vous souciez pas de toute la résolution de la chaîne DNS. Dans ce cas, vous pouvez spécifier le serveur DNS à utiliser pour la résolution DNS. Cette option peut fournir de meilleurs temps de résolution DNS ainsi que Dotcom-Monitor n’a pas à propager une surveillance à partir du serveur racine et peut aller directement sur le serveur DNS approprié. Toutefois, cette option peut ne pas détecter tous les problèmes liés au DNS.

Chaque adresse distincte crée un cache différent. Ainsi, par exemple, si deux tâches sous un seul appareil ont différents DNS externes (IPs différents), alors il y aura deux caches différentes.

  • Principes de base de surveillance DNS

    Que signifie DNS ?

    Le système de noms de domaine est l’une des technologies fondamentales de l’environnement Internet moderne puisque les informations sur l’adresse IP de l’hôte demandé sont une condition préalable pour recevoir une réponse à toute demande sur Internet. L’adresse IP elle-même est une valeur numérique comme «100.123.145.167», qui est difficile à mémoriser pour un internaute moyen. Toutes les adresses IP sur Internet sont des valeurs numériques uniques. En plus de sa structure complexe, les adresses IP d’un hôte sur Internet ne sont pas toujours stables et peuvent être modifiées, par exemple, lors de la modification de l’hébergement. Ainsi, pour rendre les adresses réseau plus confortables à utiliser pour un internaute moyen, le système de noms de domaine (DNS) a été introduit. Au lieu d’utiliser des adresses IP numériques, les humains utilisent des noms de domaine alphabétiques pour accéder aux ressources connectées à Internet (ordinateurs, serveurs Web, autres appareils).

    DNS fournit la traduction du nom de domaine symbolique demandé par le client dans l’adresse IP du serveur qui dessert cette zone de domaine. DNS utilise des hôtes dédiés nommés serveurs DNS pour stocker les enregistrements des ressources et traiter les demandes DNS. Un serveur DNS peut résoudre indépendamment les adresses réseau liées à son domaine de responsabilité, ou transmettre des demandes de zones qu’il ne sert pas aux serveurs DNS le long de la chaîne de recherche DNS.

    Un serveur DNS qui est responsable de transmettre les demandes DNS d’un client (par exemple, navigateurs) à d’autres serveurs DNS pour satisfaire la requête DNS du client s’appelle récurrateur DNS ou serveur récursif DNS. Une requête DNS commence généralement par une récurrorité DNS. En général, les serveurs DNS de FAI fonctionnent comme des résolvants récursifs DNS.

    Un serveur DNS qui stocke les enregistrements de ressources DNS et peut retourner les adresses IP nécessaires aux clients sans rediriger la demande vers d’autres serveurs DNS est appelé serveur DNS faisant autorité. Les serveurs DNS faisant autorité sont généralement des serveurs à la fin de la chaîne de rechercher DNS.

    Outre les résolvants récursifs DNS et les serveurs DNS faisant autorité, il existe deux autres types de serveurs intermédiaires impliqués dans le processus de recherche DNS – les noms de racines qui envoient une demande DNS à un emplacement plus spécifique et des serveurs de domaine de haut niveau qui servent la dernière partie d’un nom d’hôte (par exemple, .com, .uk, etc.).

    Fonctionnement de la résolution DNS dans les navigateurs Web

    Une fois que vous avez tapé une URL dans votre navigateur, le navigateur utilise le serveur DNS de votre fournisseur de services Internet (FAI) pour trouver l’adresse IP du serveur qui héberge le site Web demandé. Les adresses de ces serveurs DNS sont généralement envoyées par un fournisseur d’hébergement lors de la connexion ou doivent être spécifiées manuellement dans les paramètres de connexion IP. En d’autres termes, lorsque vous entrez un nom de domaine, par exemple, google.com, dans la barre d’adresse de votre navigateur, une demande de résolution est générée vers les serveurs DNS locaux qui sont installés automatiquement pour votre connexion Internet, ou que vous avez spécifié pour votre connexion Internet.

    Après réception d’une demande, le serveur DNS local recherche dans son cache des informations sur la cartographie du domaine vers une adresse IP et, s’il ne trouve pas l’adresse IP requise, une demande est transmise à l’un des serveurs DNS racine actuellement disponibles. En termes simples, le serveur local peut ne pas avoir les informations dont il a besoin dans son cache, mais il peut communiquer avec d’autres serveurs DNS.

    Pendant que le navigateur attend une réponse, le serveur DNS local contacte les serveurs principaux du monde – les serveurs DNS racine – et demande une adresse IP pour google.com. Le serveur Root DNS stocke uniquement des informations de référence sur les serveurs DNS pour les zones de domaine. Ainsi, le serveur DNS racine ne connaît pas l’adresse IP du domaine demandé, mais stocke les adresses IP des serveurs DNS qui sont responsables de tous les domaines dans la zone du domaine demandé, pour google.com ce sont les serveurs DNS de la zone de domaine .com.

    Le serveur DNS local reçoit l’adresse IP de l’un de ces serveurs DNS et tente de trouver une adresse IP demandée sur ce serveur. Ce serveur DNS ne connaît pas non plus l’adresse IP de Google, mais il sait que les informations de référence pour google.com sont hébergées par les serveurs DNS faisant autorité qui sont enregistrés pour ce domaine dans les enregistrements NS.

    Le serveur DNS local reçoit l’adresse IP de l’un de ces serveurs DNS dans le domaine .com et transmet la demande DNS au serveur DNS faisant autorité. Ce serveur DNS faisant autorité stocke l’adresse IP désirée et l’envoie au serveur DNS local.

    Le serveur DNS local reçoit l’adresse IP correcte et transmet l’adresse IP du nom d’hôte demandé au navigateur.

    Le navigateur obtient l’google.com’adresse IP, se connecte directement à son serveur et charge le site Web.

    En général, le processus de recherche DNS est si rapide qu’un utilisateur ne remarque pas si l’ensemble de la chaîne de recherche DNS a été sondé ou non.

    Erreurs DNS à surveiller

    Comme cela a été mentionné ci-dessus, le serveur DNS peut interroger séquentiellement d’autres serveurs DNS lors de l’exécution d’une requête récursive et stocker temporairement les informations contenues dans les réponses dans la mémoire de cache. Dans ce cas, le serveur DNS n’a pas besoin de demander à nouveau l’adresse IP d’un domaine et peut simplement utiliser l’adresse correspondante qui est déjà mise en cache. Le temps maximum autorisé pour stocker ces informations dans le cache est spécifié dans le champ TTL de l’enregistrement des ressources. Mise en cache DNS est l’une des vulnérabilités que les pirates utilisent pour rediriger le trafic vers les sites Web de pirates. Ce type de fraude impliquant l’usurpation d’adresses IP dans le cache des serveurs DNS est appelé empoisonnement cache DNS.

    En outre, les attaques de serveurs DNS telles que les tunnels DNS, les attaques d’amplification DNS, les attaques DDoS ou divers types de défaillances matérielles/réseau peuvent entraîner des pannes DNS et affecter négativement les performances des services Web.

    Surveillance DNS avec Dotcom-Monitor

    Si les attaquants ont modifié vos paramètres DNS, vous devez être la première personne qui est notifiée. Dotcom-Monitor fournit l’outil de surveillance DNS qui peut être utilisé comme mesure proactive pour défendre vos paramètres DNS. Lorsque le système détecte que votre nom d’hôte est résolu à une autre adresse IP que vous avez spécifié ou d’autres problèmes se sont produits lors de l’exécution de la recherchez DNS, l’erreur sera générée, et la notification d’alerte sera envoyée aux adresses de notification spécifiées. Ainsi, vous pouvez réagir immédiatement à la menace avant que vos utilisateurs ont été conduits vers les sites web de phishing et de logiciels malveillants.