FR 3142817 A1 20240607 FR 2212748 A 20221205 Procédés de détection d’un serveur de résolution de noms de domaine malveillant, équipement, serveur de confiance et programme d’ordinateur correspondants. L’invention concerne un procédé de détection d’un serveur DNS malveillant, mis en œuvre dans un équipement configuré avec au moins un serveur DNS de confiance, mettant en œuvre : la transmission (111), à destination d’au moins un desdits serveurs de confiance, d’au moins une requête d’activation d’un service de vérification DNS, la réception (112) d’au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance, la transmission (113) d’au moins une requête de résolution dudit au moins un nom de domaine, si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête est reçue mais comporte une anomalie, la réception (114) d’au moins une notification invitant ledit équipement à engager une action. Figure pour l’abrégé : Figure 1 Procédés de détection d’un serveur de résolution de noms de domaine malveillant, équipement, serveur de confiance et programme d’ordinateur correspondants. 1. Domaine de l’invention Le domaine de l’invention est celui des communications au sein d’un réseau de communication, par exemple un réseau informatique mettant en œuvre le protocole IP. Plus précisément, l’invention concerne les services de résolution de noms, par exemple DNS (en anglais « Domain Name System »), et propose une solution contribuant à détecter la présence d’un serveur malveillant impliqué dans la résolution de noms. 2. Art antérieur Le développement de l’Internet s’appuie sur un ensemble d’offres de services pour les marchés grand public et entreprises. Parmi celles-ci, les offres dites multi-services, dont les offres « Triple Play » (car proposant simultanément un accès à Internet, à des contenus vidéo (dont la diffusion de programmes télévisés) et à des services conversationnels (téléphonie sur IP)), ont accaparé une part importante du marché. L’un des facteurs communs aux offres des opérateurs est la présence systématique d’une passerelle domestique ou d’entreprise, souvent appelée CPE (« Customer Premises Equipment »), HG (« Home Gateway ») ou encore « box ». Un tel CPE sert classiquement d’interface entre le réseau local d’un utilisateur (« Local Area Network » (LAN)) et le réseau d’un opérateur auprès duquel l’utilisateur a souscrit une offre de service (« Internet Service Provider » (ISP), en anglais). C’est donc un équipement d’accès au réseau d’un opérateur par lequel transite le trafic caractéristique des différents services souscrits par l’utilisateur. Le CPE étant un point de passage pour le trafic en provenance ou à destination d’un utilisateur via un réseau d’opérateur, des attaques peuvent être menées sur cet équipement, par exemple pour intercepter des données sensibles de l’utilisateur, telles que des données bancaires. A titre d’exemple, une attaque consiste à modifier la configuration des informations DNS stockées dans un CPE, descriptives d’au moins un serveur de confiance associé à au moins une interface réseau via laquelle le CPE est apte à communiquer. Pour rappel, un service DNS permet d’associer une ressource (par exemple de type nom de domaine, URI (en anglais « Uniform Resource Identifier », en français « identifiant uniforme de ressource »), etc.) avec une ou plusieurs adresses IP pour accéder à cette ressource. Par exemple, le service DNS permet à un terminal connecté au CPE d’obtenir les adresses IPv4 et/ou IPv6 associées à un nom de domaine. Ainsi, quand un terminal connecté au CPE veut joindre un serveur applicatif identifié par un nom de domaine, une requête de résolution DNS est relayée par le CPE vers l’un au moins des serveurs DNS de confiance configurés dans le CPE. Une connexion est alors établie entre le terminal et le serveur applicatif en utilisant la ou les adresses IP retournées par le serveur DNS au CPE. Si un attaquant souhaite capter le trafic d’un utilisateur et intercepter certaines de ses données, il peut, selon un premier exemple, fournir à l’utilisateur une adresse IP d’un serveur applicatif malveillant utilisé par l’attaquant, en lieu et place d’une adresse IP du serveur applicatif (légitime) auquel l’utilisateur souhaitait initialement accéder. Pour ce faire, l’attaquant peut modifier la configuration des informations DNS stockées dans le CPE pour qu’il relaie les requêtes DNS émises par le terminal vers un serveur DNS malveillant géré par l’attaquant, au lieu du serveur DNS de confiance initialement configuré. Toutes les communications qui nécessitent des échanges DNS peuvent ainsi être interceptées par le serveur DNS malveillant. L’attaquant peut alors rediriger le trafic de l’utilisateur victime de l’attaque vers des serveurs frauduleux qui émuleront certains sites (par exemple, des serveurs utilisés pour réaliser une transaction financière). Selon un deuxième exemple, l’attaquant peut aussi décider de rediriger les requêtes applicatives émises par l’utilisateur vers un serveur applicatif « légitime », pour éviter que l’utilisateur ne se rende compte qu’il est la cible d’une attaque. Dans ce cas, l’attaquant dirige d’abord les requêtes de l’utilisateur vers un serveur applicatif « frauduleux » en manipulant les requêtes DNS, puis vers le serveur applicatif « légitime ». Pour ce faire, comme dans le premier exemple, l’attaquant peut modifier la configuration des informations DNS stockées dans le CPE pour qu’il relaie les requêtes DNS émises par le terminal vers un serveur DNS malveillant géré par l’attaquant, au lieu du serveur DNS de confiance initialement configuré. Toutefois, dans le deuxième exemple, le serveur applicatif frauduleux « n’émule » pas le service demandé mais se comporte comme un relais (« proxy ») qui termine l’association de sécurité avec le terminal de l’utilisateur et relaie les messages entre ce terminal et le serveur applicatif légitime. Ce faisant, le serveur applicatif frauduleux accède au contenu des messages chiffrés. La protection par un mot de passe de l’accès à l’interface d’administration du CPE (qui permet notamment de configurer les informations DNS dans le CPE) ne suffit pas à protéger le CPE des attaques décrites précédemment. En effet, comme la plupart des utilisateurs n’utilisent pas (voire ne soupçonnent même pas l’existence) d’interface d’administration du CPE, la protection de l’accès à cette interface d’administration est souvent faible. De même, la protection de l’accès à l’interface d’administration du CPE par adresse MAC (« Medium Access Control ») peut s’avérer inefficace car un attaquant peut changer l’adresse MAC de son terminal pour être identique à celle(s) autorisée(s) par le CPE. Ces adresses MAC peuvent en effet être acquises de façon malveillante en écoutant les échanges Wi-Fi, par exemple. Il existe donc un besoin d’une nouvelle solution pour détecter une modification frauduleuse des informations de configuration DNS, et qui puisse notamment préserver la sécurité des données personnelles des utilisateurs. 3. Exposé de l’invention L’invention propose une solution pour la détection d’un serveur de résolution de noms de domaine malveillant, mise en œuvre dans un équipement configuré avec au moins un serveur de résolution de noms de domaine de confiance associé à au moins une interface réseau via laquelle ledit équipement est apte à communiquer. Un tel équipement met en œuvre : la transmission, à destination d’au moins un desdits serveurs de confiance, d’au moins une requête d’activation d’un service de vérification de résolution de noms de domaine, la réception d’au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface, la transmission d’au moins une requête de résolution dudit au moins un nom de domaine, si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, la réception d’au moins une notification invitant ledit équipement à engager une action. La solution proposée permet ainsi à un équipement (par exemple un terminal, un CPE, etc.) d’engager une action si un serveur de confiance de résolution de noms de domaine, configuré pour au moins une interface réseau (par exemple Ethernet, Wireless LAN, etc.) de l’équipement, détecte une anomalie dans une requête de résolution de domaine spécifique émise via une interface de l’équipement. Plus précisément, selon la solution proposée, le serveur de confiance peut générer un ou plusieurs noms de domaine spécifiques pour au moins une interface de l’équipement. Par exemple, un tel nom de domaine, noté par exemple « TARGET_HB_FQDN », peut être généré de façon aléatoire par le serveur de confiance. On considère donc qu’un tel nom de domaine est unique et que le serveur de confiance est identifié comme serveur autoritaire ou faisant autorité (appelé « authoritative server » en anglais) pour le nom de domaine ainsi généré. Le serveur de confiance peut transmettre à l’équipement le ou les noms de domaine générés pour au moins une de ses interfaces. De tels noms de domaine sont donc connus uniquement du serveur de confiance et de l’équipement. Le serveur de confiance peut alors détecter la présence d’un serveur malveillant si aucune requête de résolution de ce ou ces noms de domaine n’est reçue par lui, ou si une ou plusieurs requêtes de résolution de ce ou ces noms de domaine (appelées par exemple dans la suite « HB ») sont reçues mais comportent une anomalie (par exemple, l’adresse source de la requête de résolution du nom de domaine n’est pas une adresse de l’équipement). Dans ce cas, une notification est envoyée par le serveur de confiance à l’équipement, afin que l’équipement puisse engager au moins une action permettant par exemple de corriger la configuration de résolution de noms de domaine active. Une telle action peut ainsi être exécutée automatiquement par l’équipement, sans intervention d’un utilisateur. De ce fait, quand bien même l’utilisateur n’aurait aucune connaissance technique des systèmes informatiques, les informations de configuration DNS de l’équipement peuvent être réinitialisées, ou le trafic vers ou en provenance d’un serveur applicatif malveillant être stoppé. La solution proposée contribue ainsi à améliorer la robustesse des services IP à valeur ajoutée (services DNS inclus) et à préserver l’utilisateur d’attaques qui reposeraient sur un service de résolution de noms tel que le service DNS. De plus, la solution proposée ne requiert pas d’inspection de trafic dans le réseau (par exemple dans le réseau d’accès) ou de profilage des communications pour la détection d’anomalies. La solution peut ainsi être mise en œuvre indépendamment de l’offre de connectivité sous-jacente. On note qu’un équipement selon l’invention peut embarquer un ou plusieurs « clients DNS ». En d’autres termes, un client DNS peut être supporté par le système d’exploitation (ou OS pour « Operating System » en anglais) d’un équipement, ou être spécifique à une application. Dans ce dernier cas, plusieurs clients DNS peuvent être activés sur un même équipement, chacun de ces clients étant identifié de façon univoque. Le procédé selon l’invention peut être mis en œuvre par l’un de ces clients DNS ou être supporté par une application dédiée. Notamment, chaque client DNS d’un équipement peut mettre en œuvre les étapes décrites ci-dessus. L’invention ne fait aucune hypothèse quant à l’interface interne utilisée entre une application et une fonction de résolution de noms (un client DNS, typiquement). Selon un mode de réalisation particulier, ladite au moins une réponse comporte également des données de vérification (notées par exemple « CHALLENGE ») générées par ledit serveur de confiance pour ladite au moins une requête d’activation. Ladite au moins une requête de résolution dudit au moins un nom de domaine générée par l’équipement comporte alors une preuve d’intégrité obtenue à partir desdites données de vérification. A réception d’une requête de résolution par le serveur de confiance, ce dernier peut ainsi vérifier l’intégrité de la requête de résolution grâce à la preuve d’intégrité, ce qui contribue à améliorer la sécurité de la solution proposée. Par exemple, la preuve d’intégrité est un condensé (encore appelé « hachage » ou « hash ») desdites données de vérification. Dans un mode de réalisation particulier, ladite au moins une requête de résolution dudit au moins un nom de domaine comporte un indicateur requérant la génération, par ledit serveur de confiance, de nouvelles données de vérification. Un tel changement des données de vérification contribue à renforcer la sécurité de la solution proposée. L’équipement peut alors être à l’initiative d’un changement des données de vérification. Comme décrit par la suite avec la description d’un mode de réalisation particulier, l’équipement envoie par exemple une requête de résolution notée « HB (C, NONCE1) ». En variante, c’est le serveur qui peut être à l’initiative d’un changement des données de vérification. Un tel changement des données de vérification peut notamment être mis en œuvre de façon régulière ou selon d’autres politiques locales au serveur de résolution de noms. En particulier, ladite au moins une réponse et/ou ladite requête de résolution peuvent être chiffrées. Un tel chiffrement permet de préserver les données de vérification transmises dans la réponse à la requête d’activation (i.e. réponse du serveur de confiance vers l’équipement) ou la preuve d’intégrité transmise dans la requête de résolution « HB ». Dans un mode de réalisation particulier, ladite au moins une réponse comporte également une information de récurrence (notée par exemple « EPOCH »). Ladite au moins une requête de résolution dudit au moins un nom de domaine est transmise en tenant compte de ladite information de récurrence. Par exemple, l’information de récurrence prévoit la périodicité d’envoi des requêtes de résolution (« HB ») par l’équipement, l’envoi d’une requête de résolution au redémarrage de l’équipement, lors d’une connexion à un nouveau réseau, etc. Dans un mode de réalisation particulier, ladite au moins une requête d’activation comporte au moins une adresse de contact dudit équipement (notée par exemple « CONTACT_URI »). De cette façon, le serveur de confiance peut envoyer à l’équipement une notification vers cette adresse de contact pour informer l’équipement d’anomalie(s) constatée(s) dans la résolution de noms de domaine. On suppose que l’équipement met en place les procédures adéquates pour pouvoir recevoir ces messages (par exemple configuration d’un pare-feu, NAT). Ces procédures sont connues en soi et ne sont donc pas réitérées ici. Un exemple est notamment décrit dans le document RFC6887 « Port Control Protocol (PCP) » d’avril 2013. Selon un mode de réalisation particulier, les informations descriptives dudit au moins un serveur de confiance sont stockées dans un registre maintenu par ledit équipement et dont l’accès est protégé. On rappelle qu’il est classique de configurer au moins une liste d’au moins un serveur de confiance associé à au moins une interface d’un équipement. Selon l’invention, de telles informations de configuration (i.e. informations descriptives dudit au moins un serveur de confiance) sont stockées dans un registre spécifique, dont l’accès est protégé, par exemple par un mot de passe ou des clés de vérification. De cette façon, un attaquant n’a pas directement accès à ces informations de configuration, ce qui contribue à renforcer la sécurité de la solution proposée. En particulier, le registre dont l’accès est protégé est distinct de tout autre registre utilisé pour le stockage d’autres informations relatives à la résolution de noms de domaine. Notamment, l’emplacement de ce registre protégé n’est pas prédéfini, et peut être différent pour différents équipements. L’emplacement du registre peut notamment être choisi aléatoirement au moment de l’activation du service de vérification de résolution de noms de domaine. Selon un mode de réalisation particulier, l’équipement étant configuré pour exécuter au moins une action, ledit équipement exécute au moins une action donnée (par exemple, préconfigurée) à réception d’une notification l’invitant à exécuter ladite au moins une action. Par exemple, ladite au moins une action appartient au groupe comprenant : remplacer la configuration de résolution de noms de domaine active par la configuration d’un desdits serveurs de confiance, désactiver les communications sortantes à l’exception des communications vers l’un desdits serveurs de confiance, générer une notification locale pour informer un utilisateur d’une modification de la configuration de résolution de noms de domaine, demander l’envoi de la configuration de résolution de noms de domaine active. Notamment, de telles actions peuvent avoir été préalablement configurées pour l’équipement. Ainsi, à réception d’une notification, l’équipement connaît l’action qu’il doit exécuter. La solution proposée ne fait donc pas intervenir l’utilisateur pour la résolution des anomalies. L’utilisateur n’est donc pas censé disposer de connaissances techniques particulières pour la mise en œuvre de l’invention. L’invention concerne également un tel procédé de détection d’un serveur de résolution de noms de domaine malveillant, mis en œuvre dans le serveur de confiance. Un tel serveur de confiance met en œuvre les étapes suivantes : la réception d’au moins une requête d’activation d’un service de vérification de résolution de noms de domaine, en provenance dudit équipement, la transmission d’au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface, si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, la transmission audit équipement d’au moins une notification l’invitant à exécuter une action. Comme déjà indiqué, le serveur de confiance peut générer un ou plusieurs noms de domaine spécifiques pour au moins une interface de l’équipement et détecter un problème dans le service de vérification de résolution de noms de domaine si aucune requête de résolution du nom de domaine spécifique n’est reçue, ou si une requête de résolution du nom de domaine spécifique est reçue mais comporte une anomalie. Si un problème est détecté, le serveur de confiance peut envoyer une notification à au moins une adresse de contact dudit équipement portée par ladite requête d’activation ou à l’adresse utilisée par ledit équipement pour transmettre ladite requête d’activation. Ces vérifications sont rendues possibles du fait que le serveur de confiance fait autorité pour les noms de domaines générés pour au moins une interface d’un équipement. Selon un mode de réalisation particulier, une anomalie est détectée si ladite au moins une requête de résolution dudit au moins un nom de domaine et si ladite au moins une requête d’activation ne proviennent pas du même équipement. Par exemple, le serveur de confiance compare les adresses utilisées pour l’émission de la requête d’activation et pour l’émission de la requête de résolution dudit au moins un nom de domaine. Si elles diffèrent ou ne sont pas associées au même équipement, le serveur de confiance détecte une anomalie. Selon un mode de réalisation particulier, ladite au moins une réponse comporte également des données de vérification générées par ledit serveur de confiance pour ladite au moins une requête d’activation. Dans ce cas, ladite au moins une requête de résolution dudit au moins un nom de domaine comporte une preuve d’intégrité obtenue à partir desdites données de vérification, et une anomalie est détectée si ladite preuve d’intégrité portée par ladite au moins une requête de résolution dudit au moins un nom de domaine n’est pas cohérente avec une preuve d’intégrité obtenue à partir des données de vérification connues du serveur de confiance. Par exemple, le serveur de confiance génère de façon aléatoire des données de vérification, et les transmet dans sa réponse. L’équipement calcule un condensé de ces données de vérification, et le transmet dans la requête de résolution du nom de domaine spécifique. A réception, le serveur de confiance peut calculer localement un condensé des données de vérification qu’il connaît, et le comparer avec le condensé reçu dans la requête de résolution. Selon un mode de réalisation particulier, ladite au moins une réponse comporte de nouvelles données de vérification générées par ledit serveur de confiance pour ledit équipement, à l’initiative dudit serveur de confiance ou à réception d’une requête en provenance dudit équipement. Comme indiqué précédemment, les données de vérification peuvent effectivement être renouvelées à l’initiative de l’équipement ou du serveur de confiance, par exemple régulièrement, de façon à améliorer la sécurité de la solution proposée. Selon un mode de réalisation particulier, ladite au moins une réponse comporte également une information de récurrence (notée par exemple « EPOCH ») de ladite au moins une requête de résolution dudit au moins un nom de domaine, et une anomalie est détectée si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance ou si ladite au moins une requête de résolution dudit au moins un nom de domaine n’est pas cohérente avec ladite information de récurrence. A nouveau, l’utilisation d’une telle information de récurrence contribue à renforcer la sécurité de la solution proposée. Selon un mode de réalisation particulier, lesdites requêtes d’activation et/ou de résolution dudit au moins un nom de domaine utilisent une option selon le mécanisme DNS tel que décrit dans le document RFC 6891 (« Extension Mechanisms for DNS » (EDNS) d’avril 2013) pour transmettre différentes informations entre l’équipement et le serveur de confiance (par exemple un nom de domaine (« TARGET_HB_FQDN »), des données de vérification (« CHALLENGE »), des informations de récurrence (« EPOCH »), une adresse de contact (« CONTACT_URI »), etc.). Dans un autre mode de réalisation, l’invention concerne un équipement correspondant. Un tel équipement est notamment adapté pour la mise en œuvre d’un procédé de détection d’un serveur de résolution de noms de domaine malveillant selon au moins un mode de réalisation de l’invention. Ainsi, un tel équipement peut comporter les différentes caractéristiques relatives au procédé selon l’invention, qui peuvent être combinées ou prises isolément. Par exemple, l’équipement est de type CPE, terminal, etc. L’équipement peut être raccordé à un réseau fixe, un réseau mobile, un réseau d’objets connectés (par exemple un réseau maillé selon le protocole « Thread »), etc. Dans un autre mode de réalisation, l’invention concerne un serveur de confiance correspondant. Un tel serveur de confiance est notamment adapté pour la mise en œuvre d’un procédé de détection d’un serveur de résolution de noms de domaine malveillant selon au moins un mode de réalisation de l’invention. Ainsi, un tel serveur peut comporter les différentes caractéristiques relatives au procédé selon l’invention, qui peuvent être combinées ou prises isolément. Dans encore un autre mode de réalisation, l’invention concerne un ou plusieurs programmes d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé de détection d’un serveur de résolution de noms de domaine malveillant selon au moins un mode de réalisation de l’invention, lorsque ce ou ces programmes est/sont exécuté(s) par un processeur. Les procédés selon l’invention peuvent donc être mis en œuvre de diverses manières, notamment sous forme câblée et/ou sous forme logicielle. En particulier, le procédé selon l’invention peut être implémenté par un module générique, une application, etc. 4. Liste des figures D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la illustre les principales étapes d’un procédé de détection d’un serveur de résolution de noms de domaine malveillant selon un mode de réalisation, la présente le format générique d’une option WADE selon un mode de réalisation, la présente un exemple d’option WADE selon un mode de réalisation, la illustre un exemple de messages échangés entre un client DNS et un serveur de confiance sans détection d’anomalie, la illustre un exemple de messages échangés entre un client DNS et un serveur de confiance avec modification des données de vérification à l’initiative du client DNS, la illustre un exemple de messages échangés entre un client DNS et un serveur de confiance avec modification des données de vérification à l’initiative du serveur de confiance, la illustre un exemple de messages échangés entre un client DNS et un serveur de confiance avec détection d’une anomalie de type non-respect de l’information de récurrence, la illustre un exemple de messages échangés entre un client DNS et un serveur de confiance avec détection d’une anomalie liée à l’adresse source, la illustre un exemple de messages échangés entre un client DNS et un serveur de confiance pour la désactivation d’un service de vérification de résolution de noms de domaine, et la présente la structure simplifiée d’un équipement, respectivement d’un serveur de confiance, selon un mode de réalisation. 5. Description d’un mode de réalisation de l’invention 5.1 Principe général On se place dans le contexte d’un équipement (par exemple un terminal, un CPE) configuré avec des informations descriptives d’au moins un serveur de confiance de résolution de noms de domaine associé à une interface réseau via laquelle l’équipement est apte à communiquer. Le principe général de l’invention repose sur la génération, par le serveur de confiance, d’au moins un nom de domaine spécifique pour au moins une interface de l’équipement et la mise en place d’une procédure d’émission de requêtes de résolution liées à ce nom de domaine spécifique. Le serveur de confiance peut ainsi détecter un problème dans un service de résolution de noms de domaine s’il ne reçoit aucune requête de résolution du nom de domaine spécifique, ou si une requête de résolution du nom de domaine spécifique qu’il reçoit comporte une anomalie. Le serveur de confiance peut alors informer l’équipement, qui peut dès lors engager des actions adéquates. On présente, en relation avec la , les principales étapes mises en œuvre pour la détection d’un serveur de résolution de noms de domaine malveillant selon l’invention. On considère un équipement H 11 configuré avec au moins un serveur de confiance de résolution de noms de domaine DNS 12 associé à au moins une interface réseau via laquelle l’équipement est apte à communiquer. Au cours d’une première étape 111, l’équipement 11 transmet au serveur de confiance 12, via au moins une interface réseau, au moins une requête d’activation ACTIV d’un service de vérification de résolution de noms de domaine. Le serveur de confiance 12 reçoit ladite au moins une requête d’activation ACTIV au cours d’une étape 121. La requête d’activation peut notamment être une requête dédiée, telle qu’une requête DNS réservée à l’activation du service de vérification de résolution de noms de domaine. Un exemple d’une telle requête dédiée est une requête de résolution d’un nom de domaine dédié, apte à déclencher l’activation du service de vérification. Ce nom de domaine dédié peut être un nom configuré lors de la souscription au service (par exemple « peraspera.example ») ou un nom de domaine réservé à cet usage et qui peut être utilisé par tous les opérateurs (par exemple « peraspera.arpa »). En variante, la requête d’activation peut être une requête « non dédiée ». Dans ce cas, l’équipement ne génère pas une requête DNS portant sur un nom de domaine dédié à l’activation du service de vérification de résolution de noms de domaine, mais utilise une requête DNS classique, par exemple une requête DNS émise pour les besoins d’une application embarquée dans l’équipement, et y insère des informations pour l’activation du service de résolution de noms de domaine. On détourne ainsi une requête DNS classique en y insérant des informations particulières, par exemple sous la forme d’une nouvelle option selon un mécanisme d’extension DNS tel que décrit ci-après. Le serveur de confiance 12 peut générer au moins un nom de domaine spécifique pour l’interface réseau utilisée, et transmettre à l’équipement 11 au moins une réponse comportant le ou les noms de domaine spécifiques, au cours d’une étape 122. On considère qu’un tel nom de domaine est unique et que le serveur de confiance fait autorité pour le nom de domaine ainsi généré. Selon l’exemple illustré par la , le serveur de confiance transmet une seule réponse REP portant un nom de domaine unique. L’équipement 11 reçoit la réponse REP au cours d’une étape 112. L’équipement 11 peut alors transmettre au serveur de confiance 12 au moins une requête de résolution du nom de domaine unique REQ DNS au cours d’une étape 113. Une telle requête de résolution portant sur le nom de domaine unique est par la suite également appelée HB (« Heartbeat » en anglais). Si le serveur de confiance 12 reçoit une requête REQ DNS au cours d’une étape 123, mais que cette requête REQ DNS comporte une anomalie, le serveur de confiance 12 envoie une notification NOTIF à l’équipement 11 au cours d’une étape 124, l’invitant à exécuter une action. Si le serveur de confiance 12 ne reçoit aucune requête REQ DNS portant sur le nom de domaine unique communiqué à l’équipement 11 lors de l’activation de la procédure (étapes 122/112), le serveur de confiance 12 envoie une notification NOTIF à l’équipement 11 l’invitant à exécuter une action, par exemple après une période d’attente. La période d’attente peut notamment être prédéfinie, configurée dans le serveur de confiance, connue de l’équipement ou transmise à l’équipement, etc. L’équipement 11 peut ainsi recevoir, au cours d’un étape 114, une notification NOTIF l’invitant à exécuter une action, par exemple une action prédéfinie. L’équipement peut ensuite exécuter une telle action, sans nécessiter d’interaction avec un utilisateur de l’équipement ou un administrateur d’un réseau local (par exemple administrateur d’un réseau domestique, administrateur d’un CPE). Comme décrit par la suite, différentes informations peuvent être utilisées par le serveur de confiance pour détecter une anomalie lors du traitement d’une requête de résolution de noms de domaine. Notamment, des données de vérification et/ou une information de récurrence peuvent être transmises dans la réponse REP du serveur de confiance vers l’équipement, et utilisées par l’équipement pour la gestion de la transmission de la requête de résolution du nom de domaine unique REQ DNS vers le serveur de confiance. Une anomalie peut notamment être détectée si la requête d’activation ACTIV et la requête de résolution du nom de domaine unique REQ DNS ne proviennent pas du même équipement, ou si une preuve d’intégrité, obtenue à partir des données de vérification et véhiculée par la requête REQ DNS, n’est pas cohérente avec une preuve d’intégrité obtenue à partir des données de vérification connues du et maintenues localement par le serveur de confiance, ou si l’émission de la ou des requêtes REQ DNS n’est pas conforme à l’information de récurrence, ou si la requête REQ DNS inclut une information d’un relais DNS, par exemple. 5.2 Description détaillée d’un mode particulier de réalisation 5.2.1 Configuration initiale On décrit ci-après un exemple détaillé de mise en œuvre de l’invention. On considère qu’un utilisateur de l’équipement (par exemple un terminal) souhaite activer un service de vérification de résolution de noms de domaine. Par la suite, on nomme un tel service « PER ASPERA » (« PER-DNS client guards Against malicious DNS Server swaPping, traffic intERception, and datA theft », ou « procédure de détection et de mitigation de changement de configuration DNS »). Par exemple, l’utilisateur peut souscrire au service PER ASPERA en utilisant une interface dédiée. Le service PER ASPERA peut notamment être fourni à des terminaux directement connectés au réseau d’un fournisseur de service ou réservé à des offres qui reposent sur la fourniture d’un CPE. Comme déjà indiqué, on dénote par « équipement » un terminal ou un CPE utilisé par un utilisateur souhaitant profiter du service PER ASPERA. On note que le service PER ASPERA peut être proposé par un fournisseur de service de connectivité, un fournisseur de service DNS, etc. En particulier, un utilisateur peut solliciter un fournisseur de service DNS distinct du fournisseur qui lui fournit la connectivité. L’équipement de l’utilisateur peut se connecter à plusieurs réseaux en utilisant un même équipement d’accès ou des équipements différents. L’équipement de l’utilisateur peut utiliser un même service DNS pour l’ensemble des réseaux d’accès (fixes et mobiles) auxquels il peut se connecter. Le service PER ASPERA peut être proposé indépendamment de la nature du ou des réseau(x) d’accès utilisé(s) par l’équipement de l’utilisateur. De plus, le serveur PER ASPERA peut n’être utilisé que pour une partie des interfaces. De façon classique, l’équipement, ou au moins une interface réseau de l’équipement, est configurée avec au moins une liste d’au moins un serveur DNS de confiance. Afin d’améliorer la sécurité de la solution proposée, les connexions entre l’équipement et le ou les serveurs de confiance sont, dans le mode de réalisation décrit ici, sécurisées. Ainsi, le ou les serveurs de confiance peuvent supporter au moins un schéma de chiffrement reposant par exemple sur l’utilisation de l’un ou l’autre des protocoles suivants : DNS over TLS (DoT), DNS over DTLS (DoD), DNS over HTTPS (DoH), DNS over QUIC (DoQ), DNS over CoAP (DoC), etc. La configuration de la ou des listes d’au moins un serveur de confiance peut être réalisée en utilisant un mécanisme reposant sur une découverte des résolveurs désignés par leurs voisins (DNR, « Discovery of Neighbor-designated Resolvers », tel que décrit dans le document « DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) » d’août 2022, un mécanisme basé sur un échange de clés (IKE, « Internet Key Exchange », tel que décrit dans le document « Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS » de septembre 2022), etc. Si l’équipement dispose de plusieurs interfaces réseau, au moins une liste d’au moins un serveur de confiance peut être configurée par interface réseau (filaire, sans fil, 5G, etc.). Dans ce cas, une liste d’au moins un serveur de confiance peut être associée à un identifiant de l’interface réseau concernée. Selon un mode de réalisation particulier, l’équipement peut également être configuré avec au moins une action. Par exemple, l’équipement est configuré avec une liste indexée d’actions prédéfinies. Une telle liste peut contenir les actions suivantes (non-exhaustive) : index de politique / d’action « 0 » : remplacer la configuration de résolution de noms de domaine active par la configuration d’un des serveurs de confiance, index de politique / d’action « 1 » : désactiver les communications sortantes à l’exception des communications vers l’un des serveurs de confiance pour une interface donnée, index de politique / d’action « 2 » : générer une notification locale pour informer l’utilisateur d’une modification de la configuration de résolution de noms de domaine, index de politique / d’action « 3 » : demander l’envoi de la configuration de résolution de noms de domaine active, etc. Selon un mode de réalisation particulier, les informations descriptives du ou des serveurs de confiance (i.e. la configuration de la ou des listes d’au moins un serveur de confiance) sont stockées dans un registre maintenu par l’équipement et dont l’accès est protégé. L’accès à ce registre peut notamment mettre en œuvre des mécanismes d’authentification forte (par exemple, par l’utilisation d’un mot de passe dédié ou des clés de vérification à plusieurs niveaux). L’emplacement d’un tel registre peut notamment être décidé lors de l’activation du service PER ASPERA. Le registre peut correspondre à des entrées dédiées dans une base de registre Windows©, un fichier, une base de données, etc. En particulier, un tel registre est distinct de tout autre registre utilisé pour le stockage d’autres informations relatives à la résolution de noms de domaine. Le registre où sont stockées la ou les listes d’au moins un serveur de confiance est donc isolé des autres registres utilisés pour le stockage des informations exploitées pour la gestion DNS. Éventuellement, les informations descriptives du ou des serveurs de confiance peuvent être dupliquées pour être d’une part stockées dans le registre dont l’accès est protégé, d’autre part dans un registre classiquement utilisé pour le stockage d’informations relatives à la résolution de noms de domaine. Cette isolation a pour objectif d’éviter la modification de la liste des serveurs DNS de confiance par une application malveillante ou à la suite d’un accès frauduleux à l’équipement. Concrètement, une application qui accède à la configuration DNS locale sans consentement de l’utilisateur peut éventuellement modifier la configuration DNS active, mais ne peut pas modifier la configuration des serveurs de confiance stockée dans le registre dont l’accès est protégé. 5.2.2 Activation du service PER ASPERA Par la suite, on utilise le terme « client DNS » pour désigner l’équipement ou au moins une interface réseau de l’équipement mettant en œuvre la solution proposée. Comme décrit dans la , au cours d’une première étape 111, un client DNS transmet à au moins un de ses serveurs de confiance au moins une requête DNS d’activation du service PER ASPERA. Comme déjà indiqué, cette requête d’activation peut être dédiée à l’activation du service de vérification de résolution de noms de domaine. Dans ce cas, la requête d’activation est une requête DNS réservée au service PER ASPERA. En variante, la requête d’activation peut être non dédiée, notamment lorsque des requêtes conventionnelles sont utilisées pour les besoins des applications d’usage. Dans ce cas, le client DNS utilise une requête émise par exemple par une application embarquée dans l’équipement en insérant les informations requises pour l’activation du service PER ASPERA. On note que si un même serveur de confiance est associé à plusieurs interfaces de l’équipement, une requête d’activation par interface peut être envoyée ; chacune de ces requêtes est acheminée vers le serveur de confiance via l’interface concernée. En effet, l’envoi de ces différentes requêtes par interface permet de communiquer à un serveur de confiance l’adresse externe de l’équipement (client DNS) qui le rend joignable via cette interface. Si plusieurs listes de serveurs de confiance sont configurées, alors une requête d’activation est envoyée vers chacune de ces listes, i.e. vers au moins un serveur de confiance de chacune des listes. Ceci permet en particulier de contrôler l’activité DNS pour l’ensemble des interfaces d’un équipement lorsque celles-ci sont associées à des serveurs de confiance différents. Selon un mode de réalisation de l’invention, la ou les requêtes d’activation utilisent une nouvelle option selon le mécanisme EDNS . Une telle option est nommée ci-après WADE (« An EDNS Option for WAtching DNS associations to prevent swapping, interception, and theft »). L’identification d’une requête étendue selon le mécanisme EDNS est réalisée grâce à un pseudo « resource-record » (RR) OPT. Le format générique de l’option WADE est illustré dans la . Comme illustré par la , le champ de données « OPTION-DATA » du RR OPT prévoit six indicateurs de contrôle, par exemple sous la forme de 6 bits H, N, C, T, E, U : le bit H, aussi appelé « HB_ENABLE » (pour « Heartbeat Enable » en anglais), positionné à la valeur « 1 » indique une demande d’activation du service PER ASPERA, alors que la valeur « 0 » est utilisée pour désactiver le service PER ASPERA, le bit N positionné à la valeur « 1 » indique la présence du champ « NONCE », le bit C positionné à la valeur « 1 » indique la présence du champ « CHALLENGE », le bit T positionné à la valeur « 1 » indique la présence du champ « TARGET_HB_FQDN », le bit E positionné à la valeur « 1 » indique la présence du champ « EPOCH », le bit U positionné à la valeur « 1 » indique la présence du champ « CONTACT_URI ». Ces différents champs (« NONCE », « CHALLENGE », « TARGET_HB_FQDN », « EPOCH », « CONTACT_URI ») sont présentés par la suite. En particulier, les champs « CHALLENGE », « TARGET_HB_FQDN », et « EPOCH » sont renseignés par un serveur de confiance. Quand plusieurs de ces champs sont transportés dans une même option WADE, alors ces différents champs sont insérés selon l’ordre des bits de contrôle. Les paramètres variables sont précédés par un champ qui renseigne la taille du paramètre. Une requête d’activation incluant l’option WADE, telle qu’illustrée par la , utilise le bit H et éventuellement le bit U, positionnés à la valeur « 1 ». Les autres bits (N, C, T, et E) peuvent être positionnés à la valeur « 0 ». Ainsi, le bit H peut prendre une valeur « 1 » pour indiquer une demande d’activation du service PER ASPERA. Le bit « U » peut également prendre une valeur « 1 » pour indiquer la présence du champ « CONTACT_URI ». Un champ « URI_Length » peut notamment être prévu pour renseigner la taille du paramètre présent dans le champ « CONTACT_URI », comme illustré par la . Un tel champ « CONTACT_URI » peut être présent dans une requête d’activation du service PER ASPERA. Ce champ liste le ou les identifiants de contact que le serveur de confiance (qui reçoit la requête d’activation) peut utiliser pour rendre compte d’anomalies constatées dans les informations de configuration DNS (par exemple en transmettant au client DNS une notification l’invitant à engager une action). Si le bit U est positionné à la valeur « 1 », i.e. si le champ « CONTACT_URI » est présent, cela signifie que la ou les adresses de contact pour l’envoi des notifications sont celles renseignées dans le champ « CONTACT_URI ». Si le bit U est positionné à la valeur « 0 », i.e. si le champ « CONTACT_URI » n’est pas présent, cela signifie que l’adresse de contact pour l’envoi des notifications est l’adresse (ainsi que le numéro de port) utilisée par le client DNS pour envoyer cette requête d’activation. On note que le service PER ASPERA peut être désactivé à tout moment par un équipement. Pour ce faire, une requête qui contient l’option WADE peut être envoyée du client DNS vers un serveur de confiance, en utilisant le bit H positionné à la valeur « 0 ». Dans la suite, on suppose que le service est activé. On note qu’une telle option WADE n’est insérée que dans une requête DNS destinée à un serveur de confiance. Cette vérification repose par exemple sur l’adresse IP destination de la requête DNS ou l’ADN (« Authentication Domain Name ») du serveur DNS cible. 5.2.3 Réponse du serveur de confiance Comme indiqué en relation avec la , au moins un serveur de confiance reçoit au moins une requête d’activation du service PER ASPERA au cours d’une étape 121. Si un serveur de confiance ne supporte pas l’option WADE, alors il peut répondre avec un message d’erreur. Le client DNS peut éventuellement sélectionner un autre serveur de confiance configuré dans sa liste, envoyer une requête d’activation vers le même serveur mais sans l’option WADE, mettre fin à la communication et générer une notification locale (application, utilisateur, etc.), etc. Si un serveur de confiance supporte l’option WADE, alors il peut traiter la requête d’activation reçue. Notamment, le serveur de confiance peut extraire les informations communiquées dans l’option WADE, notamment dans le champ « CONTACT_URI » le cas échéant. Par exemple, le serveur de confiance peut extraire une adresse IP et un numéro de port source de la requête d’activation. Ces informations peuvent être stockées pour être ré-utilisées par la suite. Un serveur de confiance peut ainsi maintenir une ou plusieurs adresses sources par client DNS. Le serveur de confiance peut notamment préparer au moins une réponse et la transmettre au client DNS au cours de l’étape 122 de la . Une telle réponse peut notamment prendre la forme d’une requête DNS qui inclut l’option WADE telle qu’illustrée par la . En particulier, une telle réponse incluant l’option WADE utilise les bits H et T, et éventuellement les bits C et E, positionnés à la valeur « 1 ». Les autres bits (U, N) peuvent être positionnés à la valeur « 0 ». Ainsi, le bit H peut être valorisé à « 1 » pour indiquer l’acceptation d’une demande d’activation du service PER ASPERA. Le bit T peut également être valorisé à « 1 » pour indiquer la présence du champ « TARGET_HB_FQDN ». Un champ « TARGET_HB_FQDN_Length » peut notamment être prévu pour renseigner la taille du paramètre présent dans le champ « TARGET_HB_FQDN ». Un tel champ « TARGET_HB_FQDN » comporte un ou plusieurs noms de domaine spécifiques générés par le serveur de confiance pour le client DNS considéré. Le serveur de confiance fait autorité pour ces noms de domaine. Ils sont donc considérés comme uniques, et connus uniquement du client DNS et du serveur de confiance. Pour ce faire, ils sont générés de façon aléatoire par exemple. Éventuellement, le bit C peut prendre une valeur « 1 » pour indiquer la présence d’un champ « CHALLENGE ». Un champ « CHALLENGE_Length » peut notamment être prévu pour renseigner la taille du paramètre présent dans le champ « CHALLENGE ». Un tel champ « CHALLENGE » comporte des données de vérification qui peuvent être utilisées par le client DNS pour déterminer une preuve d’intégrité. Par exemple, de telles données de vérification peuvent être générées aléatoirement et utilisées par le client DNS pour calculer une preuve d’intégrité, telle qu’un condensé (« hash » en anglais). Une telle preuve intégrité peut ensuite être insérée par le client DNS dans les requêtes DNS ultérieures destinées au serveur de confiance. Éventuellement, le bit E peut prendre une valeur « 1 » pour indiquer la présence d’un champ « EPOCH ». Un champ « EPOCH_length » peut notamment être prévu pour renseigner la taille du paramètre présent dans le champ « EPOCH ». Un tel champ « EPOCH » comporte une information de récurrence, utilisée par le client DNS pour transmettre les requêtes de résolution de noms de domaine « HB ». Par exemple, un tel champ indique la périodicité des requêtes HB par le client DNS. Si les champs « EPOCH » et « CHALLENGE » sont activés, les bits C, T, E sont positionnés à la valeur « 1 » et les bits U et N sont positionnés à la valeur « 0 ». En particulier, le serveur de confiance peut stocker les informations communiquées à chaque client DNS. Dans un mode de réalisation particulier, le serveur de confiance peut contrôler le champ TTL (« Time To Live ») des réponses pour forcer le client DNS à renouveler l’activation du service PER ASPERA en renvoyant une requête d’activation. 5.2.4 Requête de résolution du nom de domaine du champ TARGET_HB_FQDN Comme indiqué en relation avec la , le client DNS reçoit une réponse du serveur de confiance au cours d’une étape 112. Le client DNS peut extraire les informations contenues dans l’option WADE, notamment dans le champ « TARGET_HB_FQDN ». Si des informations sont présentes dans les champs « EPOCH » et/ou « CHALLENGE », ces informations peuvent également être extraites. Le client DNS peut stocker ces informations, en association avec au moins un serveur de confiance et au moins une interface. Plusieurs réponses qui contiennent l’option WADE peuvent être envoyées au client DNS par un serveur de confiance. Toutes ces informations peuvent être stockées par le client DNS dans un registre approprié, dont l’accès peut être protégé. Comme illustré par la , le client DNS peut alors émettre une requête de résolution du nom de domaine présent dans le champ « TARGET_HB_FQDN » au cours d’une étape 113. Une telle requête peut notamment prendre la forme d’une requête DNS avec option WADE telle qu’illustrée par la . En particulier, une telle requête qui contient l’option WADE peut utiliser les bits H et N positionnés à la valeur « 1 ». Les autres bits (C, T, E et U) peuvent être positionnés à la valeur « 0 ». Le bit N peut être valorisé à « 1 » pour indiquer la présence du champ « NONCE ». Un champ « NONCE_Length » peut notamment être prévu pour renseigner la taille du paramètre présent dans le champ « NONCE ». Un tel champ « NONCE » comporte par exemple une preuve d’intégrité générée à partir des données de vérification transmises dans le champ « CHALLENGE ». La illustre un exemple de messages échangés entre un client DNS 41 et un serveur DNS de confiance 42. A titre d’exemple, on considère que le client DNS 41 émet une requête d’activation en utilisant son adresse @1 comme adresse source, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE ». A l’issue de ces étapes de réception d’au moins une requête d’activation et de construction d’au moins une réponse (notées Activ. PER APSERA 411), le serveur de confiance 42 dispose des informations contenues dans les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE », et de l’adresse source de la requête d’activation (@1). Selon l’exemple considéré, le client DNS 41 peut notamment émettre une ou plusieurs requêtes DNS pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », notées HB, en tenant compte de la valeur indiquée dans le champ « EPOCH » de la réponse reçue. Par exemple, le champ « EPOCH » comporte une information de récurrence indiquant une périodicité d’envoi T1 des requêtes HB. Ainsi, une première requête HB pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » peut être émise à l’instant T0+T1, une deuxième requête HB pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » peut être émise à l’instant T0+2*T1, une troisième requête HB pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » peut être émise à l’instant T0+3*T1, etc. De telles requêtes HB (« HeartBeat ») permettent de signaler au serveur de confiance 42 la présence d’une association active avec un client DNS 41. Selon l’exemple considéré, le client DNS 41 peut notamment calculer un condensé des données de vérification véhiculées dans le champ « CHALLENGE » de la réponse reçue lors de la phase d’activation PER ASPERA. Un tel condensé peut notamment être inséré dans le champ « NONCE » de la requête HB qui contient l’option WADE. Selon l’exemple illustré par la , le client DNS 41 émet une première requête HB (412) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d’intégrité dans le champ « NONCE », à l’instant T0+T1. A réception de la première requête HB (412), le serveur de confiance 42 peut notamment vérifier que l’adresse source de la requête d’activation (@1) et l’adresse source de la première requête HB (src@) sont cohérentes, i.e. permettent d’identifier le même équipement (src@=@1). Si ce n’est pas le cas, une anomalie est détectée. Le serveur de confiance 42 peut également vérifier que la preuve d’intégrité contenue dans le champ « NONCE » de la requête HB est cohérente avec une preuve d’intégrité déterminée localement à partir des données de vérification stockées par le serveur de confiance 42 (telles que consignées dans le champ « CHALLENGE » dans la réponse émise par le serveur de confiance). Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (par exemple procéder au calcul « Hash (CHALLENGE) » où Hash désigne une fonction de hachage correspondant à celle appliquée par le client DNS 41 pour générer le condensé des données de vérification (par exemple « Secure Hash Algorithms (SHAs) » décrits dans le document RFC 6234 « US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) » de mai 2011) et vérifier qu’il est égal au condensé transmis dans le champ « NONCE ». Si ce n’est pas le cas, une anomalie est détectée par le serveur de confiance 42. Le serveur de confiance 42 peut également vérifier si l’information de récurrence spécifiée dans le champ « EPOCH » est respectée. Si ce n'est pas le cas, une anomalie est détectée. En variante, l’indication de la fonction « hash » à utiliser par un client DNS peut être communiquée à l’aide de l’option WADE. Pour ce faire, un bit « I » est défini à cet effet parmi les bits « unassigned » décrits dans la . Quand le bit « I » est positionné à « 1 », l’identité de la fonction « hash » est renseignée dans le corps de l’option WADE (par exemple SHA2-256). Le client DNS 41 peut ensuite émettre une deuxième requête HB (413) pour la résolution du nom de domaine indiqué dans le champ TARGET_HB_FQDN, comportant une preuve d’intégrité dans le champ NONCE, à l’instant T0+2T1. Le serveur de confiance 42 peut notamment vérifier que l’adresse source de la requête d’activation (@1) et l’adresse source de la deuxième requête HB (src@) sont cohérentes (src@=@1), que le condensé des données de vérification (Hash (CHALLENGE)) est égal au condensé transmis dans le champ NONCE et que l’information de récurrence contenue dans le champ « EPOCH » est respectée. Le client DNS 41 peut émettre une troisième requête HB (414) et ainsi de suite. Dans l’exemple illustré par la , aucune anomalie n’est détectée. Dans un mode de réalisation particulier, les informations communiquées lors de l’activation du service PER ASPERA peuvent être modifiées à l’initiative du serveur de confiance 42 ou du client DNS 41. La illustre un exemple de messages échangés entre le client DNS 41 et le serveur de confiance 42, avec une demande de modification des données de vérification à l’initiative du client DNS 41. On considère par exemple que le client DNS 41 émet une requête d’activation en utilisant son adresse @1, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE1 » (Activ. PER APSERA 511). Selon l’exemple illustré par la , le client DNS 41 émet une première requête HB (512) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d’intégrité dans le champ « NONCE1 », à l’instant T0+T1. A réception de la première requête HB (512), le serveur de confiance 42 peut notamment vérifier que l’adresse source de la requête d’activation (@1) et l’adresse source de la première requête HB (src@) sont cohérentes. Le serveur de confiance 42 peut également vérifier que la preuve d’intégrité contenue dans le champ « NONCE1 » de la requête HB est cohérente avec une preuve d’intégrité déterminée localement à partir des données de vérification portées par le champ « CHALLENGE1 ». Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (Hash (CHALLENGE1)) et vérifier qu’il est égal au condensé transmis dans le champ « NONCE1 ». Le serveur de confiance 42 peut également vérifier si l’information de récurrence spécifiée dans le champ « EPOCH » est respectée. Le client DNS 41 peut demander à tout moment de modifier les données de vérification (« CHALLENGE1 »). Pour ce faire, le client DNS peut envoyer une deuxième requête HB (513) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » comportant une preuve d’intégrité dans le champ « NONCE1 », calculé sur la base des données de vérification du champ « CHALLENGE1 ». Pour informer le serveur de confiance 42 que le client DNS 41 demande de nouvelles données de vérification, les bits C et N sont positionnés à « 1 ». A réception de ce message, le serveur de confiance 42 peut accepter la demande et générer de nouvelles données de vérification, qui sont transmises au client DNS 41 dans une réponse qui contient l’option WADE, dans le champ « CHALLENGE2 » (514). Le client DNS 41 peut émettre une troisième requête HB (515) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d’intégrité dans le champ « NONCE2 », à l’instant T0+2T1. Une telle preuve d’intégrité est obtenue à partir des nouvelles données de vérification « CHALLENGE2 ». A réception de la troisième requête HB (515), le serveur de confiance 42 peut notamment vérifier que l’adresse source de la requête d’activation (@1) et l’adresse source de la troisième requête HB (src@) sont cohérentes, i.e. permettent d’identifier le même équipement (src@=@1). Le serveur de confiance 42 peut également vérifier que la preuve d’intégrité contenue dans le champ « NONCE2 » de la requête HB est cohérente avec une preuve d’intégrité déterminée localement à partir des nouvelles données de vérification stockées par le serveur de confiance 42 (telles que contenues dans le champ « CHALLENGE2 » de la réponse émise par le serveur de confiance). Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (Hash (CHALLENGE2)) et vérifier qu’il est égal au condensé contenu dans le champ « NONCE2 ». Le serveur de confiance 42 peut également vérifier si l’information de récurrence contenue dans le champ « EPOCH » est respectée. Le client DNS 41 peut émettre une quatrième requête HB (516) et ainsi de suite. La illustre un exemple de messages échangés entre le client DNS 41 et le serveur de confiance 42, avec une demande de modification des données de vérification à l’initiative du serveur de confiance 42. On considère par exemple que le client DNS 41 émet une requête d’activation en utilisant son adresse @1, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE1 » (Activ. PER APSERA 611). Selon l’exemple illustré par la , le client DNS 41 émet une première requête HB (612) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d’intégrité dans le champ « NONCE1 », à l’instant T0+T1. A réception de la première requête HB (612), le serveur de confiance 42 peut notamment vérifier que l’adresse source de la requête d’activation (@1) et l’adresse source de la première requête HB (src@) sont cohérentes. Le serveur de confiance 42 peut également vérifier que la preuve d’intégrité spécifiée dans le champ « NONCE1 » de la requête HB est cohérente avec une preuve d’intégrité déterminée à partir des données de vérification consignées dans le champ « CHALLENGE1 ». Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (Hash (CHALLENGE1)) et vérifier qu’il est égal au condensé consigné dans le champ « NONCE1 ». Le serveur de confiance 42 peut également vérifier si l’information de récurrence contenue dans le champ « EPOCH » est respectée. Le serveur de confiance 42 peut décider à tout moment de modifier les données de vérification (« CHALLENGE1 »). Par exemple, à réception d’une deuxième requête HB (613) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » comportant une preuve d’intégrité consignée dans le champ « NONCE1 », calculé sur la base des données de vérification du champ « CHALLENGE1 », le serveur de confiance 42 peut générer de nouvelles données de vérification. Le serveur de confiance 42 peut transmettre les nouvelles données de vérification au client DNS 41 dans une réponse qui contient l’option WADE, consignée dans le champ « CHALLENGE2 » (614). Pour informer le client DNS 41 que le serveur de confiance 42 a généré de nouvelles données de vérification qui sont transmises dans le champ « CHALLENGE2 », le bit C est positionné à « 1 ». Le client DNS 41 peut émettre une troisième requête HB (615) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d’intégrité contenue dans le champ « NONCE2 », à l’instant T0+2T1. Une telle preuve d’intégrité est obtenue à partir des nouvelles données de vérification « CHALLENGE2 ». A réception de la troisième requête HB (615), le serveur de confiance 42 peut notamment vérifier que l’adresse source de la requête d’activation (@1) et l’adresse source de la troisième requête HB (src@) sont cohérentes, i.e. permettent d’identifier le même équipement (src@=@1). Le serveur de confiance 42 peut également vérifier que la preuve d’intégrité consignée dans le champ « NONCE2 » de la requête HB est cohérente avec une preuve d’intégrité déterminée localement à partir des nouvelles données de vérification stockées par le serveur de confiance 42 (telles que contenues par le champ « CHALLENGE2 » dans la réponse émise par le serveur de confiance). Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (Hash (CHALLENGE2)) et vérifier qu’il est égal au condensé transmis dans le champ « NONCE2 ». Le serveur de confiance 42 peut également vérifier si l’information de récurrence contenue dans le champ « EPOCH » est respectée. Le client DNS 41 peut émettre une quatrième requête HB (616) et ainsi de suite. Par exemple, le serveur de confiance 42 peut modifier les données de vérification à fréquence régulière pour des besoins de sécurité. On présente désormais, en relation avec la , la détection d’une anomalie lorsque l’information de récurrence contenue dans le champ « EPOCH » n’est pas respectée. La illustre un exemple de messages échangés entre le client DNS 41 et le serveur de confiance 42. On considère par exemple que le client DNS 41 émet une requête d’activation en utilisant son adresse @1, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE » (Activ. PER APSERA 711). Selon l’exemple illustré par la , le client DNS 41 émet une première requête HB (712) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d’intégrité consignée dans le champ « NONCE ». A réception de la première requête HB (712), le serveur de confiance 42 peut notamment vérifier que l’adresse source de la requête d’activation (@1) et l’adresse source de la première requête HB (src@) sont cohérentes. Le serveur de confiance 42 peut également vérifier que la preuve d’intégrité contenue dans le champ « NONCE » de la requête HB est cohérente avec une preuve d’intégrité déterminée localement à partir des données de vérification contenues dans le champ « CHALLENGE ». Le serveur de confiance 42 peut également vérifier si l’information de récurrence consignée dans le champ « EPOCH » est respectée. Le serveur de confiance 42 constate qu’il ne reçoit pas de requête HB aux instants T0 + T1, T0 + 2T1 et T0 + 3T1 par exemple. Il détecte donc que l’information de récurrence contenue dans le champ « EPOCH » (récurrence des requêtes avec une périodicité T1) n’est pas respectée, et émet au moins une notification invitant le client DNS 41 à engager une action. Par exemple, un ou plusieurs messages de notification 713 sont envoyés vers l’adresse renseignée dans le champ « CONTACT_URI » pour le client DNS 41, ou vers l’adresse utilisée par le client DNS 41 pour envoyer la requête d’activation. Par exemple, un message de notification peut être de type Push HTTPS, Update DNS, etc. Un tel message peut notamment comporter un index correspondant à une action donnée, par exemple préconfigurée. Par exemple, si un message de notification comporte un index égal à 0 (Notif. (Action = 0)), le client DNS engage une action de type remplacement de la configuration de résolution de noms de domaine active par la configuration d’un des serveurs de confiance. Si un message de notification comporte un index égal à 1 (Notif. (Action = 1)), le client DNS engage une action de type « désactiver les communications sortantes à l’exception des communications vers l’un des serveurs de confiance pour l’interface considérée », etc. L’échange illustré par la peut notamment être observé quand un serveur DNS malveillant 73 a été configuré dans l’équipement embarquant le client DNS 41, et que ce serveur malveillant 73 bloque tout ou partie des requêtes DNS émises par le client DNS 41. Le client DNS 41 peut engager une ou plusieurs actions à réception du ou des messages de notification, comme réinstaller la configuration DNS de confiance, bloquer certaines communications, etc. Une fois la configuration DNS de confiance réinstallée par exemple (réinstallation des informations descriptives des serveurs DNS de confiance), le serveur de confiance 42 peut de nouveau recevoir une requête HB. On présente maintenant, en relation avec la , la détection d’une anomalie lorsque l’adresse source d’une requête HB n’est pas cohérente avec l’adresse source de la requête d’activation. Des étapes similaires peuvent être mises en œuvre lorsque la preuve d’intégrité véhiculée par une requête HB n’est pas cohérente avec la preuve d’intégrité déterminée localement par le serveur de confiance à partir des données de vérification connues du serveur de confiance. Selon l’un et/ou l’autre de ces cas, cela signifie typiquement que la requête HB a été relayée par un autre serveur DNS potentiellement malveillant. Le serveur de confiance peut ainsi détecter que les requêtes HB (ou toute autre requête DNS) émises par le client DNS sont interceptées par un autre serveur DNS avant leur acheminement vers le serveur de confiance. La illustre un exemple de messages échangés entre le client DNS 41 et le serveur de confiance 42. On considère par exemple que le client DNS 41 émet une requête d’activation en utilisant son adresse @1, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE » (Activ. PER APSERA 811). Selon l’exemple illustré par la , le client DNS 41 émet une première requête HB (812) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d’intégrité consignée dans le champ « NONCE ». A réception de la première requête HB (812), le serveur de confiance 42 peut notamment vérifier que l’adresse source de la requête d’activation (@1) et l’adresse source de la première requête HB (src@) sont cohérentes. Le serveur de confiance 42 peut également vérifier que la preuve d’intégrité contenue dans le champ « NONCE » de la requête HB est cohérente avec une preuve d’intégrité déterminée à partir des données de vérification consignées dans le champ « CHALLENGE ». Le serveur de confiance 42 peut également vérifier si l’information de récurrence spécifiée dans le champ « EPOCH » est respectée. Le client DNS 41 émet ensuite une deuxième requête HB (813) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d’intégrité dans le champ « NONCE ». Or comme illustré par la , cette deuxième requête HB (813) est interceptée par un serveur F 83 et relayée au serveur de confiance 42. A réception de la deuxième requête HB (813), le serveur de confiance 42 constate que l’adresse source de la requête d’activation (@1) et l’adresse source de la deuxième requête HB (src@) ne sont pas cohérentes (src@!=@1). Il détecte donc une anomalie et que la deuxième requête HB a probablement été relayée par un autre serveur DNS potentiellement malveillant (F 83). Le serveur de confiance 42 émet au moins une notification 814 invitant le client DNS 41 à engager une action. Par exemple, un ou plusieurs messages de notification 814 sont envoyés vers l’adresse renseignée dans le champ CONTACT_URI pour le client DNS 41, ou vers l’adresse utilisée par le client DNS 41 pour envoyer la requête d’activation. Par exemple, un tel message peut être de type réponse DNS, relayée par le serveur malveillant 83, comportant un index correspondant à une action donnée, par exemple préconfigurée, à exécuter par le client DNS. Par exemple, si une réponse DNS comporte un index égal à 3 (Rep. (Action = 3)), le client DNS engage une action de type « demander l’envoi de l’identité du serveur DNS actif ». Si une réponse DNS comporte un index égal à 0 (Rep. (Action = 0)), le client DNS engage une action de type remplacement de la configuration de résolution de noms de domaine active par la configuration d’un des serveurs de confiance, etc. On note que le serveur de confiance 42 peut déclencher l’exécution de plusieurs actions au titre des échanges HB utilisant une adresse IP distincte de celle utilisée lors de l’activation du service PER ASPERA. L’échange illustré par la peut notamment être observé quand un serveur DNS malveillant 83 a été configuré dans l’équipement embarquant le client DNS 41, et que ce serveur malveillant 83 se comporte comme un relais DNS intermédiaire (« proxy ») qui relaie les messages entre le client DNS 41 et le serveur de confiance 42. Une fois la configuration DNS de confiance réinstallée par exemple (réinstallation des informations descriptives des serveurs DNS de confiance), le serveur de confiance 42 peut de nouveau recevoir une requête HB. Dans un mode de réalisation particulier, le serveur de confiance 42 peut aussi inclure une option EDE, telle que décrite dans le document RFC 8914 « Extended DNS Errors » d’octobre 2020, pour informer le client DNS qu’une erreur DNS a été constatée par le serveur de confiance. A réception de cette réponse, le client DNS peut procéder à l’exécution de l’action indiquée dans cette réponse. En variante, l’indication de l’action à exécuter par un client DNS peut être renseignée à l’aide de l’option WADE. Pour ce faire, un bit « A » est défini à cet effet parmi les bits « unassigned » présentés dans la . Quand le bit « A » est positionné à « 1 », l’index de l’action est renseigné dans le corps de l’option WADE. On présente enfin, en relation avec la , un exemple de désactivation du service PER ASPERA, pour au moins une interface de l’équipement. On considère par exemple que le client DNS 41 émet une requête d’activation en utilisant son adresse @1, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE » (Activ. PER APSERA 911). Selon l’exemple illustré par la , lorsque le client DNS 41 souhaite désactiver le service PER ASPERA, il émet une requête HB (912) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » comportant une preuve d’intégrité dans le champ « NONCE », calculé sur la base des données de vérification consignées dans le champ « CHALLENGE ». Pour informer le serveur de confiance 42 que le client DNS 41 souhaite désactiver le service PER ASPERA, le bit H « HB_ENABLE » est positionné à « 0 ». A réception d’une telle requête, le serveur de confiance 42 vérifie qu’il n’y a pas d’anomalie. Par exemple, le serveur de confiance 42 peut rejeter la requête HB 912 et renvoyer un message d’erreur si la preuve d’intégrité contenue dans le champ NONCE de la requête HB 912 ne correspond pas à la preuve d’intégrité calculée localement par le serveur de confiance 42 pour les données de vérification consignées dans le champ CHALLENGE et stockées localement pour ce client DNS. S’il ne détecte pas d’anomalie, le serveur de confiance 42 valide la désactivation du service PER ASPERA. 5.3 Structure simplifiée d’un équipement et d’un serveur de confiance selon un mode de réalisation On présente finalement, en relation avec la , la structure simplifiée d’un équipement, respectivement d’un serveur de confiance, mettant en œuvre un procédé de détection d’un serveur malveillant selon un mode de réalisation décrit ci-dessus. Comme illustré par la , un tel équipement, respectivement serveur de confiance, comprend une mémoire 101E, respectivement 101S, comprenant par exemple une mémoire tampon, une unité de traitement 102E, respectivement 102S, équipée par exemple d’un processeur P, et pilotée par le programme d’ordinateur Pg 103E, respectivement 103S, mettant en œuvre le procédé de détection d’un serveur malveillant selon un mode de réalisation décrit ci-dessus. A l’initialisation, les instructions de code du programme d’ordinateur 103E sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 102E. Le processeur de l’unité de traitement 102E met en œuvre les étapes du procédé de détection d’un serveur malveillant selon un mode de réalisation décrit ci-dessus, selon les instructions du programme d’ordinateur 103E, pour : transmettre, à destination d’au moins un desdits serveurs de confiance, au moins une requête d’activation d’un service de vérification de résolution de noms de domaine, recevoir au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface, transmettre au moins une requête de résolution dudit au moins un nom de domaine, si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, recevoir au moins une notification invitant ledit équipement à engager une action. A l’initialisation, les instructions de code du programme d’ordinateur 103S sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 102S. Le processeur de l’unité de traitement 102S met en œuvre les étapes du procédé de détection d’un serveur malveillant selon un mode de réalisation décrit ci-dessus, selon les instructions du programme d’ordinateur 103S, pour : recevoir au moins une requête d’activation d’un service de vérification de résolution de noms de domaine, en provenance dudit équipement, transmettre au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface, si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, transmettre audit équipement au moins une notification l’invitant à exécuter une action. Procédé de détection d’un serveur de résolution de noms de domaine malveillant, mis en œuvre dans un équipement configuré avec au moins un serveur de résolution de noms de domaine de confiance associé à au moins une interface réseau via laquelle ledit équipement est apte à communiquer, mettant en œuvre : la transmission (111), à destination d’au moins un desdits serveurs de confiance, d’au moins une requête d’activation d’un service de vérification de résolution de noms de domaine, la réception (112) d’au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface, la transmission (113) d’au moins une requête de résolution dudit au moins un nom de domaine, si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, la réception (114) d’au moins une notification invitant ledit équipement à engager une action. Procédé selon la revendication 1, caractérisé en ce que ladite au moins une réponse comporte également des données de vérification générées par ledit serveur de confiance pour ladite au moins une requête d’activation, et en ce que ladite au moins une requête de résolution dudit au moins un nom de domaine comporte une preuve d’intégrité obtenue à partir desdites données de vérification. Procédé selon la revendication 2, caractérisé en ce que ladite au moins une requête de résolution dudit au moins un nom de domaine comporte un indicateur requérant la génération, par ledit serveur de confiance, de nouvelles données de vérification. Procédé selon l’une quelconque des revendications 1 à 3, caractérisé en ce que ladite au moins une réponse et/ou ladite requête de résolution dudit au moins un nom de domaine sont chiffrées. Procédé selon l’une quelconque des revendications précédentes, caractérisé en ce que ladite au moins une réponse comporte également une information de récurrence et en ce que ladite au moins une requête de résolution dudit au moins un nom de domaine est transmise en tenant compte de ladite information de récurrence. Procédé selon l’une quelconque des revendications précédentes, caractérisé en ce que ladite au moins une requête d’activation comporte au moins une adresse de contact dudit équipement. Procédé selon l’une quelconque des revendications précédentes, caractérisé en ce que les informations descriptives dudit au moins un serveur de confiance sont stockées dans un registre maintenu par ledit équipement et dont l’accès est protégé. Procédé selon l’une quelconque des revendications précédentes, caractérisé en ce que ledit équipement exécute au moins une action donnée à réception d’une notification l’invitant à exécuter ladite au moins action, ladite au moins une action appartenant au groupe comprenant : remplacer la configuration de résolution de noms de domaine active par la configuration d’un desdits serveurs de confiance, désactiver les communications sortantes à l’exception des communications vers l’un desdits serveurs de confiance, générer une notification locale pour informer un utilisateur d’une modification de la configuration de résolution de noms de domaine, demander l’envoi de la configuration de résolution de noms de domaine active. Procédé de détection d’un serveur de résolution de noms de domaine malveillant, mis en œuvre dans un serveur de résolution de noms de domaine de confiance configuré dans un équipement et associé à au moins une interface réseau via laquelle ledit équipement est apte à communiquer, mettant en œuvre : la réception (121) d’au moins une requête d’activation d’un service de vérification de résolution de noms de domaine, en provenance dudit équipement, la transmission (122) d’au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface, si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, la transmission (124) audit équipement d’au moins une notification l’invitant à exécuter une action. Procédé selon la revendication 9, caractérisé en ce qu’une anomalie est détectée si ladite au moins une requête de résolution dudit au moins un nom de domaine et si ladite au moins une requête d’activation ne proviennent pas du même équipement. Procédé selon l’une quelconque des revendications 9 et 10, caractérisé en ce que ladite au moins une réponse comporte également des données de vérification générées par ledit serveur de confiance pour ladite au moins une requête d’activation, en ce que ladite au moins une requête de résolution dudit au moins un nom de domaine comporte une preuve d’intégrité obtenue à partir desdites données de vérification, et en ce qu’une anomalie est détectée si ladite preuve d’intégrité portée par ladite au moins une requête de résolution dudit au moins un nom de domaine n’est pas cohérente avec une preuve d’intégrité obtenue localement à partir desdites données de vérification connues dudit serveur de confiance. Procédé selon l’une quelconque des revendications 9 à 11, caractérisé en ce que ladite au moins une réponse comporte également une information de récurrence de ladite au moins une requête de résolution dudit au moins un nom de domaine, et en ce qu’une anomalie est détectée si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance ou si ladite au moins une requête de résolution dudit au moins un nom de domaine n’est pas cohérente avec ladite information de récurrence. Procédé selon l’une quelconque des revendications 9 à 12, caractérisé en ce que ladite au moins une notification d’action est transmise à au moins une adresse de contact dudit équipement portée par ladite requête d’activation ou à l’adresse utilisée par ledit équipement pour transmettre ladite requête d’activation. Procédé selon l’une quelconque des revendications 1 à 13, caractérisé en ce que lesdites requêtes d’activation et/ou de résolution utilisent une option selon le mécanisme EDNS (« Extension Mechanisms for DNS ») pour échanger des informations entre ledit équipement et ledit serveur de confiance. Équipement configuré avec au moins un serveur de résolution de noms de domaine de confiance associé à au moins une interface réseau via laquelle ledit équipement est apte à communiquer, caractérisé en ce qu’il est configuré pour : transmettre, à destination d’au moins un desdits serveurs de confiance, au moins une requête d’activation d’un service de vérification de résolution de noms de domaine, recevoir au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface, transmettre au moins une requête de résolution dudit au moins un nom de domaine, si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, recevoir au moins une notification invitant ledit équipement à engager une action. Serveur de résolution de noms de domaine de confiance configuré dans un équipement et associé à au moins une interface réseau via laquelle ledit équipement est apte à communiquer, caractérisé en ce qu’il est configuré pour : recevoir au moins une requête d’activation d’un service de vérification de résolution de noms de domaine, en provenance dudit équipement, transmettre au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface, si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, transmettre audit équipement au moins une notification l’invitant à exécuter une action.