PROCEDES DE RESOLUTION DE NOM, DE COMMUNICATION, DE TRAITEMENT DE MESSAGES ET SERVEUR, DISPOSITIF CLIENT ET NOEUD RELAIS CORRESPONDANTS

Technique antérieure

[0001] L'invention appartient au domaine général des télécommunications.

[0002] Elle concerne plus particulièrement les communications avec un serveur de résolution de noms de domaine (ou DNS pour « Domain Name System » en anglais) dans un réseau de télécommunications, comme par exemple un réseau IP (pour « Internet Protocol » en anglais).

[0003] Le système DNS est une composante fondamentale dans la fourniture de services IP. En effet, il permet d'associer une ressource (telle qu'un nom de domaine, une URI (pour « Uniform Resource Identifier » en anglais), etc.) à une ou plusieurs adresses IP qui permettent à un dispositif (tel que par exemple un terminal) d'accéder à cette ressource.

[0004] A titre d'exemple, un serveur joignable en IPv4 publie auprès du système DNS un enregistrement (ou RR pour « Resource Record » en anglais) DNS de type « A », tandis qu'un serveur joignable en IPv6 publie un enregistrement DNS de type « AAAA » (ou « Quad A Resource Record » en anglais) ; un serveur joignable en IPv4 et IPv6 publie les deux types d'enregistrement.

[0005] Lorsqu'un dispositif souhaite établir une communication avec un serveur dit « destinataire » identifié par un nom de domaine (ou FQDN pour « Fully Qualified Domain Name » en anglais), le client DNS embarqué dans le dispositif envoie une requête de résolution de noms de domaine (dite requête DNS) à un serveur du système DNS (ou serveur DNS par souci de simplification) en précisant dans la requête le type d'enregistrement souhaité (A ou AAAA). Un dispositif supportant les deux protocoles IPv4 et IPv6 envoie deux requêtes DNS à un serveur DNS (une indiquant un enregistrement de type A, l'autre un enregistrement de type AAAA).

[0006] Sur réception de cette requête, le serveur DNS répond au dispositif en lui envoyant au moins une adresse IP associée au nom de domaine sur lequel porte la requête si une entrée correspondant à ce nom de domaine est disponible. S'il ne dispose pas d'une telle entrée, le serveur DNS relaie la requête vers un autre serveur selon la hiérarchie DNS connue de l'homme du métier. La réponse reçue de cet autre serveur est ensuite relayée par le serveur DNS initialement sollicité vers le dispositif à l'origine de la requête DNS. Le dispositif extrait l'adresse ou les adresses IP contenues dans la réponse et établit une communication avec le serveur destinataire en utilisant typiquement l'une de ces adresses IP.

[0007] Ces échanges entre le dispositif et le serveur DNS (désignés dans la suite par « communications DNS » par souci de simplification) sont conventionnellement mis en œuvre en clair, selon un mode appelé Do53 (ou « unencrypted DNS » en anglais). Ce mode non chiffré rend possible, aux entités localisées sur le chemin des communications DNS, l'accès à des informations sensibles, par exemple à des fins de profilage. Do53 présente donc un risque d'atteinte à la vie privée des utilisateurs.

[0008] Afin d'améliorer le niveau de confidentialité des communications DNS et restreindre l'accès aux informations sensibles véhiculées par ces communications DNS uniquement à des entités habilitées ou consenties, de nombreux mécanismes ont été spécifiés pour chiffrer les communications DNS. Des exemples de tels mécanismes sont « DNS over DTLS (DoD) », « DNS over TLS (DoT) », « DNS over HTTPS (DoH) », « DNS over QUIC (DoQ) », DNS over CoAP (ou DoC), etc. Toutefois, en dépit de la mise en œuvre de tels mécanismes, une entité localisée dans le chemin de communications DNS peut associer l'adresse de destination de paquets de données émis après un échange DNS avec un serveur ou un service donné en utilisant des techniques dites d'analyse statistique (ou « statistical analysis » en anglais), et obtenir ainsi des informations potentiellement sensibles sur les utilisateurs. Une étude de l'APNIC (pour « Asia Pacific Network Information Centre » en anglais) datant de 2019 s'est en effet intéressée aux informations qu'il est possible de tirer d'un ensemble d'adresses IP contactées par un équipement utilisateur. Cette étude montre notamment que la majorité des sites web ont une empreinte de chargement de page ou PLF (pour « Page Load Fingerprint » en anglais) unique ; il existe donc un risque qu'un site web visité par un utilisateur puisse être identifié à partir des adresses IP ciblées par son équipement utilisateur. Il en résulte une protection limitée de la vie privée des utilisateurs par les mécanismes DNS chiffrés précités.

Exposé de l'invention

[0009] L'invention vient notamment améliorer la situation précitée en proposant un procédé de traitement d'une première requête de résolution de nom provenant d'un dispositif client, ce procédé étant mis en œuvre par un serveur de résolution de noms et comprenant un envoi au dispositif client d'une réponse à la première requête comprenant au moins une information relative à un serveur dit destinataire résultant d'une résolution de la première requête. Le procédé de traitement est remarquable en ce qu'il comprend en outre un envoi au dispositif client d'une pluralité d'éléments comprenant : au moins une adresse d'au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais.

[0010] Corrélativement, l'invention concerne également un serveur de résolution de noms configuré pour envoyer une réponse à une première requête de résolution de nom provenant d'un dispositif client, cette réponse comprenant au moins une information relative à un serveur dit destinataire résultant d'une résolution de la première requête. Le serveur de résolution de noms est remarquable en ce qu'il est en outre configuré pour envoyer au dispositif client une pluralité d'éléments comprenant : au moins une adresse d'au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais.

[0011] L'invention vise aussi un procédé de communication mis en œuvre par un dispositif client, comprenant une réception, en provenance d'un serveur de résolution de noms, d'une réponse à une première requête de résolution de nom émise par le dispositif client, cette réponse comprenant au moins une information relative à un serveur dit destinataire résultant d'une résolution de la première requête. Le procédé de communication est remarquable en ce qu'il comprend en outre : une réception d'une pluralité d'éléments, en provenance du serveur de résolution de noms, comprenant : o au moins une adresse d'au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et o au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais ; et une application de ladite instruction de brouillage auxdits messages.

[0012] Corrélativement, l'invention concerne également un dispositif client configuré pour recevoir, en provenance d'un serveur de résolution de noms, une réponse à une première requête de résolution de nom émise par le dispositif client, cette réponse comprenant au moins une information relative à un serveur dit destinataire résultant d'une résolution de la première requête. Le dispositif client est remarquable en ce qu'il est en outre configuré pour : recevoir une pluralité d'éléments, en provenance du serveur de résolution de noms, comprenant : o au moins une adresse d'au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et o au moins une instruction de brouillage devant être appliquée par le dispositif client aux- dits messages avant de les adresser audit au moins un nœud relais ; et appliquer ladite instruction de brouillage auxdits messages.

[0013] Selon un autre aspect encore, l'invention vise aussi un procédé de traitement de messages mis en œuvre par un nœud relais sélectionné par un serveur de résolution de noms pour un dispositif client et un serveur destinataire, ce procédé comprenant : une acquisition d'au moins une information relative à au moins une instruction de brouillage appliquée par le dispositif client à des messages contenant des données destinées au serveur destinataire avant de les adresser au nœud relais ; sur réception d'au moins un message brouillé contenant des données destinées au serveur destinataire et adressé au nœud relais par le dispositif client, une suppression en utilisant ladite au moins une information acquise, du brouillage appliqué par le dispositif client ; et un transfert dudit au moins un message obtenu après suppression du brouillage vers le serveur destinataire.

[0014] Corrélativement, l'invention concerne également un nœud relais dans un réseau de communications sélectionné par un serveur de résolution de noms pour un dispositif client et un serveur destinataire, ce nœud relais étant configuré pour : acquérir au moins une information relative à au moins une instruction de brouillage appliquée par le dispositif client à des messages contenant des données destinées au serveur destinataire avant de les adresser au nœud relais ; sur réception d'au moins un message brouillé contenant des données destinées au serveur destinataire et adressé au nœud relais par le dispositif client, supprimer en utilisant ladite au moins une information acquise, le brouillage appliqué par le dispositif client ; et transférer ledit au moins un message obtenu après suppression du brouillage vers le serveur destinataire.

[0015] L'invention propose donc une solution qui permet de prévenir l'accès à des informations sensibles par des équipements qui sont proches du dispositif client (du point de vue de la topologie du réseau). Ainsi, la solution s'applique particulièrement au niveau du réseau d'accès utilisé par un dispositif client (ex. réseau WLAN (« Wireless Local Area Network » en anglais) public ou privé, réseau mobile, etc.) en s'appuyant sur une pluralité d'entités de réseau (serveur(s) de résolution de noms, nœud(s) relais), pour prévenir des actions malveillantes susceptibles d'être mises en œuvre lors de communications DNS, ou plus généralement lors de communications en lien avec la résolution de ressources telles que des URI, des noms de domaine, etc. Ces ressources sont plus généralement désignées par « noms » dans la suite de ce document. L'invention a une application privilégiée mais non limitative lorsque les communications en question sont chiffrées ; aucune limitation n'est attachée au schéma de chiffrement envisagé alors pour transporter les messages échangés lors de ces communications (par exemple, pour des communications DNS, DoT, DoD, DoQ, DoH, DoC).

[0016] De même, aucune limitation n'est imposée quant à la nature du dispositif client (qui peut être par exemple un terminal, un CPE (pour « Customer Premises Equipment » en anglais), un décodeur de type STB (pour « Set Top Box » en anglais), etc.), ni à celle du nœud relais sélectionné par le serveur de résolution de noms (qui peut être notamment un serveur, un routeur, etc.).

[0017] La solution proposée par l'invention s'appuie plus particulièrement sur la sélection, par un serveur de résolution de noms de confiance sollicité par le dispositif client lorsqu'il souhaite accéder à un service donné, typiquement fourni par un serveur dit destinataire, d'au moins un nœud relais via lequel le dispositif client va interagir avec le serveur destinataire. Plusieurs nœuds relais peuvent être avantageusement utilisés lors d'une communication avec un serveur destinataire, par exemple chaque nœud relais est utilisé durant une période de temps limitée. Il convient par ailleurs de noter qu'une requête de résolution de nom peut donner lieu à une ou plusieurs communications avec un ou plusieurs serveurs destinataires. Les communications avec ces différents serveurs destinataires peuvent être gérées avec un ou plusieurs nœuds relais.

[0018] Plus spécifiquement, conformément à l'invention, le dispositif client adresse les messages contenant les données qu'il destine au serveur destinataire (autrement dit contenant les données qu'il souhaite lui envoyer dans le cadre de l'accès au service) à un nœud relais, qui se charge ensuite de les relayer vers le serveur destinataire. L'introduction d'un nœud relais entre le dispositif client et le serveur destinataire a pour effet de masquer le véritable destinataire (à savoir le serveur destinataire) des données envoyées par le dispositif client lorsqu'il accède au service, puisque l'adresse à laquelle sont envoyés les messages est celle du nœud relais et non celle du serveur destinataire, conformément à l'invention. L'adresse du serveur destinataire est quant à elle dissimulée dans le contenu des messages adressés au nœud relais, par exemple sous forme chiffrée au moyen d'un mécanisme de chiffrement partagé avec le nœud relais. Ceci permet de rendre l'identité du serveur destinataire inaccessible en cas d'interception des messages entre le dispositif client et le nœud relais et ce, tout en permettant au nœud relais de relayer ces messages vers le serveur destinataire.

[0019] Par exemple, dans un mode particulier de réalisation, les messages adressés audit au moins un nœud relais comprennent, sous forme chiffrée, des données destinées au serveur destinataire et une adresse du serveur destinataire.

[0020] Ces dispositions rendent ainsi difficile voire impossible à une entité malveillante localisée entre le dispositif client et le nœud relais d'obtenir par analyse statistique du trafic issu du dispositif client et/ou en établissant et analysant une empreinte de chargement de page, des informations révélant les pratiques de l'utilisateur du dispositif client et susceptibles de porter atteinte à sa vie privée.

[0021] De façon similaire, l'introduction d'un nœud relais entre le dispositif client et le serveur destinataire permet de masquer la véritable source des messages (c'est-à-dire l'identité du dispositif client), en cas d'interception et d'inspection de ces messages par une entité malveillante localisée au-delà du nœud relais (dans le sens dispositif client vers serveur destinataire).

[0022] Cette difficulté à obtenir par analyse statistique du trafic des données sensibles est accrue lorsque l'utilisation d'un (ou de plusieurs) nœud(s) relais est combinée avec une ou plusieurs actions de brouillage (supplémentaires) mises en œuvre par le dispositif client (éventuellement complétée(s) par des actions de brouillage mises en œuvre par le(s) nœud(s) relais). Ces actions de brouillage sont transmises sous formes d'instructions de brouillage au dispositif client par le serveur de résolution et peuvent être de différentes natures.

[0023] Par exemple, dans un mode particulier de réalisation du procédé de traitement de la première requête, ladite au moins une instruction de brouillage transmise par le serveur de résolution de noms au dispositif client comprend une instruction de bourrage (ou de remplissage ou encore de « padding » en anglais) des messages contenant des données destinées au serveur destinataire avant de les adresser audit au moins un nœud relais, cette instruction comprenant au moins un motif de bourrage à utiliser par le dispositif client pour brouiller lesdits messages ou une technique de génération d'au moins un tel motif de bourrage.

[0024] Corrélativement, dans un mode particulier de réalisation du procédé de communication, ladite au moins une instruction de brouillage comprend une instruction de bourrage desdits messages et l'application de ladite au moins une instruction de brouillage auxdits messages comprend un bourrage d'au moins un dit message contenant des données destinées au serveur destinataire et adressé au nœud relais en utilisant un motif de bourrage fourni dans ladite instruction de bourrage ou généré au moyen d'une technique de génération fournie dans ladite instruction de bourrage.

[0025] A titre illustratif, une instruction de bourrage des messages peut consister, dans le cadre d'un service de communication de type voix s'appuyant sur l'échange de paquets de données de petite taille entre le dispositif client et le serveur destinataire, à augmenter la longueur des paquets de données envoyés au nœud relais par le dispositif client et destinés au serveur destinataire en utilisant un motif de bourrage déterminé, fourni par le serveur de résolution de noms, ou généré par le dispositif client selon une technique de génération de motifs de bourrage fournie par le serveur de résolution de noms.

[0026] Le bourrage des messages par le dispositif client permet de banaliser le profil des messages émis par le dispositif client et ainsi d'homogénéiser le trafic en sortie du dispositif client. Pour renforcer la protection des données véhiculées par les messages envoyés au nœud relais, comme évoqué précédemment, les données, le motif de bourrage complétant ces données, et l'adresse du serveur destinataire peuvent être chiffrés avant d'être adressés au nœud relais. Ceci permet en outre de garantir l'authenticité et l'intégrité des messages échangés entre le dispositif client et le nœud relais, et les informations contenues dans ces messages. On peut, dans un mode particulier de réalisation, envisager une activation du chiffrement par défaut pour l'envoi de ces informations critiques (par ex. pour le motif de brouillage).

[0027] D'autres actions de brouillage des messages avant leur envoi au nœud relais peuvent être envisagées en sus ou en remplacement des actions précitées.

[0028] Ainsi, dans un autre mode de réalisation, ladite au moins une instruction de brouillage comprend une instruction d'établissement par le dispositif client d'au moins une connexion fictive avec et/ou via ledit au moins un nœud relais.

[0029] Une telle connexion fictive est établie en parallèle de la connexion utilisée par le dispositif client pour transmettre au nœud relais les messages destinés au serveur destinataire (désignée dans la suite par « connexion principale »). Elle peut se terminer au niveau du nœud relais ou être relayée par ce dernier jusqu'à un serveur dédié (c'est-à-dire capable d'établir et de gérer une connexion fictive convenablement et en toute connaissance de cause). Le dispositif client peut être configuré pour transmettre sur cette connexion fictive des données fictives, c'est-à-dire qui ne sont pas destinées à être « consommées » (c'est-à-dire exploitées, utilisées) par le nœud relais et/ou par le serveur dédié qui les reçoit. De même, les données applicatives fictives éventuellement transmises par le serveur dédié ne sont pas consommées par le relais et/ou par le dispositif client.

[0030] Dans un mode particulier de réalisation, le procédé de traitement d'une première requête de résolution de noms ou le procédé de communication peut comprendre en outre une étape de notification audit au moins un nœud relais d'au moins une information relative à ladite au moins une instruction de brouillage.

[0031] Cette notification du nœud relais par le serveur de résolution de noms ou par le dispositif client permet au nœud relais d'identifier aisément et de supprimer le brouillage appliqué des messages brouillés provenant du dispositif client avant leur transmission vers le serveur destinataire.

[0032] L'information notifiée au nœud relais peut comprendre l'instruction de brouillage en elle-même, telle qu'ordonnée par le serveur de résolution de noms au dispositif client, ou seulement certains éléments représentatifs de cette instruction de brouillage, suffisants pour permettre au nœud relais d'être en mesure de supprimer le brouillage introduit par le dispositif client. Par exemple, dans le cas d'une instruction de bourrage des messages, l'information en question, lorsqu'elle est notifiée au nœud relais par le dispositif client, peut être un indicateur délimitant ou identifiant le motif de bourrage contenu dans un message (par exemple, un tel indicateur peut comprendre un décalage de bits ou de symboles aussi appelé « bit/symbol offset » en anglais).

[0033] Les actions de brouillage ordonnées par le serveur de résolution de noms sont avantageusement prises en compte par le nœud relais lorsqu'il reçoit des messages brouillés du dispositif client contenant des données destinées au serveur destinataire, afin d'identifier puis de supprimer le brouillage introduit par le dispositif client avant de relayer les messages vers le serveur destinataire.

[0034] Le nœud relais peut également, sur réception d'au moins un message provenant du serveur destinataire et contenant des données destinées au dispositif client, appliquer un brouillage dudit au moins un message avant de le transférer vers le dispositif client, de façon transparente pour le serveur destinataire.

[0035] Le brouillage introduit par le nœud relais peut être équivalent à celui appliqué par le dispositif client (autrement dit de même nature, par exemple reposer sur les mêmes motifs de bourrage). Ce mode est appelé « mode de brouillage symétrique ».

[0036] En variante, le brouillage introduit par le nœud relais peut être différent de celui appliqué par le dispositif client ; par exemple, un bourrage des messages peut n'être appliqué que dans un sens, ou des motifs de bourrage différents peuvent être appliqués dans les deux sens, ou encore une émulation de connexions fictives peut être réalisée dans un sens (par exemple du dispositif client vers le nœud relais) tandis qu'un bourrage des messages est appliqué dans l'autre sens (par exemple du nœud relais vers le dispositif client), etc. Ce mode est appelé « mode de brouillage asymétrique ». Cette différence dans les actions de brouillage appliquées permet de tenir compte du caractère asymétrique de la volumétrie du trafic selon sa direction. En effet, une quantité plus importante de données utiles est généralement transmise dans le sens nœud relais vers dispositif client. Ces données peuvent présenter, pour une application donnée, des profils constants dans le temps et ainsi être utilisées pour des besoins de profilage (et donc de traçabilité/* tracking ») de l'utilisateur. Par conséquent, l'application d'un brouillage adéquat dans chacun des deux sens de la communication permet une protection plus efficace des informations sensibles relatives au dispositif client ou à son utilisateur.

[0037] Par ailleurs, il convient de noter qu'il n'est pas toujours possible d'appliquer le même brouillage dans le sens dispositif client vers nœud relais et dans le sens nœud relais vers dispositif client (par exemple, il se peut que les messages envoyés dans le sens dispositif client vers nœud relais ne contiennent pas autant de données que dans le sens inverse).

[0038] Grâce au brouillage introduit par le dispositif client, et éventuellement par le nœud relais, il est difficile voire impossible pour une entité tierce malveillante de déduire/extraire/extrapoler des informations sur le trafic en provenance et/ou à destination du dispositif client. Combinées à l'intervention du nœud relais jouant l'intermédiaire entre le dispositif client et le serveur destinataire, il est possible d'éliminer la mise en œuvre d'analyses statistiques par des entités tierces malveillantes présentes dans les réseaux impliqués dans l'acheminement du trafic DNS ou tout du moins de réduire la portée de telles analyses statistiques et de limiter la pertinence des informations qui sont obtenues à partir de telles analyses statistiques.

[0039] L'invention permet donc de garantir le respect de la confidentialité des communications établies par des dispositifs clients, et contribue à mieux préserver la vie privée des utilisateurs de ces dispositifs clients et à limiter les risques de profilage des utilisateurs. Les opérateurs de réseaux peuvent incidemment, par le biais de l'invention, offrir des services de résolution de noms (ex. services DNS) à valeur ajoutée et ainsi bénéficier de la confiance de leurs utilisateurs. On note que les utilisateurs en question ne sont pas nécessairement ceux auxquels les opérateurs fournissent une connectivité réseau.

[0040] Comme mentionné précédemment, l'introduction d'un nœud relais entre le dispositif client et le serveur destinataire a pour but de masquer le véritable destinataire des messages émis par le dispositif client, ainsi que la véritable source de ces messages (lorsqu'une inspection indue des messages a lieu au-delà du nœud relais), rendant difficile la mise en œuvre d'analyse statistique du trafic issu du dispositif client. Cette difficulté peut être accrue via un choix judicieux du ou des nœuds relais à utiliser par un dispositif client. Par exemple, au moins un dit nœud relais peut être sélectionné par le serveur de résolution de noms de sorte que le nœud relais satisfait au moins une condition parmi : empêcher une corrélation entre ce nœud relais et le serveur destinataire (par exemple, un même nœud relais peut être utilisé pour plusieurs serveurs destinataires distincts, ou des nœuds relais différents peuvent être sélectionnés pour un même dispositif client et un même serveur destinataire mais pour des communications différentes entre le dispositif client et le serveur destinataire) ; et/ou maximiser le nombre de dispositifs clients utilisant ledit nœud relais.

Ces critères permettent de limiter le risque de traçage des communications visant une résolution de nom (par ex. communications DNS) par une entité malveillante.

[0041] D'autres conditions à vérifier peuvent être prises en compte lors de la sélection d'un nœud relais pour un dispositif client et un serveur destinataire, comme optimiser les dispositifs clients utilisant le nœud relais sélectionné en fonction d'au moins un critère donné, tel que des considérations de charge ou des considérations géographiques (qui peuvent relever notamment d'un savoir-faire de l'opérateur et/ou de l'ingénierie/configuration des nœuds relais). Selon un autre exemple encore, un nœud relais peut être sélectionné parce qu'il vérifie une condition consistant à disposer (déjà) d'une route vers le serveur destinataire.

[0042] Il convient de noter que les critères évoqués ci-dessus ne sont pas exclusifs ; autrement dit, le serveur de résolution de noms peut prendre en compte plusieurs critères de façon simultanée pour sélectionner un nœud relais pour le dispositif client et le serveur destinataire.

[0043] Dans un mode particulier de réalisation, la pluralité d'éléments transmise par le serveur de résolution au dispositif client (et incidemment reçue par le dispositif client en provenance du serveur de résolution) comprend en outre une première indication qu'au moins un dit nœud relais peut être utilisé par le dispositif client pour envoyer au moins une deuxième requête de résolution de nom corrélée à la première requête.

[0044] En d'autres termes, non seulement le nœud relais en question est utilisé par le dispositif client pour transmettre des messages au serveur destinataire, mais il est également chargé de résoudre tout ou partie des futures requêtes de résolution de noms du dispositif client corrélées avec la première requête, par exemple portant sur un nom d'un sous-domaine d'un nom de domaine sur lequel portait la première requête. Ceci permet d'introduire un degré supplémentaire de brouillage, en rendant difficile l'établissement d'un lien par une entité malveillante entre un serveur de résolution de noms particulier et un dispositif client. En outre, chaque serveur de résolution de noms impliqué dans la communication du dispositif client avec le serveur destinataire n'a qu'une connaissance partielle des requêtes émises par le dispositif client.

[0045] On peut envisager d'introduire un degré de granularité dans les requêtes de résolution de noms orientées vers un nœud relais. Ainsi, dans un mode particulier de réalisation, la pluralité d'éléments transmise par le serveur de résolution au dispositif client (et incidemment reçue par le dispositif client en provenance du serveur de résolution) peut comprendre en outre une deuxième indication identifiant les requêtes de résolution de nom concernées par la première indication.

[0046] Dans un mode particulier de réalisation, la pluralité d'éléments transmise par le serveur de résolution au dispositif client (et incidemment reçue par le dispositif client en provenance du serveur de résolution) comprend en outre au moins un identifiant dudit au moins un nœud relais sélectionné par le serveur de résolution de noms.

[0047] Ce mode de réalisation présente plusieurs avantages.

[0048] Tout d'abord, il permet de gérer les situations où plusieurs nœuds relais peuvent être joignables en utilisant une même adresse IP. L'identifiant transmis dans la pluralité d'éléments permet au dispositif client de distinguer un nœud relais particulier parmi la pluralité de nœuds relais partageant la même adresse IP. [0049] En outre, la transmission de l'identifiant du nœud relais sélectionné par le serveur de résolution de noms permet de s'affranchir du maintien au niveau du serveur de résolution de noms d'états associant à chaque dispositif client le contactant un ou plusieurs nœuds relais (on parle dans ce cas de serveur de résolution de noms sans état ou « stateless » en anglais).

[0050] Dans un mode particulier de réalisation, la première requête comprend au moins un identifiant d'au moins un nœud relais précédemment sélectionné pour le dispositif client auquel le dispositif client envoie tout ou partie de ses messages contenant des données destinées au serveur destinataire.

[0051] Il convient de noter que le nœud relais en question peut avoir été sélectionné pour le dispositif client et pour le même serveur destinataire (typiquement pour une même communication avec ce serveur destinataire), par le serveur de résolution de noms auquel le dispositif client adresse la première requête ou par un autre serveur de résolution de noms. L'insertion de l'identifiant du nœud relais en cours d'utilisation par le dispositif client permet au serveur de résolution de noms auquel est adressée la première requête, selon la stratégie adoptée, soit de resélectionner le même nœud relais (c'est- à-dire au moins un dit nœud relais sélectionné par le serveur de résolution de noms coïncide avec un nœud relais identifié dans la première requête), par exemple pour exploiter une connexion existante, soit au contraire, de sélectionner sciemment un nœud relais différent, de façon à rendre plus difficile encore le traçage des communications du dispositif client. Il est en effet plus difficile dans ce dernier cas de corréler le serveur destinataire avec l'identité du relais inclus dans la première requête.

[0052] Par ailleurs, ce mode de réalisation permet de limiter les informations stockées par le serveur de résolution de noms (pas de maintien d'états nécessaire, comme expliqué précédemment), ce qui renforce la sécurité du mécanisme mis en œuvre par l'invention et limite les risques de traçage du dispositif client sur la base de ses communications DNS.

[0053] Dans un mode particulier de réalisation, la pluralité d'éléments est envoyée au dispositif client ou reçue par le dispositif client dans une réponse à la première requête de résolution.

[0054] Ce mode de réalisation permet d'appliquer sans délai l'invention à partir de la première requête de résolution. En outre, il permet avantageusement de limiter la signalisation requise entre le serveur de résolution de noms et le dispositif client pour mettre en œuvre l'invention.

[0055] Il convient de noter que l'utilisation des adjectifs « première » et « deuxième » a uniquement pour dessein de distinguer deux requêtes de résolution de noms successives, corrélées entre elles, par exemple une requête portant sur un nom de domaine et une requête ultérieure portant sur un sous- domaine de ce nom de domaine. Cette utilisation ne présuppose pas l'absence d'échanges DNS ou plus généralement de résolution de noms antérieur entre le dispositif client et le serveur de résolution de noms, par exemple l'envoi par le dispositif client et la résolution par le serveur de résolution de noms d'une requête portant sur un autre nom de domaine.

[0056] Dans un mode de réalisation l'envoi de ladite pluralité d'éléments par le serveur de résolution de noms au dispositif client est conditionné par une détection par le serveur de résolution de noms d'une option déterminée dans la première requête.

[0057] Ce mode de réalisation offre la possibilité à l'utilisateur du dispositif client de choisir s'il souhaite ou non bénéficier du mécanisme de protection proposé par l'invention. Par exemple, si le réseau utilisé par le dispositif client de l'utilisateur pour accéder au service fourni par le serveur destinataire est un réseau de confiance, l'utilisateur peut décider de désactiver la mise en œuvre de l'invention . A l'inverse, si le réseau n'est pas un réseau de confiance, l'utilisateur peut décider d'avoir recours à l'invention. Il convient de noter que cette désactivation peut également être réalisée par le dispositif client lui-même, de façon automatique c'est-à-dire sans intervention de l'utilisateur, de façon transparente pour lui.

[0058] Dans un mode particulier de réalisation, les procédés de traitement d'une (première) requête et de messages, et/ou de communication sont mis en œuvre par un ordinateur. [0059] 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 un serveur de résolution de nom conforme à l'invention et comportant des instructions adaptées à la mise en œuvre d'un procédé de traitement d'une première requête de résolution de nom tel que décrit ci-dessus.

[0060] 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 un dispositif client conforme à l'invention et comportant des instructions adaptées à la mise en œuvre d'un procédé de communication tel que décrit ci-dessus.

[0061] L'invention vise aussi 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 un nœud relais conforme à l'invention et comportant des instructions adaptées à la mise en œuvre d'un procédé de traitement de messages tel que décrit ci-dessus.

[0062] 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.

[0063] L'invention vise aussi un support d’informations ou un support d'enregistrements lisible par un ordinateur, et comportant des instructions d'un programme d’ordinateur tel que mentionné ci-dessus.

[0064] Le support d’informations ou d'enregistrements 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.

[0065] D’autre part, le support d’informations ou d'enregistrements 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.

[0066] Le programme selon l’invention peut être en particulier téléchargé sur un réseau de type Internet.

[0067] Alternativement, le support d’informations ou d'enregistrements 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 traitement et de communication selon l'invention.

[0068] Selon un autre aspect, l'invention concerne également un système dans un réseau de communications comprenant : un dispositif client selon l'invention ; un serveur de résolution de noms selon l'invention ; et au moins un nœud relais selon l'invention sélectionné par le serveur de résolution de noms pour ledit dispositif client.

[0069] Le système selon l'invention bénéficie des mêmes avantages cités précédemment que le dispositif client, le serveur de résolution de noms et le nœud relais selon l'invention.

[0070] On peut également envisager, dans d’autres modes de réalisation, que les procédés de traitement et de communications, le serveur de résolution de noms, le dispositif client, le nœud relais et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.

Brève description des dessins

[0071] 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 :

[Fig. 1] la figure 1 représente, dans son environnement, un système dans un réseau conforme à l'invention, dans un mode particulier de réalisation ;

[Fig. 2] la figure 2 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 figure 1 ;

[Fig. 3] la figure 3 représente les modules fonctionnels d'un serveur de résolution de noms du système de la figure 1, conforme à l'invention ;

[Fig. 4] la figure 4 représente les modules fonctionnels d'un dispositif client du système de la figure 1, conforme à l'invention ;

[Fig. 5] représente les modules fonctionnels d'un nœud relais du système de la figure 1, conforme à l'invention ;

[Fig. 6] la figure 6 représente sous forme d'ordinogramme les principales étapes d'un procédé de traitement d'une requête de résolution de nom telles qu'elles sont mises en œuvre par le serveur de résolution de noms de la figure 3 ;

[Fig. 7] la figure 7 représente sous forme d'ordinogramme les principales étapes d'un procédé de communication telles qu'elles sont mises par le dispositif client de la figure 4 ;

[Fig. 8] la figure 8 représente sous forme d'ordinogramme les principales étapes d'un procédé de traitement de messages telles qu'elles sont mises en œuvre par le nœud relais de la figure 5 ;

[Fig. 9] la figure 9 comprend les figures 9A et 9B représentant respectivement une option EAO (pour « EDNS (Extension Mechanisms for DNS) ASTRA (A DNS-driven Guard Against STatistical Trafic Analysis) Option ») pouvant être utilisée dans une requête de résolution de noms et dans la réponse à cette requête pour mettre en œuvre l'invention, dans un mode particulier de réalisation ;

[Fig. 10] la figure 10 illustre de façon partielle et schématique un message brouillé adressé au nœud relais de la figure 5 et contenant des données destinées au serveur destinataire de la figure 1 ;

[Fig. 11] la figure 11 illustre schématiquement les changements de numéros de port et d'adresses source et de destination opérés par le nœud relais de la figure 5, dans une variante particulière de réalisation ; et

[Fig. 12] la figure 12 comprend les figures 12A et 12B représentant les échanges entre les entités du système 1 de la figure selon que le dispositif client du système supporte ou non la fonction « partial-offload ».

Description de l'invention

[0072] La figure 1 représente un système 1 dans un réseau de communications NW, conforme à l'invention, dans un mode particulier de réalisation. Aucune limitation n'est imposée quant à la nature du réseau de communications NW, celui-ci pouvant comprendre un ou plusieurs sous-réseaux, comme par exemple un ou plusieurs (sous-)réseaux d'accès (par exemple un réseau public ou privé de type WLAN, un réseau mobile, etc.), le réseau Internet, etc.

[0073] Conformément à l'invention, le système 1 comprend : un dispositif client 2, conforme à l'invention. Dans l'exemple de la figure 1, le dispositif client 2 est un terminal d'un utilisateur U tel qu'un téléphone mobile (par exemple de type « smartphone »), connecté à un réseau WLAN public AN 1 et à un réseau d'accès mobile AN2 via lesquels il peut accéder au réseau Internet. L'invention s'applique bien entendu à d'autres dispositifs clients fixes ou mobiles (par exemple à un décodeur tel qu'une STB, un CPE, etc.), ainsi qu'à d'autres réseaux (filaires, sans fil, etc.), le dispositif client 2 pouvant être connecté simultanément à un ou plusieurs réseaux d'accès, directement ou via un équipement intermédiaire tel qu'un CPE ; au moins un serveur de résolution de noms de confiance pour le dispositif client 2 (typiquement, considéré comme tel par l'utilisateur U du dispositif client 2), conforme à l'invention, et référencé de manière générale par 3. Dans l'exemple de la figure 1, on considère à titre illustratif deux serveurs 3 de confiance conformes à l'invention. Ces serveurs 3-1 et 3-2 sont à titre illustratif des serveurs de résolution de noms de domaine tels que définis par le document IETF RFC 1034, novembre 1987, aussi couramment désignés par serveurs DNS. L'invention peut toutefois s'appliquer dans le contexte de la résolution d'autres ressources IP désignées dans ce document de façon générale par « noms », comme par exemple des URI, etc. ; et au moins un nœud relais 4-1, 4-2, etc. conforme à l'invention, désigné plus généralement sous la référence 4 et s'interfaçant avec les serveurs 3 de résolution de noms, par exemple en utilisant le protocole RESTCONF décrit dans le document IETF RFC 8040, janvier 2017. Bien entendu, d'autres protocoles peuvent être envisagés en variante pour cette interface.

[0074] Dans le mode de réalisation décrit ici, le mécanisme proposé par l'invention, désigné dans la suite par procédure ou mécanisme AD ASTRA (pour « Advanced DNS-driven protection Against Statistical TRaffic Analysis » en anglais), est activé lorsque le dispositif client 2 utilise, pour accéder au réseau Internet et plus particulièrement à un service S quelconque (ex. service de communication vocale, service web, etc.) hébergé ou fourni par un serveur 5 distant associé à (c'est-à-dire identifié par) un nom de domaine donné (par exemple à titre illustratif, « service-s.com »), un réseau d'accès qui n'est pas un réseau de confiance pour le dispositif client 2. Un tel réseau, appelé « Untrusted » en anglais, est par exemple un réseau public tel que le réseau WLAN public AN1, ou un réseau « visiteur » tel qu'un réseau d'hôtel, de bar, d'une ville, etc. Il présente en effet un risque pour le dispositif client 2 selon lequel ses communications, notamment avec un serveur DNS 6 local du réseau en question, peuvent être interceptées par une entité tierce malveillante et le cas échéant exploitées par cette entité, par exemple en procédant à une analyse statistique, pour obtenir des informations susceptibles de compromettre la vie privée de l'utilisateur U.

[0075] Le mécanisme AD ASTRA est en revanche désactivé ici (bien que cela ne soit pas obligatoire), lorsque le réseau d'accès utilisé par le dispositif client 2 est un réseau de confiance pour le dispositif client 2 (aussi désigné par « Trusted Network » en anglais), comme par exemple le réseau mobile AN2. Un tel réseau de confiance est typiquement un réseau qui a été configuré comme tel par l'utilisateur U du dispositif client 2, ou selon une configuration par défaut, ou encore qui a été identifié comme tel par exemple en utilisant un mécanisme de vérification d'identité du réseau, etc. Alternativement, un réseau de confiance peut aussi être déterminé dynamiquement en procédant à la validation des assertions du réseau, de façon connue en soi. Le dispositif client 2 est alors configuré pour utiliser, lorsqu'il souhaite accéder au service S via un tel réseau de confiance, un serveur DNS 7 de confiance local (au réseau de confiance), annoncé par le réseau de confiance, par exemple au moyen d'un mécanisme d'annonce tel que décrit dans le document draft-ietf-add-dnr-13 édité par l'IETF et intitulé « DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) », août 2022. Le serveur DNS 7 peut être indifféremment un serveur DNS conforme à l'invention ou un serveur DNS connu de l'état de la technique ne mettant pas en œuvre l'invention.

[0076] L'activation/désactivation du mécanisme AD ASTRA en fonction du niveau de confiance accordé au réseau d'accès utilisé par le dispositif client 2 peut être configurée par défaut au niveau du dispositif client 2 (ce qui permet une activation ou une désactivation automatique du mécanisme en fonction des conditions d'attachement au réseau du dispositif client 2) ou être décidée dynamiquement, par exemple en interrogeant l'utilisateur U du dispositif client 2, via une interface utilisateur prévue à cet effet.

[0077] Les serveurs DNS 3 de confiance appartiennent à une liste L-DNS de serveurs DNS de confiance, configurée par exemple par défaut sur le dispositif client 2 ou définie par l'utilisateur U du dispositif client 2 (par exemple via une interface utilisateur prévue à cet effet). Cette configuration peut avoir été notamment réalisée par l'opérateur du réseau fournissant une connectivité IP au dispositif client 2 (par exemple, son fournisseur d'accès Internet) ou par l'utilisateur U du dispositif client 2. Par souci de simplification, on suppose que la liste L-DNS ne comprend que des serveurs DNS de confiance supportant le mécanisme AD ASTRA. Toutefois, en variante, la liste L-DNS peut également comprendre des serveurs DNS de confiance ne supportant pas ce mécanisme. [0078] Dans l'exemple de la figure 1, les serveurs DNS 3 compris dans la liste L-DNS se trouvent dans le réseau Internet ; bien qu'aucune limitation ne soit attachée à leur localisation à proprement parler, préférentiellement, les serveurs DNS 3 ne sont pas situés dans ou annoncés par un réseau « Un- trusted » (c'est-à-dire par un réseau qui n'est pas un réseau de confiance pour le dispositif client 2). [0079] Il convient de noter qu'il n'existe aucune limitation quant au nombre de serveurs DNS (ou plus généralement de résolution de noms) de confiance tels que spécifiés dans la liste L-DNS, qui peut être supérieur ou égal à 1. Dans le mode de réalisation décrit ici, on suppose que le dispositif client 2 embarque un client DNS référencé par CL (par exemple dans une application telle que son système d'exploitation ou OS pour « Operating System » en anglais, le client DNS CL pouvant être partagé par plusieurs applications), qui choisit selon une stratégie locale prédéfinie (par exemple via une configuration par défaut) le ou les serveurs DNS de confiance à solliciter parmi la liste L-DNS pour chaque résolution de noms de domaine requise lors de l'invocation d'un service tel que par exemple le service S fourni par le serveur distant 5. Cette stratégie locale peut notamment spécifier : un mode de choix persistant selon lequel un même serveur DNS est choisi selon une préférence locale ou sur la base d'informations caractéristiques des capacités des serveurs DNS de la liste L-DNS, et sollicité pendant une durée déterminée ; un mode de choix séquentiel, selon lequel le client DNS CL établit une liste de serveurs candidats L-CAND à partir de la liste L-DNS, qu'il ordonne selon un ou plusieurs critères. Par exemple, la liste L-CAND est établie et ordonnée en fonction d'un schéma de chiffrement supporté le cas échéant par chaque serveur DNS ; un tel schéma de chiffrement est par exemple un schéma de chiffrement DoT, DoD, DoH, DoQ, ou encore DoC tel que cité précédemment. A titre illustratif, la liste L-CAND peut ainsi comprendre tous les serveurs DNS de la liste L-DNS supportant le schéma de chiffrement DoH, suivis de tous les serveurs DNS de la liste L-DNS supportant le schéma de chiffrement DoT. Les serveurs DNS sont alors sollicités par le client DNS CL dans l'ordre de la liste L-CAND ainsi établie. Bien entendu, d'autres critères que les schémas de chiffrement peuvent être envisagés en variante, comme par exemple la localisation des serveurs DNS, leur(s) capacité(s) de traitement, etc. ; un mode de choix aléatoire : un serveur DNS est choisi aléatoirement par le client DNS CL pour toute nouvelle requête de résolution DNS. Ce mode de choix aléatoire peut résulter également en un choix aléatoire du schéma de chiffrement implémenté ; etc.

[0080] Ces exemples de stratégies adoptées par le client DNS CL du dispositif client 2 ne sont donnés qu'à titre illustratif, et d'autres stratégies peuvent être envisagées en variante. En outre, le dispositif client 2 peut embarquer un ou plusieurs clients DNS CL aptes à mettre en œuvre une telle stratégie lorsqu'ils sont activés.

[0081] Dans le mode de réalisation décrit ici, les communications entre le dispositif client 2 (et plus spécifiquement son client DNS CL) et un serveur DNS 3 de confiance, sélectionné par le client DNS CL du dispositif client 2 sont chiffrées. Elles sont par exemple conformes à l'un quelconque des protocoles DoT, DoD, DoH, DoQ, ou DoC. L'utilisation d'un transport DNS chiffré pour transmettre des messages entre le dispositif client 2 et un serveur DNS 3 garantit l'authenticité et l'intégrité de ces messages.

[0082] On suppose par ailleurs, par souci de simplification, que le dispositif client 2 échange directement avec le serveur DNS 3 de confiance, sélectionné par le client DNS CL, sans l'intervention d'un relais (ou « forwarder » en anglais) DNS. Toutefois, l'invention s'applique également en présence d'un forwarder DNS situé entre le dispositif client 2 et le serveur DNS 3 de confiance, sélectionné par le client DNS CL. Plus spécifiquement, si le forwarder DNS est de confiance, le dispositif client 2 lui adresse ses requêtes DNS ; dans ce cas, le forwarder DNS est configuré pour relayer les requêtes DNS du dispositif client 2 vers le serveur DNS 3 sélectionné par le client DNS CL. Si le forwarder DNS n'est pas de confiance, le dispositif client 2 est configuré pour adresser ses requêtes DNS directement au serveur DNS 3 sélectionné par le client DNS CL (et ainsi contourner le forwarder DNS). Ainsi, par souci de simplification dans la suite, la terminologie « requête DNS adressée par un dispositif client » désigne indifféremment une requête DNS provenant directement du dispositif client ou via un forwarder DNS comme cela vient d'être évoqué.

[0083] Conformément à l'invention, lorsque le mécanisme AD ASTRA est activé et un serveur DNS 3 de confiance est sollicité par le dispositif client 2 pour résoudre un nom de domaine associé au service S hébergé par le serveur distant 5, le serveur DNS 3 en question est configuré pour, outre résoudre le nom de domaine en question (directement ou indirectement en sollicitant un autre serveur DNS), sélectionner un ou plusieurs nœuds relais parmi les nœuds relais 4 du système 1 vers le(s)quel(s) orienter le dispositif client 2 pour envoyer ses messages contenant des données destinées au serveur distant 5 (serveur destinataire au sens de l'invention), émises dans le cadre du service S. Les communications entre le dispositif client 2 et le ou les nœuds relais 4 du système 1 sélectionnés, ainsi qu'entre ces nœuds relais 4 et les serveurs DNS 3 les ayant sélectionnés, sont chiffrées dans le mode de réalisation décrit ici, par exemple au moyen du protocole TLS (pour « Transport Layer Security » en anglais), version 1.3, éventuellement combiné à l'utilisation d'une fonction ECH (pour « Encrypted Client Hello »). Bien entendu, cette hypothèse n'est pas limitative en soi et d'autres protocoles et extensions de chiffrement peuvent être envisagés en variante dans le contexte de l'invention.

[0084] Dans le mode de réalisation décrit ici, le dispositif client 2, les serveurs DNS 3 et les nœuds relais 4 ont l'architecture matérielle d'un ordinateur 8 telle que représentée schématiquement dans la figure 2. Cette architecture matérielle s'appuie sur un processeur PROC, une mémoire vive MEM, une mémoire morte ROM, une mémoire non volatile NVM, et des moyens COM de communication permettant à chacun des dispositifs précités de communiquer notamment avec les autres dispositifs du système 1. Ces moyens COM de communication peuvent notamment s'appuyer sur une interface de communication filaire ou sans fil, connue en soi et non décrite en détail ici, et/ou sur une ou plusieurs interfaces logicielles telles qu'une interface de programmation applicative (ou API pour « Application Programming Interface » en anglais) ou une interface de communication point-à-point, etc., et mettre en œuvre un ou plusieurs schémas de chiffrement comme évoqué précédemment.

[0085] La mémoire non volatile NVM (ou en variante la mémoire morte ROM) de l'ordinateur 8 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur PROC, et sur lequel est enregistré un programme d'ordinateur conforme à l'invention.

[0086] Dans le cas d'un serveur DNS 3 conforme à l'invention, ce programme d'ordinateur est référencé par PROG3 et comporte des instructions définissant les principales étapes d'un procédé de traitement d'une (première) requête de résolution de nom selon l'invention. Dans le cas du dispositif client 2 conforme à l'invention, ce programme d'ordinateur est référencé par PROG2 et comporte des instructions définissant les principales étapes d'un procédé de communication selon l'invention. Enfin, dans le cas d'un nœud relais 4 conforme à l'invention, ce programme d'ordinateur est référencé par PROG4 et comporte des instructions définissant les principales étapes d'un procédé de traitement de messages selon l'invention.

[0087] Le programme d'ordinateur PROG3 définit les modules fonctionnels d'un serveur DNS 3 conforme à l'invention, qui s'appuient ou commandent les éléments PROC, MEM, ROM, NVM, et COM de l'ordinateur 8. Dans le mode de réalisation décrit ici, ces modules fonctionnels comprennent notamment comme illustré par la figure 3 : un module 3A de réception, configuré pour recevoir des requêtes REQ-DNS de résolution de noms (requêtes DNS dans l'exemple envisagé ici) envoyées par des dispositifs clients, et notamment par le dispositif client 2 ; un module 3B traitement, configuré pour traiter (autrement dit résoudre) les requêtes REQ-DNS reçues par le module 3A de réception et élaborer des réponses REP-DNS à ces requêtes ; un module 3C de fourniture, configuré pour fournir à chaque dispositif client ayant sollicité le serveur DNS 3, supportant (et incidemment sollicitant) la mise en œuvre du mécanisme AD ASTRA, une pluralité d'éléments AD ASTRA-ELTS en plus des informations classiquement fournies en réponse à une requête REQ-DNS, comme détaillé davantage ultérieurement. Dans le mode de réalisation décrit ici, la pluralité d'éléments AD ASTRA-ELTS est fournie à un dispositif client ayant adressé une requête REQ-DNS au serveur DNS 3 dans la réponse REP-DNS à cette requête, par exemple dans une option EDNS (pour « Extension Mechanisms for DNS » en anglais) comme expliqué plus en détail ultérieurement. Ces hypothèses ne sont toutefois pas limitatives et on peut envisager que la pluralité d'éléments AD ASTRA-ELTS soit fournie au dispositif client à l'aide d'un ou plusieurs messages distincts de la réponse REP-DNS ; et un module 3D d'envoi, configuré pour envoyer aux dispositifs clients ayant sollicité le serveur DNS 3, les réponses REP-DNS élaborées par le module 3B de traitement ainsi que la pluralité d'éléments AD ASTRA-ELTS fournie par le module 3C de fourniture.

[0088] Le module 3B de traitement procède, pour résoudre une requête REQ-DNS reçue d'un dispositif client, de façon conventionnelle en établissant, à partir d'enregistrements RR dont dispose le serveur DNS 3 ou auxquels il peut accéder (via un ou plusieurs autres serveurs DNS organisés de façon hiérarchique), une correspondance entre le nom sur lequel porte la requête REQ-DNS (par exemple, le nom de domaine « service-s.com » permettant d'accéder au service S) et une ressource IP (par exemple une adresse IP) d'un serveur associé à ce nom (le serveur 5 dans l'exemple du nom de domaine « service-s.com »).

[0089] Dans l'exemple envisagé ici, par souci de simplification, on se limite à des enregistrements RR de type A (établissant une correspondance entre un nom et une adresse IPv4 d'un serveur associé à ce nom) et des enregistrements RR de type AAAA (établissant une correspondance entre un nom et une adresse IPv6 d'un serveur associé à ce nom), un serveur associé à un nom pouvant être identifié par une adresse IPv4 et/ou une adresse IPv6 (et donc correspondre à un enregistrement de type A et/ou à un enregistrement de type AAAA). Il convient de noter que l'invention ne se limite toutefois pas à ces deux types d'enregistrements et s'applique également à d'autres types d'enregistrements RR comme des enregistrements RR de type SVCB (pour « Service Binding » en anglais), SRV (pour « Service resource record » en anglais), CNAME, etc., qui peuvent associer à des noms d'autres ressources qu'une adresse IP, comme par exemple un alias, un autre nom, une URI, etc.

[0090] La réponse REP-DNS à la requête REQ-DNS élaborée par le module 3B de traitement comprend ainsi au moins une information contenue dans un enregistrement RR relatif à un serveur (désigné ici par « serveur destinataire ») associé au nom sur lequel porte la requête REQ-DNS, et résultant de la résolution de la requête REQ-DNS par le module 3B de traitement. Dans l'exemple envisagé ici d'enregistrements RR de types A et AAAA, cette information comprend au moins une adresse IP (IPv4 et/ou IPv6) du serveur destinataire.

[0091] Comme évoqué précédemment, cette réponse REP-DNS comprend en outre, dans le mode de réalisation décrit ici, la pluralité d'éléments AD ASTRA-ELTS fournie par le module 3C de fourniture du serveur DNS 3. Cette pluralité d'éléments AD ASTRA-ELTS comprend, conformément à l'invention, au moins les éléments suivants : au moins une adresse IP d'au moins un nœud relais 4 sélectionné par le serveur DNS 3 (par exemple par son module 3C de fourniture) pour le dispositif client 2 et pour le serveur destinataire associé au nom sur lequel porte la requête REQ-DNS (serveur distant 5 dans l'exemple envisagé), auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire. Cette adresse IP peut être éventuellement complétée par un numéro de port à utiliser par le dispositif client pour adresser ses messages au nœud relais 4, si un numéro de port par défaut n'est pas défini. Autrement dit, au lieu d'adresser les messages relatifs au service auquel il souhaite accéder au serveur destinataire identifié dans la réponse REP-DNS, le dispositif client doit adresser ces messages au nœud relais 4 (c'est-à-dire indiquer comme adresse de destination de ces messages l'adresse du nœud relais 4 au lieu de l'adresse du serveur destinataire). Le serveur destinataire auquel sont véritablement destinées les données utiles contenues dans ces messages reste toutefois identifié dans le contenu des messages adressés au nœud relais 4-1 afin qu'il puisse relayer ces données utiles vers le serveur destinataire. Ainsi, dans l'exemple envisagé du service S, si la pluralité d'éléments AD ASTRA- ELTS désigne le nœud relais 4-1, cela signifie que le dispositif client 2 doit adresser les messages contenant des données destinées au serveur distant 5 au nœud relais 4-1. Chaque message adressé au nœud relais 4-1 a pour adresse de destination, l'adresse du nœud relais 4-1 (incluant son adresse IP notée @IP4-1 et un numéro de port P4-1, qui peut être défini par défaut ou avoir été fourni par le serveur DNS 3 avec l'adresse IP du nœud relais 4-1 comme évoqué précédemment), et contient un paquet de données, appelé paquet de données intérieur (ou « inner- packet » en anglais), chiffré au moyen d'un schéma de chiffrement (par exemple, TLS, DTLS). Le paquet de données intérieur contient des données utiles destinées au serveur distant 5, et comme adresse de destination, l'adresse IP du serveur distant 5 et son numéro de port (aussi plus communément désigné par « adresse de transport »). L'adresse du serveur distant 5 est donc masquée par le biais du chiffrement dans le contenu du message adressé au nœud relais 4-1 ; et au moins une instruction INST de brouillage, destinée à être appliquée (autrement dit devant être appliquée) par le dispositif client 2 auxdits messages contenant des données destinées au serveur destinataire avant de les adresser audit au moins un nœud relais 4. Une telle instruction de brouillage peut comprendre par exemple une instruction de bourrage (« padding ») de tout ou partie des messages, et/ou une instruction d'émulation de connexions entre le dispositif client et le nœud relais ou via le nœud relais jusqu'à un serveur dédié en plus de la connexion utilisée pour envoyer les messages contenant les données destinées au serveur destinataire (autrement dit une instruction d'établissement de connexions « fictives » par le dispositif client), comme expliqué davantage ultérieurement.

[0092] La configuration et le fonctionnement des modules 3A à 3D d'un serveur DNS 3 conforme à l'invention sont décrits plus en détail en référence aux étapes du procédé de traitement d'une (première) requête de résolution de nom illustrées par la figure 6.

[0093] Pour ce qui concerne le dispositif client 2, le programme PROG2 stocké dans la mémoire NVM (ou en variante ROM) de l'ordinateur 8 définit les modules fonctionnels du dispositif client 2, qui s'appuient sur ou commandent les éléments PROC, MEM, ROM, NVM, et COM de l'ordinateur 8. Ces modules fonctionnels comprennent notamment, dans le mode de réalisation décrit ici, comme illustré dans la figure 4 : un module 2A d'envoi, embarqué dans le client DNS CL, et configuré pour envoyer à l'un des serveurs DNS 3 de la liste L-DNS choisi par le client DNS CL du dispositif client 2, une requête de résolution de nom REQ-DNS. Dans l'exemple envisagé ici, cette requête REQ-DNS porte sur un nom de domaine et sur un enregistrement RR de type A ou AAAA attaché à ce nom de domaine. Le module 2A d'envoi est activé par le client DNS CL à chaque fois que le dispositif client 2 souhaite accéder à un service, par exemple au service S hébergé par le serveur distant 5 et associé au nom de domaine « service-s.com ». Dans le mode de réalisation décrit ici, la requête REQ-DNS comprend en outre une option EDNS EAO, indiquant au serveur DNS 3 sollicité que le dispositif client 2 supporte (et incidemment sollicite) le mécanisme AD ASTRA. En variante, le support du mécanisme AD ASTRA par le dispositif client 2 peut être signalé au serveur DNS 3 par d'autres moyens (par exemple dans un autre message que dans la requête REQ-DNS, dans une autre option, etc.) ; un module 2B de réception, embarqué dans le client DNS CL, et configuré pour recevoir en provenance du serveur DNS 3 sollicité, la réponse REP-DNS à la requête REQ-DNS élaborée par ce dernier. Cette réponse REP-DNS comprend, comme indiqué précédemment, au moins une information relative à l'enregistrement RR demandé par le dispositif client 2 du serveur destinataire associé au nom sur lequel porte la requête REQ-DNS, par exemple une adresse IP du serveur destinataire. En outre, dans le mode de réalisation décrit ici, la réponse REP-DNS contient la pluralité d'éléments AD ASTRA-ELTS fournie par le serveur DNS 3 conformément au mécanisme AD ASTRA ; un module 2C d'exécution, configuré pour appliquer ladite au moins une instruction de brouillage contenue dans la pluralité d'éléments AD ASTRA-ELTS aux messages contenant des données destinées au serveur destinataire associé au nom sur lequel porte la requête REQ-DNS avant de les adresser à l'un des nœuds relais 4 identifiés dans la pluralité d'éléments AD ASTRA-ELTS ; et un module 2D d'envoi configuré pour envoyer au nœud relais 4 en question les messages brouillés obtenus par le module 2C d'exécution.

[0094] La configuration et le fonctionnement des modules 2A à 2D du dispositif client 2 selon l'invention sont décrits plus en détail en référence aux étapes du procédé de communication illustrées par la figure 7.

[0095] De façon similaire, le programme PROG4 stocké dans la mémoire NVM (ou en variante ROM) de l'ordinateur 8 définit les modules fonctionnels d'un nœud relais 4 conforme à l'invention, ces modules fonctionnels s'appuyant ou commandant les éléments PROC, MEM, ROM, NVM, et COM de l'ordinateur 8. Ils comprennent notamment, dans le mode de réalisation décrit ici, comme illustré par la figure 5 : un module 4A d'acquisition, configuré pour acquérir des informations relatives à au moins une instruction INST de brouillage appliquée par un dispositif client conforme à l'invention tel que le dispositif client 2, pour lequel le nœud relais 4 a été sélectionné, ladite instruction de brouillage INST étant appliquée à des messages contenant des données destinées à un serveur destinataire avant que le dispositif client les adresse au nœud relais 4. L'acquisition des informations relatives à l'instruction INST de brouillage peut se faire par l'intermédiaire du serveur DNS 3 de confiance à l'origine de cette instruction ou par le dispositif client configuré pour l'appliquer ; et un module 4B de traitement, configuré pour : o sur réception d'un tel message, supprimer en utilisant les informations acquises, le brouillage appliqué par le dispositif client au message conformément à l'instruction de brouillage INST ; et o transférer le message obtenu après suppression du brouillage vers le serveur destinataire. Il convient de noter que le nœud relais 4 peut transférer le message obtenu directement au serveur destinataire ou par l'intermédiaire d'un autre nœud relais, dans le cas où plusieurs nœuds relais sont déployés en cascade. La façon dont le module 4B de traitement procède ne présente aucune difficulté pour l'homme du métier et n'est pas décrite plus en détail ici.

[0096] Dans le mode de réalisation décrit ici, le module 4B est en outre configuré pour, sur réception d'un message provenant du serveur destinataire et destiné au dispositif client pour lequel il a été sélectionné (par exemple au dispositif client 2), brouiller ce message et transférer le message brouillé obtenu au dispositif client. Il convient de noter que le module 4B n'applique pas nécessairement dans le sens nœud relais vers dispositif client, le brouillage qui a été appliqué dans le sens dispositif client vers nœud relais (c'est-à-dire les brouillages appliqués dans un sens et dans l'autre ne sont pas nécessairement les mêmes). Le brouillage appliqué dans le sens nœud relais vers dispositif client est par exemple choisi par le serveur DNS 3 de confiance. S'il diffère de celui appliqué dans le sens dispositif client vers nœud relais, le nœud relais 4 en est informé par exemple par le serveur DNS 3 de confiance et reçoit de ce dernier, via son module 4A d'acquisition, une instruction INST' de brouil- lage décrivant le brouillage à appliquer. Alternativement, l'instruction pour l'identification du brouillage est explicitement codée dans le message chiffré et donc communiquée par le dispositif client (resp. le nœud relais).

[0097] La configuration et le fonctionnement des modules 4A et 4B d'un nœud relais 4 selon l'invention sont décrits plus en détail en référence aux étapes du procédé de traitement de messages illustrées par la figure 8.

[0098] Nous allons maintenant décrire, en référence aux figures 6 à 8, les principales étapes des procédés de traitement d'une requête de résolution de nom (figure 6), de communication (figure 7) et de traitement de messages (figure 8) selon l'invention, tels qu'ils sont mis en œuvre respectivement par un serveur DNS 3 (dans l'exemple envisagé ci-après, le serveur DNS 3-1), le dispositif client 2 et un nœud relais 4 (dans l'exemple envisagé ci-après le nœud relais 4-1) conformes à l'invention, dans un mode particulier de réalisation.

[0099] En référence à la figure 7, comme évoqué précédemment, on suppose dans le mode de réalisation décrit ici que le dispositif client 2 est configuré (par exemple, par son fournisseur d'accès Internet ou par son utilisateur) avec une liste L-DNS de serveurs DNS 3 de confiance, conformes à l'invention supportant le mécanisme AD ASTRA.

[0100] De façon connue en soi, lorsqu'un dispositif client tel que le dispositif client 2 souhaite accéder par le biais d'une application installée sur le dispositif client par exemple, à un service hébergé au sein d'un environnement informatique , l'application en question envoie à un serveur DNS une requête DNS portant sur le nom (au sens DNS) de l'environnement informatique afin d'obtenir l'adresse (par exemple une adresse IP) d'un serveur avec lequel échanger pour bénéficier du service.

[0101] On suppose ici que le dispositif client 2 souhaite accéder par le biais d'une application APP au service S associé au nom de domaine « service-s.com » et hébergé par le serveur distant 5.

[0102] Le dispositif client 2 envoie alors, par l'intermédiaire de son module 2A d'envoi, une requête REQ- DNS de résolution du nom de domaine « service-s.com » (première requête au sens de l'invention) à l'un des serveurs DNS 3 de confiance, identifiés dans la liste L-DNS, à savoir ici au serveur DNS 3- 1 (étape E10). Le choix du serveur DNS 3-1 parmi la liste L-DNS résulte d'une stratégie locale appliquée par le dispositif client 2 et qui a été préalablement configurée dans le dispositif client 2, comme évoqué précédemment. On rappelle par ailleurs que les échanges entre le dispositif client 2 et le serveur DNS 3-1 (requêtes DNS et réponses aux requêtes DNS notamment) sont chiffrés, par exemple en utilisant l'un des schémas de chiffrement DoT, DoD, DoH, DoQ, ou encore DoC précédemment cités.

[0103] La requête REQ-DNS, de façon connue en soi, spécifie notamment le nom de domaine « service- s.com » auquel le dispositif client 2 souhaite accéder, ainsi que le type d'enregistrement RR visé par la requête (par exemple ici un enregistrement RR de type A si le dispositif client 2 supporte le protocole IPv4 ou un enregistrement RR de type AAAA si le dispositif client 2 supporte le protocole IPv6). Dans le mode de réalisation décrit ici, la requête REQ-DNS comporte en outre une option EDNS appelée EAO (nouvellement introduite pour les besoins de l'invention), indiquant au serveur DNS 3 sollicité, c'est-à-dire le serveur DNS 3-1, que le dispositif client 2 supporte et sollicite la mise en œuvre du mécanisme AD ASTRA.

[0104] La figure 9A illustre un exemple de format de l'option EAO insérée par le dispositif client 2 dans sa requête REQ-DNS indiquant au serveur DNS 3-1 que le dispositif client 2 supporte et sollicite la mise en œuvre du mécanisme AD ASTRA. Conformément au document RFC 6891 édité par l'IETF et intitulé « Extension Mechanisms for DNS (EDNS(0)) », avril 2013, l'option EAO comprend trois champs OPTION-CODE, OPTION-LENGTH et OPTION-DATA, le champ OPTION-LENGTH indiquant la taille en octets du champ OPTION-DATA.

[0105] Dans l'exemple illustré par la figure 9, le champ OPTION-DATA comprend un paramètre « partial- offload » et un paramètre « AID » (pour « AD ASTRA relay IDentifier » en anglais), ainsi qu'un emplacement réservé ou « reserved » en anglais, permettant au dispositif client 2 de communiquer des capacités dont il dispose en lien avec le mécanisme AD ASTRA ainsi que d'autres informations pouvant être utiles au serveur DNS 3 sollicité. Plus particulièrement : le paramètre « pa rtia l-off load » est utilisé par le dispositif client 2 dans une requête pour indiquer au serveur DNS 3-1 s'il supporte (paramètre valorisé à 1 par exemple) ou non (paramètre valorisé à 0 par exemple) l'envoi d'une première requête de résolution de nom vers le serveur DNS 3-1 (requête REQ-DNS) puis l'envoi de requêtes de résolution de nom ultérieures (deuxièmes requêtes au sens de l'invention, notées REQ'-DNS, REQ"-DNS, etc.), corrélées à la première requête de résolution de nom REQ-DNS, vers un autre serveur de résolution de nom que le serveur DNS 3.1 dont l'information de joignabilité (par exemple son adresse IP) lui est communiquée par le serveur DNS 3-1. Cet autre serveur de résolution de nom peut typiquement être un nœud relais sélectionné par le serveur DNS 3-1 conformément à l'invention. Par « requêtes corrélées », on entend ici qu'il existe un lien entre les deux questions posées dans les deux requêtes, par exemple la première requête porte sur la résolution d'un nom de domaine « parent » (par exemple « service-s.com ») tandis que la deuxième requête porte sur la résolution d'un nom d'un sous-domaine du domaine parent (c'est-à-dire « *. service-s. corn » dans l'exemple envisagé ci-avant où * désigne une chaîne de caractères). Un autre exemple de corrélation est la découverte par le dispositif client 2 de noms (ou de « références » ou encore « referrals » en anglais) nécessitant une résolution lors du traitement de données envoyées par le serveur destinataire résultant de la résolution de la première requête ; la ou les deuxièmes requêtes envoyées pour résoudre ces noms sont corrélées au sens de l'invention à la première requête. La corrélation est établie par le dispositif client 2 dès lors qu'il associe le serveur destinataire comme source des noms. Le paramètre « partial-offload » peut être valorisé à 0 par défaut. Dans la suite de la description, si le paramètre « partial-offload » est valorisé à 1 par le dispositif client 2, on dit que celui-ci supporte la fonction « partial-offload » (fonction de « décharge » de requêtes DNS sur un autre serveur que le serveur DNS 3-1 chargé de traiter la première requête REQ-DNS) ; et le paramètre « AID » est utilisé par le dispositif client 2 pour indiquer s'il utilise déjà, pour des connexions actives, un nœud relais conformément à l'invention, dans le cadre d'une mise en œuvre du mécanisme AD ASTRA pour le service S associé au nom de domaine « service-S.com » hébergé par le serveur 5 (autrement dit pour envoyer des messages contenant des données destinées au serveur 5), et le cas échéant un identifiant de ce nœud relais. Aucune limitation n'est imposée quant à la forme de l'identifiant en question : il peut s'agir d'un alias, d'un nombre, d'un nom de domaine, d'un condensé (ou « hash » en anglais), etc. Le dispositif client 2 peut éventuellement associer cet identifiant à une préférence destinée au serveur DNS 3-1, par exemple « match » s'il souhaite que le serveur DNS 3-1 sélectionne le même nœud relais lors de son traitement de la requête REQ-DNS, ou « not match » pour demander l'utilisation d'un autre nœud relais. Dans le mode de réalisation décrit ici, cette préférence n'est pas nécessairement contraignante pour le serveur DNS 3-1 et peut ne pas être prise en compte par celui-ci. Bien entendu, ceci n'est qu'un choix d'implémentation et on peut en variante envisager que cette préférence du dispositif client 2 soit contraignante pour le serveur DNS 3-1.

[0106] En référence à la figure 6, sur réception de la requête REQ-DNS par son module 3A de réception (étape F10), le serveur DNS 3-1 détermine si cette dernière contient l'option EAO (étape test F20).

[0107] Si la requête REQ-DNS ne contient pas l'option EAO (réponse « non » à l'étape test F20), le serveur DNS 3-1 traite (c'est-à-dire résout) par l'intermédiaire de son module de traitement 3B la requête REQ-DNS de façon conventionnelle et connue de l'homme du métier, à partir des enregistrements RR dont il dispose ou en interrogeant un ou plusieurs autres serveurs DNS comme évoqué précédemment (étape F30), puis envoie sa réponse REP-DNS-0 au dispositif client 2 (étape F40). Cette réponse REP-DNS-0 comprend ici l'adresse IP notée @IP5 du serveur 5 associé au nom de domaine « service-s.com ».

[0108] Si la requête REQ-DNS contient l'option EAO (réponse « oui » à l'étape test F20), comme c'est le cas dans l'exemple envisagé ici, le serveur DNS 3-1 traite (résout) via son module de traitement 3B la requête REQ-DNS de façon conventionnelle et connue de l'homme du métier, à partir des enregistrements RR dont il dispose ou en interrogeant un ou plusieurs autres serveurs DNS (étape F50). Ce traitement est identique à celui réalisé lors de l'étape F30.

[0109] Le module 3B de traitement du serveur DNS 3-1 obtient en résolvant la requête REQ-DNS, l'enregistrement RR du serveur 5 (serveur destinataire au sens de l'invention) associé au nom de domaine « service-s.com » et plus particulièrement son adresse IP @IP5 qui est contenue dans cet enregistrement RR (information relative au serveur destinataire résultant de la résolution de la requête REQ- DNS au sens de l'invention). Il inclut l'adresse @IP5 dans la réponse REP-DNS à la requête REQ- DNS.

[0110] Par ailleurs, conformément à l'invention, le serveur DNS 3-1, supportant le mécanisme AD ASTRA, sélectionne via son module 3C de fourniture au moins un nœud relais 4 pour le serveur destinataire 5 (étape F60). Dans l'exemple envisagé ici, il sélectionne le nœud relais 4-1. Le nœud relais 4-1 ainsi sélectionné est destiné à être utilisé par le dispositif client 2 pour lui adresser les messages qu'il souhaite envoyer au serveur destinataire 5, dans le cadre de son accès au service S (au lieu de les envoyer directement au serveur destinataire 5). Le nœud relais 4-1 est chargé ensuite de relayer ces messages vers le serveur destinataire 5, directement ou par l'intermédiaire d'un autre nœud relais 4 lorsque des nœuds relais sont déployés en cascade.

[0111] Il convient de noter que si la requête REQ-DNS est adressée par le dispositif client 2 à un serveur DNS de confiance ne supportant pas le mécanisme AD ASTRA et en particulier l'option EAO (par exemple lorsque la liste L-DNS comprend à la fois des serveurs DNS de confiance supportant le mécanisme AD ASTRA et des serveurs DNS de confiance ne le supportant pas), alors celui-ci répond au dispositif client 2 en lui envoyant un message d'erreur. Sur réception du message d'erreur, le dispositif client 2 peut solliciter un autre serveur DNS, renvoyer la requête au même serveur mais sans l'option EAO, mettre fin à la communication et générer une notification locale (application, utilisateur, etc.) indiquant l'échec de la tentative de résolution, etc.

[0112] Pour sélectionner un nœud relais 4 pour un serveur destinataire 5 et un dispositif client 2, le module 3C de fourniture du serveur DNS 3-1 peut tenir compte d'un ou de plusieurs critères de sélection. Notamment, le module 3C de fourniture peut sélectionner un nœud relais 4 vérifiant une ou plusieurs conditions parmi les conditions suivantes : empêcher l'établissement d'une corrélation entre le nœud relais 4 sélectionné et le serveur destinataire. Typiquement, le module 3C de fourniture doit éviter qu'un nœud relais 4 ne soit sélectionné que pour un unique serveur destinataire, ou pour des communications distinctes entre le dispositif client 2 et le serveur destinataire, il peut sélectionner des nœuds relais 4 différents ; maximiser le nombre de dispositifs clients utilisant un nœud relais 4 sélectionné ; optimiser les dispositifs clients utilisant un nœud relais 4 sélectionné en fonction d'au moins un critère donné, comme par exemple des considérations de charge, des considérations géographiques, etc. ; disposer (déjà) d'une route depuis le nœud relais 4 sélectionné vers le serveur destinataire. Cette information peut être obtenue par le module 3C de fourniture en interrogeant les nœuds relais 4 du système 1 pour obtenir les tables de routage maintenues par ces derniers ; etc.

[0113] Dans un autre mode de réalisation, le module 3C de fourniture du serveur DNS 3-1 peut sélectionner de façon aléatoire un nœud relais 4 parmi une liste de nœuds relais avec laquelle il a été préalablement configuré. [0114] Par ailleurs, comme évoqué précédemment, le serveur DNS 3-1 peut également sélectionner une pluralité de nœuds relais en appliquant les critères évoqués précédemment, chaque nœud relais étant destiné à être utilisé par le dispositif client 2 pendant une durée déterminée (par exemple, la durée d'une connexion).

[0115] En outre, si l'option EAO de la requête REQ-DNS comprend un identifiant AID d'un nœud relais précédemment sélectionné pour le dispositif client 2 et le serveur destinataire 5 associé au service S, le serveur DNS 3-1 peut tenir compte de cet identifiant AID lors de la sélection du nœud relais (et le cas échéant de la préférence associée à cet identifiant AID indiquée par le dispositif client 2). Par exemple, si le dispositif client 2 a inséré dans l'option EAO un identifiant AID d'un nœud relais 4, le serveur DNS 3-1 peut sélectionner un nœud relais 4 de façon à éviter d'associer un même nœud relais avec un même serveur destinataire pour ce dispositif client 2, de sorte à minimiser le risque de traçage des communications DNS du dispositif client 2 par une entité malveillante (une telle entité éprouverait en effet une grande difficulté alors à établir une corrélation entre le serveur destinataire et l'identifiant du nœud relais). En variante, il peut décider de sélectionner un nœud relais coïncidant avec celui identifié dans l'identifiant AID de la requête REQ-DNS.

[0116] Il convient toutefois de noter qu'en fonction de sa configuration, le serveur DNS 3-1 peut ignorer les indications fournies par le dispositif client 2 dans le paramètre « AID » de l'option EAO de la requête REQ-DNS.

[0117] Suite à la sélection d'au moins un nœud relais 4 (le nœud relais 4-1 dans l'exemple illustratif envisagé), le module 3C de fourniture insère, dans une option EDNS EAO de la réponse REP-DNS à la requête REQ-DNS, une adresse du (ou des) nœud(s) relais sélection né(s) (étape F70). Dans le mode de réalisation décrit ici, cette adresse est une adresse IP (adresse IPv4 ou adresse IPv6). Elle fait partie de la pluralité d'éléments AD ASTRA-ELTS fournie par le module 3C de fourniture au dispositif client 2.

[0118] En variante, on peut envisager de fournir un nom de domaine associé à chaque nœud relais sélectionné comme adresse de joignabilité, au lieu d'une adresse IP. L'utilisation d'une adresse IP présente l'avantage de ne pas nécessiter de résolution de nom supplémentaire (ce qui permet au dispositif client 2 d'accéder plus rapidement au service S).

[0119] Dans une autre variante encore, l'adresse insérée par le module 3C de fourniture est une adresse de transport du nœud relais 4 et comprend une adresse IP du nœud relais 4 ainsi qu'un numéro de port à utiliser.

[0120] La figure 9B illustre un exemple de format de l'option EAO insérée par le serveur DNS 3-1 dans sa réponse REP-DNS (qui fait écho à l'option EAO insérée par le dispositif client 2 dans sa requête REQ- DNS). Comme représenté sur cette figure, le champ OPTION-DATA de l'option EAO comprend plusieurs paramètres, dont notamment un paramètre « relay-locators », dans lequel l'adresse IP du nœud relais 4-1 sélectionné (ou les adresses IP des nœuds relais sélectionnés) est (sont) insérée(s). [0121] Par ailleurs, conformément à l'invention, le module 3C de fourniture insère également dans l'option EAO de la réponse REP-DNS, dans la pluralité d'éléments AD ASTRA-ELTS qu'il fournit au dispositif client 2, au moins une instruction de brouillage INST devant être appliquée par celui-ci aux messages qu'il va adresser au nœud relais 4-1 et qui sont destinés au serveur destinataire.

[0122] Dans le mode de réalisation décrit ici, l'instruction de brouillage INST consiste en une instruction de bourrage (ou encore de remplissage ou de « padding ») des messages envoyés par le dispositif client 2 avant leur envoi au nœud relais 4-1. Elle est insérée dans un paramètre « padding » du champ OPTION-DATA de l'option EAO, comme illustré sur la figure 9. Cette instruction de bourrage est une instruction de compléter les messages destinés au serveur destinataire que le dispositif client 2 envoie au nœud relais 4-1 de sorte à homogénéiser leurs tailles. Le ou les motifs de bourrage appliqués par le dispositif client 2, notés PATT, sont choisis par exemple de sorte à rendre uniforme le gabarit des messages envoyés par plusieurs dispositifs clients. Ceci permet avantageusement de renforcer davantage l'anonymat des communications des dispositifs clients en question.

[0123] L'instruction de bourrage insérée dans le paramètre « padding » par le module 3C de fourniture peut prendre plusieurs formes. Elle peut comprendre une technique de génération à utiliser par le dispositif client 2 pour générer un ou plusieurs motifs PATT de bourrage. Une telle technique peut s'appuyer par exemple sur une technique d'apprentissage par renforcement (ou « Reinforcement Learning » en anglais) permettant au dispositif client 2 de déterminer les motifs de bourrage à appliquer et de les ajuster dans le temps si besoin.

[0124] En variante, une telle technique de génération peut être appliquée directement par le module 3C de fourniture du serveur DNS 3-1, et l'instruction de bourrage insérée dans le paramètre « padding » consigner le ou les motifs PATT de bourrage, générés par le module 3C de fourniture au moyen de cette technique de génération.

[0125] Dans le mode de réalisation décrit ici, le module 3C de fourniture notifie en outre le nœud relais 4-1 sélectionné pour le dispositif client 2 et le serveur destinataire 5, du contenu de l'instruction de bourrage (et plus particulièrement du ou des motifs PATT de bourrage ou de la technique de génération de tels motifs) qu'il demande au dispositif client 2 d'appliquer aux messages destinés au serveur destinataire 5 qu'il va envoyer au nœud relais 4-1 (étape F80).

[0126] Cette notification du nœud relais 4-1 par le serveur DNS 3-1 lui permet d'acquérir des informations relatives à ou au(x) instructions de brouillage ordonnées par le serveur DNS 3-1 au dispositif client 2 et d'être ainsi en mesure de traiter les messages en provenance du dispositif client 2 contenant des données destinées au serveur destinataire 5 avant de les relayer vers le serveur destinataire 5.

[0127] En variante, le nœud relais 4-1 peut acquérir de telles informations du dispositif client 2 lui-même. Par exemple dans le cas d'une instruction de bourrage, le dispositif client 2 peut notifier le nœud relais 4-1 en insérant dans ses messages contenant des données destinées au serveur destinataire 5 et adressés au nœud relais 4-1, des indicateurs délimitant ou identifiant les motifs de bourrage appliqués.

[0128] Dans un autre mode de réalisation, l'instruction de brouillage INST peut comprendre une instruction d'établissement par le dispositif client 2 d'une ou de plusieurs connexions fictives avec le nœud relais 4-1 et/ou via le nœud relais 4-1 (avec un ou plusieurs serveurs dédiés), en plus de sa connexion « principale » établie avec le nœud relais 4-1 pour transmettre des données au serveur destinataire 5 dans le cadre de l'accès au service S par le dispositif client 2. Le dispositif client 2 utilise alors ces connexions fictives pour transmettre des données « fictives » au nœud relais 4-1 et/ou au(x) serveurs) dédié(s), autrement dit, des données qui ne sont pas à proprement parler destinées à être exploitées (« consommées ») par le nœud relais 4-1 et/ou par le(s) serveur(s) dédié(s), mais qui ont uniquement vocation à brouiller les données destinées au serveur destinataire 5. Cette instruction d'établissement de connexions fictives peut être insérée dans un paramètre idoine du champ OPTION-DATA de l'option EAO, et être notifiée au nœud relais 4-1 comme décrit précédemment pour l'instruction de bourrage.

[0129] Bien entendu, d'autres instructions de brouillage peuvent être transmises par le serveur DNS 3-1 au dispositif client 2 dans le but d'introduire un bruit autour de la connexion du dispositif client 2 avec le serveur destinataire (serveur distant 5 dans l'exemple envisagé ici) et de rendre difficilement exploitables les informations interceptées par une entité malveillante placée sur le chemin de cette connexion. Elles sont notifiées également au nœud relais 4-1 afin qu'il puisse en tenir compte lors de la réception de messages brouillés en provenance du dispositif client 2.

[0130] Dans le mode de réalisation décrit ici, le module 3C de fourniture du serveur DNS 3-1 fournit deux autres éléments dans la pluralité d'éléments AD ASTRA-ELTS insérée dans l'option EAO de la réponse REP-DNS, à savoir : un paramètre « AID », dans lequel le module 3C de fourniture du serveur DNS 3-1 renseigne un identifiant du nœud relais 4-1 dont l'adresse figure dans le paramètre « relay-locators », et qu'il a sélectionné pour le nom de domaine « service-s.com » et le serveur destinataire 5. Si plusieurs nœuds relais sont sélectionnés, le paramètre « AID » comprend les identifiants de chacun des nœuds relais sélectionnés. Comme indiqué précédemment, aucune limitation n'est attachée à la forme de l'identifiant en question : il peut s'agir d'un alias, d'un nombre, d'un nom de domaine, d'un condensé (ou « hash » en anglais), etc. ; un paramètre « partial-offload » : si le dispositif client 2 a indiqué dans le paramètre « partial- offload » de l'option EAO de la requête REQ-DNS, le support de la fonction partial-offload, le serveur DNS 3-1 indique dans le paramètre « partial-offload » de l'option EAO de sa réponse REQ-DNS si le nœud relais qu'il a sélectionné (nœud relais 4-1) peut prendre en charge les échanges DNS ultérieurs du dispositif client 2 corrélés à la requête REQ-DNS (c'est-à-dire les « deuxièmes » requêtes au sens de l'invention), autrement dit s'il supporte la fonction partial- offload. Le module 3C de fourniture peut de façon optionnelle ajouter dans le paramètre « partial-offload » une indication supplémentaire identifiant les requêtes DNS concernées par la fonction partial-offload (par exemple, les requêtes portant sur un sous-domaine particulier ou tout autre filtre tel que l'origine des ressources DNS (noms de domaine (par ex. « ser- vice.example.com », service (SRV, par ex. "service._tcp.example.com"), etc.) à soumettre au système DNS). A titre illustratif, dans l'exemple envisagé ici d'une requête REQ-DNS portant sur le nom de domaine « service-s.com », le support de la fonction « partial-offload » par le nœud relais 4-1 indique au dispositif client 2 qu'il peut envoyer toutes ses requêtes ultérieures portant sur un sous-domaine « *.service-s.com » vers le nœud relais 4-1. Il convient de noter que le support de la fonction partial-offload par le nœud relais 4-1 n'implique pas nécessairement que les requêtes DNS ultérieures envoyées par le dispositif client 2 soient traitées (c'est-à-dire résolues) directement par le nœud relais 4-1. Celui-ci peut en effet être configuré pour adresser ces requêtes à un autre serveur DNS de confiance capable de les résoudre.

[0131] Les différents éléments indiqués par le serveur DNS 3-1 dans les paramètres « relay-locators », « AID » et « partial-offload » constituent comme évoqué précédemment une pluralité d'éléments AD ASTRA-ELTS fournie par le module 3C de fourniture du serveur DNS 3-1 au dispositif client 2. Dans le mode de réalisation décrit ici, cette pluralité d'éléments est fournie dans la réponse REP-DNS à la requête REQ-DNS, dans une option EAO. En variante, tout ou partie de cette pluralité d'éléments peut être fournie dans un ou plusieurs options ou messages distincts de la réponse REP-DNS.

[0132] La réponse REP-DNS incluant l'option EAO est ensuite envoyée par le module 3D d'envoi du serveur DNS 3-1 au dispositif client 2 (étape F90).

[0133] En référence à la figure 7 de nouveau, le dispositif client 2, et plus particulièrement son module 2B de réception, reçoit la réponse REP-DNS élaborée par le serveur DNS 3-1 à sa requête REQ-DNS (étape E20).

[0134] Le dispositif client 2 extrait de l'option EAO la pluralité d'éléments AD ASTRA-ELTS présents dans la réponse REP-DNS, et plus particulièrement les éléments compris dans les paramètres « relay-locators », « padding », « AID » et « partial-offload » de l'option (étape E30). Pour rappel, l'utilisation d'un transport DNS chiffré pour transmettre ces paramètres garantit avantageusement l'authenticité et l'intégrité des messages véhiculant ces paramètres, et donc incidemment, des paramètres reçus par le dispositif client 2.

[0135] L'identifiant AID est enregistré par le module 2B de réception dans un cache local du client DNS CL du dispositif client 2, en association avec la ressource IP correspondante, à savoir ici le nom de domaine « service-s.com ». Si une entrée est déjà présente dans le cache pour cette même ressource, le client DNS CL remplace son contenu par le nouvel AID renseigné dans la réponse REP-DNS. Lors de l'envoi de requêtes DNS ultérieures corrélées à la requête REQ-DNS, le client DNS CL renseigne le paramètre « AID » de l'option EAO de ces requêtes DNS ultérieures avec le contenu courant du cache local. [0136] Si le dispositif client 2 supporte la fonction partial-offload (comme c'est le cas dans l'exemple envisagé ici), le module 2B de réception enregistre également dans le cache local du client DNS CL les informations transmises dans le paramètre « partial-offload », à savoir que tout ou partie des nœuds relais indiqués dans le paramètre « relay-locators » peuvent être utilisés pour des requêtes DNS ultérieures corrélées à la première requête REQ-DNS ainsi que, le cas échéant, les indications supplémentaires fournies par le serveur DNS 3-1 et identifiant les requêtes DNS ultérieures concernées (étape E50). Il convient de noter que dans le mode de réalisation décrit ici, le paramètre « partial- offload » est renseigné par le serveur DNS 3-1 dans l'option EAO de la réponse REQ-DNS uniquement si le dispositif client 2 supporte la fonction partial-offload et l'a notifié au serveur DNS 3-1 en valorisant le paramètre « partial-offload » de la requête REQ-DNS à 1.

[0137] L'instruction de brouillage INST comprise dans le paramètre « padding » (instruction de bourrage des messages ici) est transmise par le module 2B de réception à l'application APP du dispositif client 2 à l'origine de la requête REQ-DNS de résolution du nom de domaine « service-s.com », afin qu'elle puisse exécuter (c'est-à-dire appliquer) cette instruction avant d'envoyer des messages destinés au serveur destinataire 5 au nœud relais 4-1 indiqué dans le paramètre « relay-locators » (étape E60). A cet effet, l'application APP comprend un module 2C d'exécution selon l'invention. Il convient de noter que l'ensemble des modules 2A à 2D du dispositif client 2 peuvent être hébergés dans l'application APP.

[0138] Comme illustré schématiquement par la figure 10, les messages destinés au serveur destinataire 5 contiennent des données utiles DATA échangées par l'application APP avec le serveur destinataire 5 lors de l'accès au service S. Comme évoqué succinctement précédemment, ces données sont chiffrées au moyen d'un premier mécanisme de chiffrement ENC1 selon les besoins du service S offert par le serveur destinataire 5, et consignées dans des paquets de données intérieurs notés I-PKT (« inner packets » en anglais). Chaque paquet de données intérieur I-PKT est destiné au serveur destinataire 5, c'est-à-dire qu'il a comme adresse de destination (contenue dans un entête du paquet IP I-PKT référencé par DEST dans la figure 10), l'adresse IP @IP5 du serveur destinataire 5 et le numéro de port P5 du serveur destinataire 5. Ce numéro de port est par exemple ici un numéro de port défini par défaut (en variante il peut avoir été obtenu lors de la résolution du nom de domaine associé au serveur destinataire 5, de façon connue en soi). Le paquet de données intérieur I-PKT constitue un paquet de données destinées au serveur destinataire au sens de l'invention. L'application APP applique alors, par le biais de son module 2C d'exécution, l'instruction de brouillage INST consignée dans les éléments AD ASTRA-ELTS, à chaque paquet de données intérieur I-PKT contenant des données destinées au serveur destinataire 5 (étape E60). Comme évoqué précédemment et illustré dans la figure 10, dans le mode de réalisation décrit ici, l'instruction de brouillage INST est une instruction de bourrage comprenant au moins un motif PATT de bourrage ou une technique de génération d'un tel motif PATT. Il en résulte que l'application APP ajoute des bits ou symboles de bourrage conformément au(x) motif(s) PATT de bourrage indiqué(s) dans l'instruction de bourrage INST ou généré(s) par le module 2C d'exécution en appliquant la technique de génération indiquée dans l'instruction de bourrage INST. L'application APP obtient ainsi un paquet de données B-PKT dit brouillé, constitué du paquet de données intérieur I-PKT complété par les bits ou symboles de bourrage du ou des motifs PATT de bourrage appliqué.

[0139] Il convient de noter que dans l'exemple illustré par la figure 10, le motif de bourrage PATT est inséré à la suite des données DATA. Cette hypothèse n'est toutefois pas limitative en soi ; le motif de bourrage PATT peut être inséré à d'autres endroits, ou être fragmenté et intercalé au milieu des données DATA.

[0140] Dans le mode de réalisation décrit ici, le paquet de données brouillé B-PKT est ensuite chiffré (conformément au schéma de chiffrement appliqué le cas échéant entre le dispositif client 2 et le nœud relais 4-1, référencé par ENC2 dans la figure 10), puis inséré par le module 2C d'exécution dans un message B-M dont l'adresse de destination comprend l'adresse IP du nœud relais 4-1 notée @IP4-1 (ou de l'un des nœuds relais 4 renseignés dans le paramètre « relay-locators ») fournie par la pluralité d'éléments AD ASTRA-ELTS, ainsi que son numéro de port P4-1. Ce numéro de port peut être un numéro de port défini par défaut, ou en variante avoir été consigné avec l'adresse @IP4-1 dans la pluralité d'éléments AD ASTRA-ELTS. Le message B-M obtenu, qui contient ici les données utiles DATA destinées au serveur destinataire 5, l'adresse IP @IP5 du serveur destinataire 5 et son numéro de port P5 (désignés communément par adresse de transport du serveur destinataire 5), et le motif de bourrage PATT, informations qui sont toutes sous forme chiffrée, est un message brouillé au sens de l'invention contenant des données destinées au serveur destinataire 5 mais adressées au nœud relais 4-1. Chaque message brouillé B-M obtenu par le module 2C d'exécution est ensuite envoyé par le module 2D d'envoi du dispositif client 2 au nœud relais 4-1 (étape E70).

[0141] On note que la figure 10 ne représente que partiellement le message brouillé B-M, et n'est fournie qu'à titre illustratif pour une meilleure compréhension de l'invention. Un tel message comprend bien entendu d'autres éléments, tels qu'une adresse IP et un numéro de port sources (qui peuvent également être chiffrés), etc.

[0142] En variante, comme évoqué précédemment, l'instruction INST de brouillage peut comprendre une instruction d'établissement de connexion(s) fictive(s) par le dispositif client 2 avec ou via le nœud relais 4-1 pour brouiller les messages contenant des données destinées au serveur destinataire 5 adressés au nœud relais 4-1. Selon cette variante, le module 2C d'exécution procède comme décrit précédemment : il insère dans un message M, sous forme chiffrée (au moyen du mécanisme de chiffrement ENC2), un paquet de données intérieur I-PKT ayant comme adresse de destination l'adresse @IP5 du serveur destinataire 5, et comprenant sous forme chiffrée au moyen du mécanisme de chiffrement ENC1 les données utiles DATA destinées au serveur destinataire 5 (pas d'ajout de motif(s) de bourrage sauf si l'instruction INST de brouillage contient également une instruction de bourrage en plus de l'instruction). Le message M a pour adresse de destination, l'adresse de transport du nœud relais comprenant son adresse IP @IP4-1 et son numéro de port P4-1.

[0143] Le message M ainsi formé est envoyé au nœud relais 4-1 par le module 2D d'envoi du dispositif client 2 sur la connexion principale établie par le dispositif client 2 avec le nœud relais 4-1 de façon connue en soi. Dans cette variante de réalisation, le module 2C d'exécution du dispositif client 2 établit en outre, en plus de la connexion principale utilisée pour adresser le message M au nœud relais 4-1, une ou plusieurs autres connexions fictives avec le nœud relais 4-1 et/ou via ce nœud relais 4-1 avec un ou plusieurs serveurs dédiés, conformément à l'instruction INST. Il envoie sur ces connexions fictives, simultanément à l'envoi du message M sur la connexion principale, des messages F-M contenant des données fictives, c'est-à-dire des données qui ne sont pas destinées à être consommées ou à être exploitées à proprement parler par le nœud relais 4-1 et/ou par les serveurs dédiés. Ces données fictives sont par exemple générées aléatoirement par le module 2C d'exécution.

[0144] Les connexions fictives ainsi émulées par le module 2C d'exécution viennent avantageusement s'ajouter à la connexion principale établie entre le dispositif client 2 et le nœud relais 4-1. Une entité tierce malveillante n'est donc pas en mesure de distinguer le message comprenant des données utile M destinées au serveur destinataire 5 des messages fictifs F-M envoyés simultanément sur les connexions fictives. Les connexions fictives établies par le dispositif client 2 viennent de ce fait par l'intermédiaire des messages fictifs F-M envoyés au nœud relais 4-1 ou via le nœud relais 4-1 en même temps que le message M « brouiller » le message M (que l'on désigne dans la suite par message brouillé B-M comme dans la variante précédente).

[0145] En référence à la figure 8, le nœud relais 4-1 reçoit via son module 4A de réception chaque message brouillé B-M envoyé par le dispositif client 2 (étape G 10).

[0146] Le nœud 4-1 déchiffre chaque message brouillé B-M reçu, puis supprime par l'intermédiaire de son module 4B de traitement le brouillage introduit par le module 2C d'exécution du dispositif client 2 (étape G20). Dans le mode de réalisation décrit ici, le brouillage introduit par le dispositif client 2 est un bourrage des paquets de données intérieurs émis par l'application APP au moyen d'au moins un motif PATT de bourrage fourni dans l'instruction INST ou généré à partir d'une technique de génération consignée dans cette instruction. Ce ou ces motifs PATT de bourrage ou la technique de génération permettant de les générer ont par ailleurs été transmis par le serveur DNS 3-1 au nœud relais 4-1 lors de l'étape de notification F80/étape G00. L'obtention de ce ou ces motifs PATT de bourrage ou de la technique permettant de les générer constitue en soi une étape d'acquisition d'informations relatives à l'instruction de brouillage INST appliquée par le dispositif client 2 au sens de l'invention.

[0147] On peut bien entendu envisager d'autres façons pour le nœud relais 4-1 d'acquérir des informations représentatives de l'instruction de brouillage INST appliquée par le dispositif client 2. Par exemple, le motif de brouillage peut être indiqué explicitement par le dispositif client dans le paquet brouillé lui-même, comme évoqué précédemment.

[0148] Ainsi, dans le mode de réalisation décrit ici, la suppression du brouillage introduit par le module 2C d'exécution du dispositif client 2 consiste pour le module 4B de traitement à retirer les bits/symboles de bourrage correspondant au(x) motif(s) PATT de bourrage qu'il a reçus du serveur DNS 3-1 ou générés à partir de la technique de génération reçue du serveur DNS 3-1. Il obtient ainsi les paquets de données intérieurs I-PKT destinés au serveur destinataire 5.

[0149] Dans la variante où l'instruction de brouillage INST comprend une instruction d'établissement de connexions fictives, le module 4B de traitement peut terminer localement les connexions fictives établies avec lui (ou relayer les messages F-M vers le(s) serveur(s) dédié(s) le cas échéant) et extraire le paquet de données intérieur I-PKT du message M reçu sur la connexion principale après déchiffrement du paquet.

[0150] Comme illustré schématiquement par la figure 11, le module 4B de traitement remplace dans chaque paquet de données intérieur I-PKT obtenu l'adresse IP et le numéro de port sources du dispositif client 2 (notés respectivement sur la figure @IP2 et P2) à l'origine du paquet de données intérieur I-PKT par son adresse IP et son numéro de port source externes (ou tout autre identifiant utilisé par le protocole de transport tel que par exemple les identifiants int-VTag ou rem-VTag pour le protocole SCTP), notés respectivement @IP4-l_e et P4-l_e. Il stocke le numéro de port P2 et l'adresse IP @IP2 sources du dispositif client 2 dans une table locale, dans sa mémoire non volatile NVM. Puis il transfère le paquet de données obtenu au serveur destinataire 5, de façon connue en soi (étape G30). Par souci de simplification, on considère ici que le paquet de données obtenu est transféré directement au serveur destinataire 5 (sans intermédiaire entre le nœud relais 4-1 et le serveur destinataire 5). Toutefois, cette hypothèse n'est pas limitative en soi, et l'invention s'applique également au transfert du paquet de données vers le serveur destinataire 5 par l'intermédiaire d'un ou de plusieurs autres nœuds relais.

[0151] De même, par souci de simplification on a considéré ici le même numéro de port P2 pour le dispositif client pour le message B-M et pour le paquet de données intérieur I-PKT. Toutefois, des numéros de port différents peuvent être utilisés par le dispositif client 2.

[0152] Dans un mode particulier de réalisation, le nœud relais 4-1 ajoute un brouillage avant de transférer le paquet de données I-PKT au serveur destinataire 5. Il peut notamment à cet effet, comme décrit précédemment pour le dispositif client 2, établir des connexions fictives avec des serveurs dédiés, ou avec d'autres (« vrais ») serveurs. Ce brouillage introduit entre le nœud relais 4-1 et le serveur destinataire 5 présente un avantage particulier notamment lorsque le nombre de dispositifs clients utilisant un même nœud relais 4 est inférieur à un seuil donné.

[0153] On suppose ici que le serveur destinataire 5 répond à au moins l'un des paquets de données I-PKT reçus du dispositif client 2 via le nœud relais 4-1, au moyen d'un paquet de données dit « retour » et noté R-PKT, les données utiles contenues dans ce paquet retour étant chiffrées selon les besoins du service S au moyen du mécanisme de chiffrement ENC1.

[0154] Conformément au numéro de port et à l'adresse IP sources indiqués dans les paquets de données intérieurs I-PKT reçus du nœud relais 4-1, le paquet de données retour R-PKT est envoyé par le serveur destinataire 5 au nœud relais 4-1. Sur réception de ce paquet retour R-PKT par le nœud relais 4-1 (étape G40), le module 4C de traitement remplace son numéro de port P4-l_e et son adresse IP @IP4-1 e externes dans l'adresse de destination du paquet de données retour R-PKT par le numéro de port P2 et l'adresse IP @IP2 du dispositif client 2. Par ailleurs, il brouille le paquet de données retour R-PKT ainsi modifié en lui appliquant ici le même type de brouillage que celui appliqué par le dispositif client 2 conformément à l'instruction de brouillage INST. Dans l'exemple envisagé ici, le module 4C de traitement applique ainsi le ou les motifs PATT de brouillage, notifiés par le serveur DNS 3-1 lors des étapes F80/G00 (ou générés à partir de la technique de génération fournie par le serveur DNS 3-1) (étape G50), puis chiffre le paquet de données retour brouillé obtenu dans son intégralité (c'est-à-dire incluant ses entêtes) conformément au schéma de chiffrement ENC2 utilisé entre le nœud relais 4-1 et le dispositif client 2. Le module 4C de traitement insère le paquet de données retour brouillé chiffré ainsi obtenu dans un message retour dont l'adresse de destination est l'adresse IP du dispositif client 2 (extraite de la table locale du nœud relais 4-1). Le message retour brouillé B-MR obtenu est ensuite transféré par le nœud relais 4-1 au dispositif client 2 (étape G60).

[0155] Dans une variante de réalisation (non illustrée sur la figure 11), le module 4C de traitement remplace également dans le paquet de données retour R-PKT le numéro de port P5 et l'adresse IP @IP5 sources du serveur destinataire 5 par son numéro de port P4-1 et son adresse IP @IP4-1 (que l'on peut qualifier d' « internes » par rapport au numéro de port P4-l_e et l'adresse IP @4-l_e externes visibles du serveur destinataire 5), avant de le brouiller et de le chiffrer.

[0156] Sur réception du message retour brouillé B-MR par le dispositif client 2 (étape E80), celui-ci le déchiffre, puis supprime le brouillage introduit par le nœud relais 4-1 (en enlevant les bits/symboles ajoutés conformément au(x) motif(s) PATT de bourrage) et accède au paquet de données retour R- PKT émis par le serveur destinataire 5 (étape E90).

[0157] Bien entendu, d'autres paquets de données intérieurs et retours peuvent être échangés de façon similaire ou identique entre le dispositif client 2 et le serveur destinataire 5 via le nœud relais 4-1 ou via un autre nœud relais 4 désigné par le serveur DNS 3-1 pour le dispositif client 2 et le serveur destinataire 5 et renseignés dans le paramètre « relay-locators » de la réponse REP-DNS.

[0158] On suppose maintenant qu'une nouvelle requête REQ'-DNS de résolution de nom est envoyée dans le cadre de l'accès au service S par le dispositif client 2, et que cette nouvelle requête REQ'-DNS est corrélée à la requête REQ-DNS précédemment envoyée (par exemple elle porte sur la résolution du nom d'un sous-domaine du domaine sur laquelle porte la requête REQ-DNS).

[0159] Si le dispositif client 2 supporte la fonction partial-offload (paramètre « partial-offload » valorisé à 1 dans la requête REQ-DNS), et que le serveur DNS 3-1 a indiqué dans le paramètre « partial-offload » de sa réponse REQ-DNS le nœud relais 4-1, alors le dispositif client 2 adresse la nouvelle requête REQ'-DNS au nœud relais 4-1 directement, comme illustré par la figure 12A. Il en est de même pour toutes les requêtes ultérieures de résolution de nom (REQ"-DNS, etc.) connectées à la requête REQ-DNS. On note que la résolution des requêtes ultérieures peut résulter en un serveur destinataire 5' différent du serveur destinataire 5, comme illustré par la figure 12A.

[0160] Si le dispositif client 2 ne supporte pas la fonction partial-offload (paramètre « partial-offload » valorisé à 0 dans la requête REQ-DNS), le dispositif client 2 continue d'utiliser le serveur DNS 3-1, comme illustré par la figure 12B. Il en est de même si la nouvelle requête DNS REQ'-DNS n'est pas corrélée à la requête REQ-DNS, y compris lorsque le dispositif client 2 supporte la fonction partial- offload.

[0161] Dans le mode de réalisation décrit ici, on a considéré des échanges DNS entre le dispositif client 2, le ou les serveurs DNS 3 et les nœuds relais 4. L'invention s'applique toutefois à tout type de noms à résoudre, quel que soit le format, et pas uniquement à un nom de domaine tel que défini par le document RFC 1034. Ainsi, tout ce qui a été décrit précédemment en référence à un nom de domaine s'applique à la résolution d'un nom quelconque d'une ressource IP.