FR 3129051 A1 20230512 FR 2111975 A 20211110 Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés L’invention concerne un procédé de contrôle d’un équipement client (2) pour accéder à un service via au moins un réseau, ce procédé de contrôle étant destiné à être mis en œuvre par une entité (6,3) de confiance pour le service et/ou l’équipement client et comprenant une étape de contrôle d’une configuration de l’équipement client, lors d’un accès de celui-ci au service, pour qu’il transmette vers au moins un dispositif (8 ;8-1, …, 8-K) désigné pour le service et autorisé par l’entité de confiance, au moins une requête de résolution de noms de domaine émise par l’équipement client dans le cadre du service. Figure 1 Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés L’invention appartient au domaine général des télécommunications. Elle concerne plus particulièrement les systèmes de résolution de noms de domaine ou DNS (pour « Domain Name System » en anglais). De façon connue, un système DNS est une composante fondamentale dans les réseaux de communication IP (pour « Internet Protocol » en anglais). Il permet d’associer à une ressource telle qu’un nom de domaine, un identifiant de type URI (pour « Uniform Resource Identifier » en anglais) une ou plusieurs adresses IP permettant d’accéder à cette ressource. Ainsi, lorsqu’un équipement client, tel que par exemple un terminal ou une application, souhaite établir, pour accéder à un service quelconque, une communication avec un serveur identifié par un nom de domaine pleinement qualifié (ou FQDN pour « Fully Qualified Domain Name » en anglais), tel que « www.example.com », le client DNS embarqué dans l’équipement client en question envoie une demande de résolution DNS à un serveur DNS pour récupérer l’adresse ou les adresses IP associées à ce nom de domaine. Le serveur DNS peut alors répondre avec une liste d’adresses IP si une entrée qui correspond à ce nom de domaine est disponible localement, ou relayer la demande de l’entité communicante vers un autre serveur DNS (serveur DNS récursif) selon la hiérarchie DNS connue s’il ne dispose pas d’une telle entrée, etc. Dans l’état actuel de la technique, le service DNS, et plus particulièrement le serveur DNS à utiliser pour la résolution de noms de domaine, est généralement configuré au niveau de l’équipement client par l’opérateur qui lui fournit une connectivité IP (ex. opérateur de réseau d’accès ou de service IP). Cette configuration a lieu préalablement à toute communication de l’équipement client, typiquement lors de son raccordement ou de son attachement au réseau de l’opérateur en question ou via une configuration d’usine. Certains utilisateurs remplacent cette configuration DNS nominale fournie par leur opérateur par des serveurs DNS alternatifs. Ces serveurs (désignés par « serveurs alternatifs » dans la suite de la description) sont généralement des serveurs DNS publics, offerts par des opérateurs tiers, et affichant des temps de réponse plus rapides que certains serveurs DNS nominaux fournis par les opérateurs, et/ou offrant des fonctions de sécurité plus avancées. Quelle que soit la configuration DNS retenue (c’est-à-dire serveur nominal fourni par l’opérateur de connectivité IP, ou serveur alternatif public ou privé), elle s’applique indifféremment à tous les services auxquels accède l’équipement client. Les fournisseurs de services sont donc tributaires des performances de cette configuration DNS pour le rendu des services qu’ils proposent aux utilisateurs, et ne maîtrisent donc pas la qualité d’expérience globale perçue par ces derniers. En effet, si le service DNS sous-jacent offert par le serveur DNS nominal fourni par l’opérateur ou le serveur DNS alternatif sélectionné par l’utilisateur n’est pas optimal, il peut s’en suivre une dégradation du service. L’invention vient améliorer cette situation en proposant, selon un premier aspect, un procédé de contrôle d’un équipement client pour accéder à un service via un réseau, ce procédé de contrôle étant destiné à être mis en œuvre par une entité de confiance pour le service et/ou l’équipement client et comprenant une étape de contrôle d’une configuration dudit équipement client, lors d’un accès de celui-ci audit service, pour qu’il transmette vers au moins un dispositif désigné pour le service et autorisé par l’entité de confiance, au moins une requête de résolution de noms de domaine émise par l’équipement client dans le cadre du service. Corrélativement, l’invention vise aussi une entité de confiance pour un service et/ou un équipement client d’un réseau, cette entité de confiance comprenant un module de contrôle, configuré pour contrôler une configuration de l’équipement client lors d’un accès au service, pour qu’il transmette vers au moins un dispositif désigné pour le service et autorisé par l’entité de confiance, au moins une requête de résolution de noms de domaine émise par l’équipement client dans le cadre du service. Cette entité de confiance est par exemple un serveur impliqué directement ou indirectement dans la fourniture du service, tel que par exemple un serveur autoritaire (ou « authoritative server ») sollicité par l’équipement client pour la fourniture du service. Selon un autre exemple, il peut s’agir d’une entité intermédiaire placée sur un chemin de communication emprunté lors de l’accès au service par l’équipement client. Une telle entité intermédiaire peut être notamment un proxy (ou relais). Il importe qu’il s’agisse d’une entité de confiance pour l’équipement client et/ou pour le service (et donc incidemment pour le fournisseur du service en question) pour éviter que cette entité ne soit utilisée pour détourner les données émises par l’équipement client. L’invention propose donc de contrôler dynamiquement, par une entité de confiance pour le service et/ou pour l’équipement client, la configuration DNS de ce dernier afin de la corréler avec le service auquel il permet d’accéder. En d’autres termes, l’entité de confiance remplace le serveur DNS nominal ou le serveur DNS alternatif configuré par défaut dans l’équipement client par un dispositif qu’elle a désigné pour résoudre les requêtes DNS émises par l’équipement client dans le cadre d’un service. Ce contrôle permet de personnaliser le service DNS utilisé lors de l’accès au service (c’est-à-dire lorsque l’équipement client consomme le service en question), de l’optimiser pour ce service, et d’améliorer ainsi la qualité d’expérience perçue par l’utilisateur. Le service DNS ainsi contrôlé est avantageusement adapté au service : il peut notamment être adapté à des contraintes de service, offrir des fonctions avancées reposant sur le service DNS bénéficiant à l’utilisateur et au service, ou encore être configuré pour que tout ou partie des connexions (service) établies à partir de l’équipement client fassent l’objet de traitements particuliers. Il peut en outre être adapté à l’équipement client, et différer d’un équipement client à un autre. En contrôlant le dispositif (désigné ci-après par souci de simplification par « dispositif DNS ») chargé de résoudre les requêtes de résolution de noms de domaine émises par un équipement client dans le cadre de son accès à un service, il est possible de contrôler les équipements par lesquels transitent les connexions établies par l’équipement client dans le cadre du service, et donc incidemment les traitements appliqués à ces connexions. Par ailleurs, dans certaines situations, l’équipement client peut être configuré avec des politiques de préservation de l’identité du client (par exemple, réduction au minimum du volume des données d’identification partagées avec les services, émulation de localisation ou d’attachement réseau). Appliquée dans un tel contexte, l’invention permet de s’assurer que l’équipement client utilise des informations DNS remontées par une entité de confiance qui maintient une liste de serveurs DNS par service. Cette liste peut être enrichie avec des mesures de qualité de service et en fonction de la localisation de l’équipement client. L’entité de confiance sélectionne pour l’équipement client le(s) serveur(s) DNS lors d’un accès au service pour contrôler les informations d’identification et/ou améliorer la qualité de service. On note que par « lors d’un accès au service par l’équipement client », on entend de manière générale « à tout moment », dès lors que l’équipement client invoque/consomme le service en question. Ainsi, la modification de la configuration DNS de l’équipement client en une configuration DNS adaptée au service est mise en œuvre dès l’établissement de la connexion permettant d’accéder au service, aussi désignée ci-après par connexion sous-jacente au service (par exemple en réponse à une demande d’établissement d’une telle connexion sous-jacente au service envoyée par l’équipement client avant même que des données utiles soient échangées dans le cadre de ce service, tel que lors d’un échange 3WHS TCP (pour « 3-way handshake Transmission Control Protocol » en anglais). Toutefois, elle peut également avoir lieu ultérieurement, aussi longtemps que l’équipement client accède au service en question. L’invention permet notamment une meilleure distribution du trafic DNS émis par les équipements clients ; on évite ainsi une concentration des requêtes DNS vers un seul serveur DNS, ce qui permet de réduire la traçabilité des utilisateurs sur la base de leurs requêtes DNS (aussi connue sous le nom de « profilage DNS »). En outre, en disposant le cas échéant d’un contrôle sur la configuration DNS de l’équipement client, le fournisseur du service a une maîtrise globale sur la fourniture de son service et peut ainsi engager sa responsabilité en cas de dégradation de ce service (ex. temps d’accès dégradé au service). Comme mentionné ci-avant, le contrôle de la configuration DNS en fonction du service tel que proposé par l’invention peut être exploité pour mettre en œuvre de nouvelles fonctions dans le réseau en lien avec le service. En effet, le dispositif DNS peut adapter ses réponses aux requêtes DNS de l’équipement client de sorte à se trouver sur le chemin de toutes les connexions établies par l’équipement client lors de l’accès au service, à savoir non seulement la connexion principale établie par l’équipement utilisateur avec l’infrastructure offrant le service, mais également toutes les connexions secondaires établies en marge de cette connexion principale, comme par exemple avec des serveurs de traçage (ou « tracking servers », en anglais), etc. Grâce à cette position privilégiée, le dispositif DNS est en mesure d’analyser les paquets de données émis sur l’ensemble de ces connexions et de traquer ou détecter des événements déterminés susceptibles d’affecter le caractère privatif des données transmises dans ces paquets, comme par exemple le transport par ces paquets d’informations d’identification de l’utilisateur de l’équipement client. Il peut également désigner un autre équipement chargé de l’analyse des données transportées dans les paquets émis par l’équipement client de l’utilisateur. L’invention offre également la possibilité d’adjoindre plus aisément et de façon immédiate au dispositif DNS, de nouvelles fonctions avancées avantageuses pour la mise en œuvre du service. Généralement, le déploiement de telles fonctions requiert l’implication de plusieurs acteurs, ce qui rend ce déploiement complexe. Par exemple, la définition d’un nouveau type d’enregistrement ou RR (pour « Resource Record ») n’est généralement pas recommandée car cela suppose la mise à jour d’un écosystème géré par plusieurs entités distinctes incluant les clients DNS, les serveurs DNS et les relais DNS chargés de l’acheminement des requêtes DNS (ou « forwarders » en anglais) les caches, etc., ainsi que la coordination entre ces entités afin de fiabiliser les informations maintenues par chacune d’entre elles. L’invention permet à un fournisseur du service de déployer de nouvelles fonctions dans le cadre de ce service sans être tributaire de ces autres acteurs et à l’équipement client de bénéficier de telles fonctions. Le dispositif DNS désigné par l’entité de confiance peut également être avantageusement configuré avec des noms de domaine « privés », propres à la mise en œuvre du service et que le fournisseur du service ne souhaite pas communiquer à un serveur DNS public ou à un serveur DNS nominal fourni par l’opérateur du réseau (contexte d’un service reposant sur des objets connectés par exemple). Un tel serveur DNS public ou nominal renverra alors une réponse négative s’il est sollicité pour résoudre un tel nom de domaine privé. Le fait de ne pas communiquer ces noms de domaine privés constitue une mesure de sécurité permettant de minimiser le risque de potentielles attaques de déni de service visant ces noms de domaine. Cela permet également au fournisseur de service de générer dans le cadre de son service des noms de domaine éphémères et personnalisés, par exemple en fonction de l’identité de l’utilisateur de l’équipement client. L’invention offre une certaine flexibilité en matière d’introduction ou de retrait de noms de domaine au niveau de la chaîne DNS, ce qui n’est pas le cas d’un serveur DNS public ou nominal. Ainsi, au vu de ce qui précède, l’invention permet de gérer plusieurs types de requêtes de résolution de noms de domaine et notamment des requêtes concernant : un nom de domaine privé ; et/ou un nom de domaine généré dans le cadre du service pour l’équipement client ; et/ou un nom de domaine éphémère. Il est aussi possible de configurer le dispositif DNS désigné par l’entité de confiance pour qu’il retourne des réponses personnalisées à l’équipement client lorsqu’il est sollicité pour la résolution de noms de domaine, permettant par exemple de satisfaire des contraintes de service. Une telle réponse personnalisée peut consister notamment en l’envoi d’une ou plusieurs adresses IP situées à proximité de l’équipement client (encore appelées « Geoproximity IP »). Dans un mode particulier de réalisation, l’étape de configuration de l’équipement client comprend une transmission par l’entité de confiance à l’équipement client d’un message comprenant au moins une information de joignabilité d’au moins un dit dispositif désigné pour le service et autorisé par l’entité de confiance. Aucune limitation n’est attachée à la nature de l’information de joignabilité communiquée. Il peut s’agir notamment d’une adresse IP, d’un nom de domaine, un alias, un identifiant d’authentification, etc. Ceci facilite la mise en œuvre de l’invention et permet une exécution immédiate de la nouvelle configuration DNS, dès réception du message. En outre, la quantité d’information véhiculée dans le message pour configurer l’équipement client est avantageusement réduite. Il convient de noter que le message en question peut être chiffré ou non. Le chiffrement du message permet d’éviter le piratage des connexions par une entité tierce, et un tel chiffrement est préférable dans le cas d’une entité de confiance pour le service. Toutefois, la sécurisation des échanges entre l’entité de confiance et l’équipement client peut être assurée par d’autres mécanismes (par exemple pour une entité de confiance pour le client configurée à l’aide de règles ACL (pour « Access Control Lists » en anglais) adéquates). Ce mode de réalisation présente en outre l’avantage de séparer la logique service de la logique DNS, et permet une meilleure stabilité du service et du mécanisme DNS : la personnalisation du service DNS est effectuée par le dispositif désigné par l’entité de confiance et non par l’infrastructure (ex. serveur autoritaire) fournissant le service. Par exemple, le message en question peut être un message de réponse à un message d’invocation du service émis par l’équipement client. Un tel message d’invocation est par exemple un message TCP 3WHS tel qu’évoqué précédemment, ou un message ClientHello TLS (pour « Transport Layer Security » en anglais) ou encore un message Handshake QUIC, messages connus en soi. Ceci est transparent pour l’utilisateur et permet d’économiser la signalisation (et la bande passante) requise pour mettre en œuvre l’invention. En variante, le message en question peut être un message envoyé de façon asynchrone par l’entité de confiance. Dans un mode particulier de réalisation, ladite au moins une information de joignabilité est incluse dans un entête, une option, une trame (par exemple une trame QUIC), un attribut (par exemple un attribut SDP (Session Description Protocol)), une charge utile (ou « message body » en anglais avec une structure prédéfinie), etc. Par exemple, dans le contexte d’un message selon le protocole HTTP (HyperText Transfer Protocol), on peut envisager la présence d’un nouvel entête, appelé à titre illustratif DNS_RESOLVER, valorisé avec ladite au moins une information de joignabilité et indiquant à l’équipement client qu’il doit adresser ses futures requêtes DNS dans le cadre du service audit au moins un équipement associé à ladite au moins une information de joignabilité. Cette variante est relativement simple à mettre en œuvre et s’appuie sur des messages déjà existants. Seul un entête (ou le cas échéant une option, une trame, un attribut ou une charge utile ayant une structure prédéfinie selon la variante envisagée) doit être nouvellement introduit(e) pour les besoins de l’invention. Il convient de noter que si l’invention a une application privilégiée lorsqu’une version quelconque du protocole HTTP est utilisée, elle peut également être utilisée en association avec d’autres protocoles, comme par exemple avec le protocole CoAP (Constrained Application Protocol) moyennant la définition d’une nouvelle option dédiée à l’invention, ou avec le protocole QUIC, moyennant la définition d’une nouvelle trame dédiée à l’invention. Dans un autre mode de réalisation, l’information de joignabilité est envoyée dans un message de réponse dédié dont la structure est explicitement indiquée par un nouveau type de média (ou « media type » en anglais tel que par exemple « json+dns-resolver »). Ce type de média indique que le contenu d’un message est de type « JSON » et transporte un serveur DNS. Dans un autre mode de réalisation, la configuration de l’équipement client peut être mise en œuvre via l’envoi, par l’entité de confiance, d’une liste de noms de domaine potentiellement impliqués lors de l’accès au service par l’équipement client, et des adresses IP qui leur sont respectivement associées, par exemple dans une réponse à un message d’invocation du service ou à une requête DNS. Il convient toutefois de noter que ce mode de réalisation a une implication sur la taille des messages envoyés à l’équipement client, et peut induire, selon le protocole de transport impliqué, une fragmentation. L’invention offre par ailleurs la possibilité d’indiquer à l’équipement client une pluralité de dispositifs DNS (et notamment d’informations de joignabilité de ces dispositifs DNS), chaque dispositif DNS pouvant être associé à un contexte d’utilisation pour que l’équipement client soit en mesure d’orienter ses requêtes DNS vers le dispositif DNS le mieux adapté en fonction du contexte dans lequel il se trouve (ex. en fonction de sa localisation géographique). En variante, le message transmis par l’entité de confiance peut comprendre, pour au moins un dit dispositif désigné pour ledit service et autorisé par ladite entité de confiance, au moins une information caractérisant au moins une capacité fonctionnelle dudit dispositif. Une telle capacité fonctionnelle est par exemple une liste de méthodes, et/ou d’enregistrements (RR), et/ou de protocoles supportés par le dispositif en question. Cela permet une meilleure distribution des requêtes DNS émises par l’équipement client. Le dispositif DNS est adapté au contexte dans lequel l’équipement client sollicite une résolution de noms de domaine et peut apporter une réponse circonstanciée à l’équipement client. Selon un deuxième aspect, l’invention vise aussi un procédé de transmission d’au moins une requête de résolution de noms de domaine destiné à être mis en œuvre par un équipement client dans le cadre d’un service fourni via un réseau, ce procédé comprenant : une étape de modification, lors d’un accès au service et sous un contrôle d’une entité de confiance pour le service et/ou l’équipement client, d’une configuration de l’équipement client pour qu’il transmette vers au moins un dispositif désigné pour un traitement des requêtes de résolution de noms de domaine associées au service et autorisé par l’entité de confiance, au moins une requête de résolution de noms de domaine émise par l’équipement client dans le cadre de l’accès au service ; et une étape de transmission d’au moins une requête de résolution de noms de domaine dans le cadre de l’accès au service vers au moins un dit dispositif désigné. Corrélativement, l’invention concerne également un équipement client d’un réseau comprenant : un module de modification, configuré pour modifier, lors d’un accès à un service fourni via le réseau et sous un contrôle d’une entité de confiance pour le service et/ou l’équipement client, une configuration de l’équipement client pour qu’il transmette vers au moins un dispositif désigné pour un traitement des requêtes de résolution de noms de domaine associées au service et autorisé par l’entité de confiance, au moins une requête de résolution de noms de domaine émise par l’équipement client dans le cadre de l’accès au service ; et un module de transmission, configuré pour transmettre, au moins une requête de résolution de noms de domaine dans le cadre de l’accès au service vers au moins un dit dispositif désigné. Dans un mode particulier de réalisation, l’équipement client comprend en outre un module d’obtention, configuré pour obtenir pour au moins un dit dispositif désigné, une information caractérisant au moins une capacité fonctionnelle de ce dispositif, le module de transmission étant configuré pour transmettre ladite au moins une requête de résolution de noms de domaines vers un dit dispositif sélectionné en fonction de ladite au moins une capacité fonctionnelle de ce dispositif. Le procédé de transmission et l’équipement client bénéficient des mêmes avantages cités précédemment que le procédé de contrôle et l’entité de confiance. Dans un mode particulier de réalisation, les procédés de contrôle et de transmission sont mis en œuvre par un ordinateur. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une entité de confiance conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de contrôle tel que décrit ci-dessus. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans équipement client conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de transmission tel que décrit ci-dessus. Chacun de ces programmes peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus. Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash. D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'information ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de contrôle ou de transmission selon l’invention. Selon un autre aspect encore, l’invention vise un système d’accès à un service fourni via un réseau comprenant : une entité de confiance selon l’invention ; un équipement client selon l’invention ; et au moins un dispositif désigné pour un traitement des requêtes de résolution de noms de domaine associées au service et autorisé par l’entité de confiance avec lequel est configuré l’équipement client par l’entité de confiance pour transmettre au moins une requête de résolution de noms de domaine dans le cadre de l’accès au service. On peut également envisager, dans d'autres modes de réalisation, que les procédés de contrôle et de transmission, l’entité de confiance, l’équipement client et le système selon l’invention présentent en combinaison tout ou partie des caractéristiques précitées. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la représente, dans son environnement, un système d’accès à un service via un réseau conforme à l’invention, dans un mode particulier de réalisation ; la représente schématiquement l’architecture matérielle d’un ordinateur pouvant héberger l’une quelconque des entités selon l’invention appartenant au système de la ; et la représente les principales étapes d’un procédé de contrôle et d’un procédé de transmission selon l’invention dans un mode particulier de réalisation dans lequel ils sont mis en œuvre par les entités du système de la . Description de l’invention La représente, dans son environnement, un système d’accès 1 à un service S fourni via un réseau NW, conforme à l’invention, dans un mode particulier de réalisation. Il convient de noter que le réseau NW peut être composé d’un ou des plusieurs (sous-)réseaux connectés entre eux. Dans l’exemple envisagé à la , le service S est un service applicatif proposé via le réseau Internet par un fournisseur de service SP à un équipement client 2 d’un utilisateur U, conforme à l’invention. Aucune limitation n’est attachée à la nature du service S ainsi fourni (ex. service web, service de voix sur IP, service WebRTC, etc.), ni à la nature de l’équipement client 2 utilisé pour y accéder (ex. téléphone intelligent (ou « smartphone » en anglais), ordinateur fixe ou portable, tablette numérique, etc.). Pour fournir le service S, le fournisseur de service SP s’appuie sur une infrastructure de service hébergée dans un domaine de service SR (ou « Service Realm » en anglais). Par souci de simplification, on considère ici que le domaine SR de service comprend un serveur autoritaire 3 (ou « authoritative server » en anglais) avec lequel, pour accéder au service S, l’utilisateur U établit une connexion dite principale (C1) via son équipement client 2. Cette hypothèse n’est toutefois pas limitative en soi, l’invention s’applique également lorsque le domaine de service SR comprend une pluralité de serveurs (ex. serveur autoritaire, serveurs de cache, répartiteurs de charge (ou « load balancers » en anglais), etc.) hébergés dans une seule structure (par exemple une infrastructure d’informatique en nuage ou « cloud computing » en anglais) ou un seul équipement, ou dans plusieurs structures ou plusieurs équipements. Le service S peut également se trouver dans un autre réseau que le réseau Internet, par exemple dans un réseau d’un opérateur ou dans une infrastructure publique (ex. cloud public ou « public cloud » en anglais). Dans l’exemple envisagé ici, on suppose que pour accéder au réseau Internet et au service S, l’équipement utilisateur 2 est connecté directement à un réseau d’un opérateur, et plus particulièrement à un réseau AN d’accès cellulaire ou PLMN (pour « Public Land Mobile Network » en anglais) administré par un opérateur OP. Cette hypothèse n’est toutefois pas limitative en soi, et en variante, l’équipement utilisateur 3 peut être connecté au réseau Internet via un réseau local (ou LAN pour « Local Area Network » en anglais) tel qu’un réseau domestique, un réseau d’entreprise, etc., par l’intermédiaire d’un équipement dédié désigné par CPE (pour « Customer Premises Equipment » en anglais). On suppose ici que lorsque l’équipement utilisateur 2 se connecte au réseau AN de l’opérateur OP pour bénéficier d’une connectivité réseau, l’opérateur OP configure l’équipement utilisateur 2 avec une information de joignabilité (ex. adresse(s) IP, nom de domaine, alias, identifiant d’authentification, etc.) d’un serveur DNS 4 dit nominal à utiliser pour résoudre ses requêtes DNS, quel que soit le service auquel l’équipement client 2 souhaite accéder. Cette information de joignabilité peut éventuellement être modifiée par l’utilisateur U, via une interface utilisateur prévue à cet effet, pour remplacer le serveur DNS 4 nominal par un serveur DNS public 5, accessible via le réseau Internet. Cette configuration DNS de l’équipement client 2 (que ce soit avec le serveur DNS 4 nominal ou avec le serveur DNS public 5) est réalisée indépendamment de tout accès à un service par l’équipement client 2, par exemple préalablement à tout accès à un service (notamment pour la configuration avec le serveur DNS nominal 4), autrement dit avant toute invocation ou consommation du service par l’équipement client 2, et s’applique ici une fois réalisée, quel que soit le service auquel l’équipement client 2 accède. On la désigne ici par « configuration DNS nominale ». On note que par souci de simplification, on a considéré dans la configuration DNS nominale un seul serveur DNS nominal 4. Il est toutefois possible de définir dans cette configuration DNS nominale plusieurs serveurs DNS qui peuvent être sélectionnés en fonction de l’interface réseau utilisée par l’équipement client 2 pour accéder à un service. Comme évoqué précédemment, le système 1 d’accès au service S permet de contrôler la configuration DNS de l’équipement client 2 pour l’adapter au service S. Ce contrôle a lieu lors de l’invocation par l’équipement client 2 du service S, comme détaillé davantage ultérieurement. A cet effet, le système 1 comprend outre l’équipement client 2, une entité 6 de confiance, conforme à l’invention. Dans le mode de réalisation décrit ici, l’entité 6 de confiance est une entité avec laquelle le fournisseur SP du service S a une relation de confiance. Il peut s’agir par exemple d’une entité gérée par le fournisseur SP du service S ou d’une entité avec laquelle il dispose d’une relation de sécurité. Une telle entité est par exemple une entité 7 de coordination du service S se trouvant dans le domaine de service SR, ou encore le serveur autoritaire 3. C’est cette entité 6 de confiance qui, conformément à l’invention, est en mesure d’autoriser au moins un dispositif référencé de manière générale par 8 (aussi parfois désigné par « dispositif DNS 8 » dans la suite), désigné spécifiquement pour le service S, à résoudre les requêtes DNS de l’équipement client 2 et à contrôler la configuration DNS de l’équipement client 2 pour qu’il adresse les requêtes DNS qu’il a dans le cadre de l’accès au service S à ce ou ces dispositifs DNS 8 pour la résolution des noms de domaine visés par ces requêtes DNS. La façon dont le ou les dispositifs DNS 8 sont choisis est décrite plus en détail ultérieurement. Ils peuvent différer d’un équipement client à un autre. Les dispositifs DNS 8 appartiennent conformément à l’invention au système 1 d’accès au service S. Dans le mode de réalisation décrit ici, l’équipement client 2 et l’entité 6 de confiance pour le service S ont l’architecture matérielle d’un ordinateur 9 telle qu’illustrée à la . On note qu’en variante, l’équipement client 2 et/ou l’entité 6 de confiance peuvent être des instances logicielles hébergées par un équipement physique ayant l’architecture matérielle de l’ordinateur 9. L’ordinateur 9 comprend notamment un processeur 10, une mémoire vive 11, une mémoire morte 12, une mémoire non volatile 13, et des moyens de communication 14 permettant notamment aux entités du système 1 de communiquer entre elles. La mémoire morte 12 de l’ordinateur 9 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 10 et sur lequel est enregistré un programme d’ordinateur conforme à l’invention. Plus spécifiquement, la mémoire morte 12 de l’ordinateur 9 comprend, lorsque ce dernier est ou héberge une entité 6 de confiance conforme à l’invention, un enregistrement d’un programme d’ordinateur PROG6, comportant des instructions définissant les principales étapes d’un procédé de contrôle selon l’invention. Ce programme PROG6 définit des modules fonctionnels de l’entité 6 de confiance qui s’appuient sur ou commandent les éléments matériels 10 à 14 de l’ordinateur 9 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici : un module 6A d’autorisation, configuré pour autoriser au moins un dispositif DNS 8 désigné pour le service S à résoudre des noms de domaine qui lui sont adressés par l’équipement client 2 dans le cadre du service S. Selon le contexte d’application de l’invention, le ou les dispositifs DNS 8 en question peuvent avoir été choisis par l’entité 6 de confiance ou par une autre entité, puis validés et autorisés par l’entité 6 de confiance. Aucune limitation n’est attachée à la façon dont le module 6A d’autorisation autorise, ou de façon équivalente, valide l’intervention du ou des dispositifs DNS 8. Par exemple, si ceux-ci ont été sélectionnés par une autre entité, cette validation peut résulter de l’existence d’une relation de sécurité ou de confiance avec cette autre entité, ou de la présence de cette autre entité dans une liste d’entités autorisées par le fournisseur du service S. On peut également envisager un échange sécurisé entre l’entité 6 de confiance et les dispositifs DNS 8 pour vérifier qu’ils sont bien autorisés à agir pour la résolution de noms de domaine dans le cadre du service S, ou la présence de ces dispositifs DNS 8 dans une liste fournie par le fournisseur de service S, etc. ; et un module 6B de contrôle, configuré pour contrôler une configuration DNS de l’équipement client 2 appliquée lors d’un accès par l’équipement client 2 au service S, pour qu’il transmette vers au moins un dit dispositif DNS 8 désigné pour le service S et autorisé par le module 6A d’autorisation de l’entité 6 de confiance, au moins une requête de résolution de noms de domaine émise par l’équipement client 2 dans le cadre de son accès au service S. Les requêtes de résolution de noms de domaine concernées sont définies par des règles de sélection fournies par le module 6B de contrôle à l’équipement client 2. De telles règles de sélection définissent les noms de domaines associés au service S concernés par la configuration, tels que par exemple tous les sous-domaines « *.example.com » ou seulement une partie d’entre eux (ex. « *.piv.example.com). On peut envisager différentes façons pour le module 6B de contrôle de contrôler la configuration DNS de l’équipement client 2. Par exemple, le module 6B de contrôle peut contrôler la configuration DNS de l’équipement client 2 en lui envoyant un message contenant un entête spécifique, par exemple un entête nommé DNS_RESOLVER, cet entête contenant une information de joignabilité (ex. adresse IP, nom de domaine, alias, identifiant d’authentification, etc.) dudit au moins un dispositif DNS 8 désigné pour le service S et indiquant à l’équipement client 2 qu’il doit adresser ses requêtes DNS à ce ou ces dispositifs DNS 8. Ce message peut être envoyé de façon asynchrone (spontanée) par le module 6B de contrôle à l’équipement client 2 ou en réponse à un message d’invocation du service S. Il peut en outre comprendre au moins une information caractérisant une capacité fonctionnelle de chacun des dispositifs DNS 8, comme par exemple une liste des méthodes, ou des enregistrements (RR) ou encore des protocoles supportés par chacun des dispositifs DNS 8. En variante, le module 6B de contrôle peut agir par l’intermédiaire d’une autre entité du réseau pour qu’elle transmette un tel entête DNS_RESOLVER à l’équipement client 2. Dans une autre variante encore, le contrôle peut s’effectuer via la transmission d’une option dédiée ou d’une trame dédiée plutôt qu’un entête DNS_RESOLVER. D’autres variantes encore peuvent être envisagées de façon alternative ou complémentaire. Les fonctions des modules 6A et 6B sont décrites plus en détail ultérieurement en référence aux étapes du procédé de contrôle selon l’invention. Lorsque l’ordinateur 9 est ou héberge une équipement client 2 conforme à l’invention, la mémoire morte 12 de l’ordinateur 9 comprend alors un enregistrement d’un programme d’ordinateur PROG2, comportant des instructions définissant les principales étapes d’un procédé de transmission selon l’invention. Ce programme PROG2 définit des modules fonctionnels de l’équipement client 2 qui s’appuient sur ou commandent les éléments matériels 10 à 14 de l’ordinateur 9 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici : un module 2A de stockage d’une configuration DNS, comprenant l’information de joignabilité (ex. adresse IP, nom de domaine, alias, identifiant d’authentification, etc.) d’un ou de plusieurs serveurs DNS à utiliser pour la résolution de noms de domaine. Le module 2A de stockage comprend ici, suite à la connexion de l’équipement client 2 au réseau AN, l’information de joignabilité, et plus particulièrement l’adresse IP, du serveur DNS nominal 4 (ou d’un serveur DNS nominal en cas de pluralité de serveurs DNS nominaux). En variante, si l’utilisateur U de l’équipement client 2 a modifié cette configuration, le module 2A de stockage peut comprendre l’information de joignabilité du serveur DNS public 5. En tout état de cause, le module 2A de stockage comprend l’information de joignabilité du serveur DNS de la configuration DNS nominale, introduite précédemment ; un module 2B de modification, configuré pour modifier, en cours d’accès au service S et sous le contrôle de l’entité 6 de confiance, la configuration DNS de l’équipement client 2 applique pour résoudre ses requêtes DNS pour que l’équipement client 2 transmette vers au moins un dispositif DNS 8, désigné pour le service S et autorisé par l’entité 6 de confiance, au moins une requête de résolution de noms de domaine dans le cadre du service S. Dans le mode de réalisation décrit ici, la configuration DNS, incluant les règles de sélection des requêtes DNS concernées et définies par le module 6B de l’entité 6 de confiance (autrement dit celles associées au service S) et la ou les informations de joignabilité du ou des dispositifs DNS 8, est enregistrée dans un cache 2D local de l’équipement client 2. Chaque entrée du cache 2D fait correspondre une configuration DNS à un service donné et est associée ici à une durée de validité : tant que la durée de validité d’une entrée n’est pas expirée, elle est appliquée par l’équipement client 2 pour le service concerné, ce qui est avantageux en cas d’invocation récurrente dudit service comme illustré ultérieurement. On note que les règles de sélection associées à chaque configuration DNS permettent avantageusement de distinguer les configurations DNS stockées dans le cache 2D local et qui peuvent concerner plusieurs services distincts, et d’ainsi permettre à l’équipement client 2 d’appliquer, en fonction du service concerné, la bonne configuration DNS. En variante, on peut envisager un cache local par service ; et un module 2C de transmission, configuré pour transmettre au moins une requête de résolution de noms de domaine dans le cadre de l’accès au service S (c’est-à-dire correspondant aux règles de sélection précitées) vers l’un des serveurs DNS identifié dans la configuration DNS stockée dans le cache local 2D. Ainsi, avant exécution de l’invention, le module 2C de transmission est configuré pour transmettre ses requêtes DNS vers le serveur DNS nominal 4 ou vers le serveur DNS public 5 selon la configuration DNS nominale adoptée et mémorisée dans le module de stockage 2A ; après exécution du procédé de contrôle selon l’invention, le module 2C de transmission est configuré pour transmettre ses requêtes DNS émises dans le cadre de l’accès au service S vers l’un des dispositifs DNS 8 autorisés par l’entité 6 de confiance identifiés dans le cache local 2D. Dans le mode de réalisation décrit ici, si plusieurs dispositifs DNS 8 sont autorisés par l’entité 6 de confiance dans le cadre de l’accès au service S, le module 2C de transmission est configuré pour obtenir au moins une information caractérisant une capacité fonctionnelle de chacun des dispositifs DNS 8 autorisés (ex. liste de méthodes, d’enregistrements RR ou de protocoles supportés par chacun des dispositifs DNS 8) et pour sélectionner l’un d’entre eux en fonction de ses capacités fonctionnelles. Ces informations sur les capacités fonctionnelles des dispositifs DNS 8 peuvent être stockées dans la configuration DNS mémorisée dans le cache local 2D. En variante, d’autres critères de sélection peuvent être envisagés, tel que par exemple, la localisation du serveur DNS par rapport à celle de l’équipement client 2, etc. Les fonctions des modules 2A à 2C sont décrites plus en détail ultérieurement en référence aux étapes du procédé de transmission selon l’invention. Nous allons maintenant décrire, en référence à la , les principales étapes d’un procédé de contrôle et d’un procédé de transmission selon l’invention telles qu’elles sont mises en œuvre respectivement par l’entité 6 de confiance et par l’équipement client 2 du système 1 dans un mode particulier de réalisation. Dans l’exemple illustré à la , on suppose que les entités du système 1 et du réseau utilisent pour communiquer entre elles une version du protocole HTTP. Toutefois, cette hypothèse n’est pas limitative en soi, l’invention s’applique en combinaison avec d’autres protocoles, comme par exemple le protocole CoAP, le protocole QUIC, etc. Par ailleurs, dans l’exemple envisagé à la , l’entité 6 de confiance est le serveur autoritaire 3. Comme mentionné précédemment, on suppose en préliminaire que l’équipement client 2 est configuré pour utiliser la configuration DNS nominale introduite précédemment, autrement dit pour transmettre ses requêtes de résolution de noms de domaine ou requêtes DNS vers le serveur DNS nominal 4. En d’autres termes, le cache local 2D ne contient aucune configuration DNS alternative à la configuration DNS nominale à appliquer dans le cadre de l’accès au service S. Ainsi, lorsque l’équipement client 2 souhaite accéder au service S, et établir notamment une connexion avec le serveur autoritaire 3, il adresse, par l’intermédiaire de son module de transmission 2C, une requête DNS désignée par QUERY(3), à son serveur DNS nominal 4 (étape H10). Le serveur DNS nominal 4 lui répond, de façon connue en soi, en fournissant une adresse IP, notée @IP3, du serveur autoritaire 3 (étape H20). Il peut notamment pour lui fournir cette réponse contacter des serveurs DNS récursifs si besoin. Après avoir établi une connexion avec le serveur autoritaire 3 de façon connue en soi (connexion sous-jacente au service), par exemple via un échange reposant sur les protocoles TCP et TLS, l’équipement client 2 envoie alors une requête HTTP POST d’accès au service S au serveur autoritaire 3 en utilisant comme adresse de destination l’adresse IP @IP3 qui lui a été transmise (étape H30). Comme mentionné précédemment, dans l’exemple envisagé ici, le serveur autoritaire 3 agit en tant qu’entité 6 de confiance selon l’invention. Il comprend par conséquent les modules 6A et 6B de l’entité 6 de confiance décrits précédemment. Ainsi, sur réception de la requête d’accès HTTP POST de l’équipement client 2, le serveur autoritaire 3 (agissant en tant qu’entité 6 de confiance) traite cette requête. Il consulte par ailleurs son module 6A d’autorisation pour obtenir la ou les informations de joignabilité (ex. adresses IP ici) du ou des dispositifs DNS 8 autorisés pour le service S à résoudre les requêtes DNS émises dans le cadre de l’accès au service S. On suppose ici qu’un nombre K supérieur ou égal à 1 de dispositifs DNS 8 sont concernés. Ces K dispositifs DNS sont référencés respectivement par dispositifs DNS 8-1, 8-2, …, 8-K dans la suite. Le serveur autoritaire 3 insère alors, via son module 6B de contrôle, dans sa réponse HTTP 200 OK à la requête d’accès HTTP POST reçue de l’équipement client 2, les K adresses IP, @IP8-1, …, @IP8-K des K dispositifs DNS 8 fournis par son module 6A d’autorisation, une indication (explicite ou implicite) que l’équipement client 2 doit envoyer ses futures requêtes DNS émises dans le cadre du service S vers l’un au moins desdits K dispositifs DNS 8, ainsi qu’ici, les règles de sélection des requêtes DNS s’appliquant à ces K dispositifs DNS 8 (autrement dit, les règles qui permettent à l’équipement client 2 de reconnaître les requêtes DNS associées au service S qui doivent être adressées à ces dispositifs DNS 8). Puis il transmet la réponse HTTP 200 OK à l’équipement client 2 (étape H40). Dans le mode de réalisation décrit ici, les adresses @IP8-1, …, @IP8-K sont insérées par le module 6B de contrôle dans l’entête DNS_RESOLVER qui indique en soi à l’équipement client 2 qu’il doit envoyer ses futures requêtes DNS émises dans le cadre du service S vers l’un au moins des dispositifs DNS 8 associés à l’une des adresses @IP8-1, …, @IP8-K. Le module 6B de contrôle insère par ailleurs dans l’entête DNS_RESOLVER en association avec chaque adresse IP, au moins une information caractérisant au moins une capacité fonctionnelle telle que décrite ci-avant du dispositif DNS 8 correspondant à cette adresse IP (ex. une liste de protocoles ou d’enregistrements RR ou encore de méthodes supportées par chaque dispositif DNS 8, ou une combinaison de telles listes). Il peut en outre insérer dans l’entête DNS_RESOLVER une durée de validité associée à la configuration DNS ainsi transmise pour le service S. Il convient toutefois de noter que cette durée de validité est optionnelle et qu’en variante on peut envisager que la configuration DNS s’applique au niveau de l’équipement client 2 tant qu’elle n’est pas modifiée par l’entité 6 de confiance. Les capacités fonctionnelles peuvent en fonction de leur nature être insérées dans des champs différents de l’entête DNS_RESOLVER. Par exemple, les protocoles de transport supportés par le dispositif DNS 8 considéré dans un champ TRANSPORT_SET, les enregistrements RR dans un champ RR_SET et les méthodes dans un champ QUERY_SET. Bien entendu ces noms ne sont donnés qu’à titre illustratif. L’insertion de l’entête DNS_RESOLVER dans la réponse HTTP 200 OK à la requête HTTP POST est une étape de contrôle au sens de l’invention par le serveur autoritaire 3 agissant en tant qu’entité 6 de confiance. On note que l’exemple envisagé ici, l’entête DNS_RESOLVER est inséré dans une réponse à une requête d’accès HTTP POST au service envoyée après l’établissement de la connexion sous-jacente au service S entre l’équipement client 2 et le serveur autoritaire 3. On peut toutefois envisager en variante qu’un tel entête soit inséré dans une réponse à une requête HTTP POST envoyée durant la procédure d’établissement de la connexion sous-jacente au service S. Une telle requête HTTP POST peut par exemple être envoyée dans un message SYN et ClientHello TLS si les mécanismes TCP Fast Open et 0-RTT TLS décrits respectivement dans les documents IETF RFC 7413 et RFC 8446 sont activés. Dans une autre variante, les indications précédemment citées, portées par l’entête DNS_RESOLVER, sont insérées dans une option TCP et/ou TLS en réponse à une requête d’accès au service ou à une demande d’établissement de la connexion sous-jacente au service S. Sur réception de la réponse HTTP 200 OK du serveur autoritaire 3 et détection de l’entête DNS_RESOLVER inclus dans la réponse, le module 2B de modification de l’équipement client 2 modifie la configuration DNS appliquée par l’équipement client 2 (qui correspond ici à celle qui est mémorisée dans le module 2A de stockage en l’absence de configuration DNS associée au service S mémorisée dans le cache local 2D). Plus spécifiquement, il mémorise dans le cache local 2D les adresses @IP8-1, …, @IP8-K des dispositifs DNS 8 compris dans l’entête DNS_RESOLVER à utiliser lors de l’accès au service S ainsi que les règles de sélection permettant à l’équipement client 2 d’identifier les requêtes DNS concernées par ces dispositifs DNS (étape H50). De la sorte, le module 2C de transmission de l’équipement client 2 adresse les futures requêtes DNS (QUERY(X)) envoyées dans le cadre du service S (par exemple, toutes les requêtes portant sur les sous-domaines « *.example.com » en fonction des règles de sélection définies par l’entité 6 de confiance) à l’un des dispositifs DNS 8 identifiés dans la nouvelle configuration DNS mémorisée dans le cache local 2D (et non plus à son serveur DNS nominal 4 comme lors de l’étape H10, qui peut toutefois continuer d’être sollicité pour des requêtes DNS envoyées dans le cadre d’autres services que le service S et non concernées par la configuration DNS mémorisée dans le cache local 2D) (ex. étapes 60, H70). On note que ces requêtes DNS peuvent viser un nom de domaine public, mais également un nom de domaine privé que les dispositifs DNS 8 sont adaptés à résoudre, ou un nom de domaine généré dans le cadre du service S pour l’équipement client 2, ou un nom de domaine éphémère généré dans le cadre du service S, etc., ou encore un nom de domaine vérifiant plusieurs de ces caractéristiques. En adaptant la configuration DNS de l’équipement client 2 en fonction du service S, une grande flexibilité est offerte au fournisseur du service S en matière de résolution DNS. En outre, il convient également de noter que si, avant l’étape H10, le cache local 2D comprend déjà une configuration DNS à appliquer pour le service S différente de la configuration DNS nominale, et que cette configuration DNS est associée dans le cache local 2D à une durée de validité non expirée, alors lors de l’étape H10, l’équipement client 2 applique cette configuration DNS enregistrée dans le cache local 2D et s’adresse directement à l’un des dispositifs DNS 8 pour résoudre sa requête DNS. Ledit dispositif fournit l’adresse @IP3 du serveur autoritaire 3 en réponse à la requête DNS envoyée par l’équipement client 2 lors de l’étape H20. Les étapes H30 et H40 sont maintenues et permettent le cas échéant de prolonger la durée de validité de la configuration DNS déjà mémorisée dans le cache local 2D pour le service S, ou si la configuration DNS s’appliquant au service S a été modifiée par l’entité 6 de confiance, de modifier cette configuration DNS. Comme évoqué précédemment, si plusieurs dispositifs DNS 8 sont identifiés dans la nouvelle configuration DNS mémorisée par le cache local 2D, pour chaque requête DNS QUERY(X) devant être émise par l’équipement client 2, le module 2C de transmission sélectionne l’un des dispositifs DNS 8 en fonction d’un critère donné. Un tel critère est par exemple ici les capacités fonctionnelles des dispositifs DNS 8. Ainsi, à titre illustratif, pour K=2, supposons que l’entête DNS_RESOLVER reçu par l’équipement client 2 indique une liste de méthodes supportées par chacun des dispositifs DNS 8-1, 8-2, et plus particulièrement pour le dispositif DNS 8-1 les méthodes HTTP {GET, POST, FETCH}, et pour le dispositif DNS 8-2 les méthodes HTTP {GET, POST}. Alors le module 2C de transmission peut sélectionner indifféremment le dispositif DNS 8-1 ou le dispositif 8-2 pour l’envoi de requêtes DNS GET et POST, et sélectionner le dispositif 8-1 uniquement pour l’envoi de requêtes DNS FETCH. Selon un autre exemple illustratif pour K=2 toujours, supposons que l’entête DNS_RESOLVER reçu par l’équipement client 2 indique une liste d’enregistrements RR supportés par chacun des dispositifs DNS 8-1, 8-2, et plus particulièrement pour le dispositif DNS 8-1 un enregistrement de type SVCB (« SerViCe Binding », en anglais) tandis que pour le dispositif DNS 8-2 un enregistrement de type MX (« Mail eXchange », en anglais). Alors le module 2C de transmission sélectionne le dispositif DNS 8-1 pour résoudre les requêtes DNS portant sur un enregistrement SVCB. Selon un autre exemple illustratif encore pour K=2, supposons que l’entête DNS_RESOLVER reçu par l’équipement client 2 indique une liste de protocoles supportés par chacun des dispositifs DNS 8-1, 8-2, et plus particulièrement pour le dispositif DNS 8-1 les protocoles Do53 et DoQ, tandis que pour le dispositif DNS 8-2 les protocoles DoH (DNS over HTTPS) et DoC (DNS over CoAP), le protocole DoT (DNS over TLS), les protocoles Do53, DoQ (DNS over QUIC), DoH et DoC étant connus de l’homme du métier et non détaillés ici. Alors le module 2C de transmission supportant le protocole DoH peut décider de ne sélectionner que le dispositif DNS 8-1 pour résoudre ses requêtes DNS. En variante, on peut envisager d’autres critères, comme par exemple une sélection aléatoire, ou une sélection d’un dispositif DNS 8 en fonction de sa proximité géographique par rapport à l’équipement client 2, ou encore une combinaison de plusieurs critères, etc. Dans l’exemple qui vient d’être envisagé, la nouvelle configuration DNS à appliquer est communiquée par le serveur autoritaire 3 / l’entité 6 de confiance à l’équipement client 2 en réponse à sa requête d’accès au service S. Il convient toutefois de noter que cette hypothèse n’est pas limitative en soi et que la nouvelle configuration peut être communiquée à l’équipement client 2 en réponse à tout autre message d’invocation du service S, dès lors qu’il est envoyé pendant que l’équipement client 2 accède au service S. En variante, l’indication d’appliquer la nouvelle configuration DNS peut être transmise par le serveur autoritaire 3 / l’entité 6 de confiance à l’équipement client 2 de façon asynchrone ou spontanée, c’est-à-dire sans être en lien avec un message d’invocation du service S particulier émis par l’équipement client 2. Par ailleurs, dans l’exemple qui vient d’être décrit, le serveur autoritaire 3 / l’entité de confiance 6 indique lui/elle-même à l’équipement client 2 la nouvelle configuration DNS à appliquer pour le service S, autrement dit le serveur autoritaire 3 / l’entité de confiance 6 modifie directement la configuration DNS appliquée par l’équipement client 2 pour le service S. En variante, la modification au niveau de l’équipement client 2 peut être contrôlée (i.e. décidée) par l’entité 6 de confiance mais être mise en place dans l’équipement client 2 par une entité intermédiaire. Cette entité intermédiaire peut être n’importe quelle entité avec laquelle l’entité 6 de confiance entretient une relation de confiance et/ou sécurisée, telle que par exemple une entité de l’infrastructure de service ou une entité tierce placée notamment sur le chemin des communications emprunté lors de l’accès au service par l’équipement client. Il peut même s’agir de l’un des dispositifs DNS qu’elle a autorisé pour le service. Il convient également de noter que dans le mode de réalisation qui vient d’être décrit, le service autoritaire 3 / l’entité de confiance 6 est une entité de confiance 6 pour le service, dès lors qu’il s’agit d’une entité de l’infrastructure sur laquelle s’appuie le service. On peut toutefois envisager d’autres entités de confiance que des entités de l’infrastructure de service, comme par exemple une entité désignée par le fournisseur du service ou d’une autre infrastructure avec laquelle le fournisseur du service a établi un accord reposant sur une relation de confiance. On peut également envisager d’appliquer l’invention dans un contexte où l’entité de confiance qui contrôle la configuration DNS utilisée par l’équipement client 2 lors de son accès au service S est une entité de confiance pour l’équipement client 2. Par exemple, il peut s’agir d’un équipement intermédiaire via lequel l’équipement client 2 établit une connexion avec le réseau Internet pour accéder au service S et avec lequel il a lui-même établi une connexion sécurisée (par exemple chiffrée, ou un tunnel de communication sécurisé) de sorte que tous les messages émis et reçus par l’équipement client 2 lors de l’accès au service S transitent par cet équipement intermédiaire. Un tel équipement intermédiaire peut être à titre illustratif un équipement de type CPE (pour « Customer Premises Equipment » en anglais), ou un relais ou proxy localisé dans l’interface Gi d’un réseau mobile, etc. On peut alors envisager qu’il soit configuré avec une liste de règles lui permettant de sélectionner les dispositifs DNS appropriés pour un service donné. Cette liste de règles peut provenir de mesures effectuées par l’équipement intermédiaire en question ou par un autre équipement permettant à l’équipement intermédiaire de classer les dispositifs DNS en fonction par exemple de leur disponibilité ou de leurs performances. Nous allons maintenant détailler à titre illustratif plusieurs cas d’usage de l’invention. Ces différents cas d’usage guident ou impactent le choix des dispositifs DNS vers lesquels orienter les requêtes DNS de l’équipement client lors de son accès au service. Selon un premier cas d’usage, on désigne comme dispositifs DNS pour le service S, des dispositifs du réseau NW via lesquels on souhaite que des connexions établies par l’équipement client dans le cadre du service S transitent. Ces connexions peuvent comprendre la connexion principale établie par l’équipement client avec le serveur autoritaire pour accéder au service, mais également toutes les connexions secondaires établies en marge de cette connexion principale, parfois à l’insu de l’utilisateur de l’équipement client. Les dispositifs DNS ainsi désignés peuvent ainsi résoudre chaque requête DNS émise par l’équipement client 2 en fournissant leurs propres adresses IP de sorte à recevoir chaque paquet de données émis par l’équipement client sur les connexions principale et secondaires. Sur réception de ces paquets de données, ils peuvent ainsi mettre en place divers traitements, comme par exemple l’analyse du contenu de ces paquets pour déterminer s’ils contiennent des informations d’identification de l’utilisateur, ou d’autres informations qu’ils souhaitent traquer. Les dispositifs DNS peuvent aussi en variante résoudre chaque requête émise par l’équipement client en fournissant l’adresse IP d’un autre équipement de confiance chargé de tels traitements. Ce cas d’usage permet de placer des équipements donnés sur le chemin des connexion principale et secondaires établies par l’équipement client dans le cadre du service S. Selon un deuxième cas d’usage, on désigne comme dispositifs DNS pour le service S, des dispositifs DNS qui ont été configurés pour résoudre entre autres des requêtes de noms de domaine afférant à des noms de domaine privés et/ou personnalisés et/ou encore éphémères, générés dans le cadre du service S, par exemple par le fournisseur du service. Ces noms de domaine sont volontairement gardés secrets et resteront inconnus des serveurs DNS publics ou nominaux configurés par les opérateurs de réseau. Ce deuxième cas d’usage peut être adopté comme mesure de sécurité pour prévenir des attaques de déni de service par exemple. Il permet également au fournisseur de service d’envisager des noms de domaine personnalisables, et par exemple de générer des noms de domaine personnalisés en fonction de l’identité de l’utilisateur de l’équipement client, ou des noms de domaine éphémères. Le recours à des dispositifs DNS propres au service permet de faciliter l’ajout et/ou le retrait de tels noms de domaine et d’éviter la latence induite par une telle démarche auprès d’un serveur DNS public/nominal. Selon un troisième cas d’usage, on peut envisager de désigner comme dispositifs DNS pour le service S, des dispositifs DNS qui ont été configurés pour réaliser une résolution personnalisée des requêtes DNS adressées par un équipement client, par exemple dans un souci de respect des contraintes de service. Par exemple, un tel dispositif DNS peut retourner à un équipement client une adresse IP pour un nom de domaine et située à proximité de l’équipement client (par ex. présentant un délai inférieur à « x ms »). Selon un quatrième cas d’usage, on peut envisager de désigner comme dispositifs DNS pour le service S des dispositifs DNS qui mettent en œuvre des fonctions DNS avancées, qui ne sont pas mises en œuvre par des serveurs DNS publics ou nominaux fournis par les opérateurs de réseau (par exemple qui supporte le protocole DoC, tel que décrit dans le document de M.S. Lenders intitulé « DNS Queries over CoAP (DoC), draft-lenders-dns-over-cap-01 », 1 er septembre 2021. Bien entendu, d’autres cas d’usage de l’invention peuvent être envisagés en complément de ceux qui viennent d’être cités. Procédé de contrôle d’un équipement client (2) pour accéder à un service via au moins un réseau, ledit procédé de contrôle étant destiné à être mis en œuvre par une entité (6,3) de confiance pour ledit service et/ou pour ledit équipement client et comprenant une étape de contrôle (H40) d’une configuration dudit équipement client, lors d’un accès de celui-ci audit service, pour qu’il transmette vers au moins un dispositif (8 ;8-1, …, 8-K) désigné pour ledit service et autorisé par ladite entité de confiance, au moins une requête de résolution de noms de domaine émise par ledit équipement client dans le cadre dudit service. Procédé de contrôle selon la revendication 1 dans lequel ladite entité de confiance (3) est un serveur impliqué dans la fourniture dudit service. Procédé de contrôle selon la revendication 1 dans lequel ladite entité (6) de confiance est une entité intermédiaire placée sur un chemin de communication emprunté lors de l’accès par ledit équipement client audit service. Procédé de contrôle selon l’une quelconque des revendications 1 à 3 dans lequel l’étape (H40) de contrôle d’une configuration dudit équipement client comprend une transmission par l’entité de confiance audit équipement client d’un message comprenant au moins une information de joignabilité (@IP8-1, …, @IP8-K) d’au moins un dit dispositif désigné pour ledit service et autorisé par ladite entité de confiance. Procédé de contrôle selon la revendication 4 dans lequel ledit message est un message de réponse à un message d’invocation dudit service émis par ledit équipement client ou un message envoyé de façon asynchrone par ladite entité de confiance. Procédé de contrôle selon la revendication 4 ou 5 dans lequel ladite au moins une information de joignabilité est incluse dans un entête, une option, une trame, un attribut, ou une charge utile du message. Procédé de contrôle selon l’une quelconque des revendications 4 à 6 dans lequel ledit message est conforme à une version d’un protocole HTTP (HyperText Transfer Protocol) ou d’un protocole CoAP (Constrained Application Protocol) ou d’un protocole QUIC. Procédé de contrôle selon l’une quelconque des revendications 4 à 7 dans lequel ledit message comprend, pour au moins un dit dispositif désigné pour ledit service et autorisé par ladite entité de confiance, au moins une information caractérisant au moins une capacité fonctionnelle dudit dispositif. Procédé de contrôle selon l’une quelconque des revendications 1 à 8 dans lequel au moins une dite requête de résolution de noms de domaine concerne : un nom de domaine privé ; et/ou un nom de domaine généré dans le cadre dudit service pour ledit équipement client ; et/ou un nom de domaine éphémère. Procédé de transmission d’au moins une requête de résolution de noms de domaine destiné à être mis en œuvre par un équipement client (2) dans le cadre d’un service fourni via un réseau, ledit procédé comprenant : une étape (H50) de modification, lors d’un accès audit service et sous un contrôle d’une entité de confiance pour ledit service et/ou ledit équipement client, d’une configuration de l’équipement client pour qu’il transmette vers au moins un dispositif désigné pour un traitement des requêtes de résolution de noms de domaine associées au service et autorisé par ladite entité de confiance, au moins une requête de résolution de noms de domaine émise par ledit équipement client dans le cadre dudit service ; et une étape (H60,H70) de transmission d’au moins une requête de résolution de noms de domaine dans le cadre dudit service vers au moins un dit dispositif désigné. Programme d’ordinateur (PROG6,PROG2) comportant des instructions pour l’exécution d’un procédé de contrôle selon l’une quelconque des revendications 1 à 9 ou d’un procédé de transmission selon la revendication 10, lorsque ledit programme est exécuté par un ordinateur. Support d’enregistrement (12) lisible par un ordinateur (9) sur lequel est enregistré un programme d’ordinateur selon la revendication 11. Entité (6) de confiance pour un service et/ou pour un équipement client d’un réseau, ladite entité de confiance comprenant un module (6B) de contrôle, configuré pour contrôler une configuration dudit équipement client lors d’un accès audit service, pour qu’il transmette vers au moins un dispositif désigné pour ledit service et autorisé par ladite entité de confiance, au moins une requête de résolution de noms de domaine émise par ledit équipement client dans le cadre dudit service. Equipement client (2) d’un réseau comprenant : un module (2B) de modification, configuré pour modifier, lors d’un accès à un service fourni via le réseau et sous un contrôle d’une entité de confiance pour ledit service et/ou ledit équipement client, une configuration de l’équipement client pour qu’il transmette vers au moins un dispositif désigné pour un traitement des requêtes de résolution de noms de domaine associées au service et autorisé par ladite entité de confiance au moins une requête de résolution de noms de domaine émise par ledit équipement client dans le cadre dudit service ; et un module (2C) de transmission, configuré pour transmettre au moins une requête de résolution de noms de domaine dans le cadre dudit service vers au moins un dit dispositif désigné. Equipement client selon la revendication 14 comprenant en outre un module (2C) d’obtention, configuré pour obtenir pour au moins un dit dispositif désigné, une information caractérisant au moins une capacité fonctionnelle de ce dispositif, ledit module de transmission étant configuré pour transmettre ladite au moins une requête de résolution de noms de domaines vers un dit dispositif sélectionné en fonction de ladite au moins une capacité fonctionnelle de ce dispositif. Système (1) d’accès à un service fourni via un réseau comprenant : une entité (6) de confiance selon la revendication 13 : un équipement client (2) selon la revendication 14 ou 15 ; et au moins un dispositif (8 ;8-1, …, 8-K) désigné pour un traitement des requêtes de résolution de noms de domaine associées audit service et autorisé par ladite entité de confiance avec lequel est configuré ledit équipement client par ladite entité de confiance pour transmettre au moins une requête de résolution de noms de domaine dans le cadre de l’accès audit service.