Method for name resolution, communication, message processing, and corresponding server, client device and relay node

Abstract

The method according to the invention for processing a first name resolution request (REQ-DNS) originating from a client device (2) is implemented by a name resolution server (3-1). The method comprises sending a response to the client device (2) to the first request, the response comprising at least one piece of information relating to the so-called recipient server (5) generated by parsing the first request. The method further comprises sending to the client device (2) a plurality of elements comprising:-at least one address of at least one relay node (4-1) selected by the name resolution server (3-1) to which the client device must address all or part of a message containing data intended for the recipient server; and-at least one scrambling instruction to be applied to the messages by the client device prior to addressing the messages to the at least one relay node.

Description

Technical Field

[0001] The present invention belongs to the general field of telecommunications.

[0002] The invention more particularly relates to communication with a Domain Name Resolution Server (or DNS, for Domain Name System) in a telecommunication network, such as for example an IP (Internet Protocol) network. Background Art

[0003] The DNS system is a basic component for providing IP services. In fact, it enables resources (such as domain names, uniform resource identifiers (URIs), etc.) to be associated with one or more IP addresses that allow devices (such as, for example, terminals) to access the resources.

[0004] For example, a server reachable by IPv4 publishes DNS "A" records (or resource records RR) to the DNS system, while a server reachable by IPv6 publishes DNS "AAAA" records (or quadruple A resource records); a server reachable by both IPv4 and IPv6 publishes both types of records.

[0005] When a device wishes to establish communication with a server identified by a domain name (or fully qualified domain name FQDN), called a "receiving" server, the DNS client embedded in the device sends a domain name resolution request (called a DNS request) to the server of the DNS system (or simply referred to as a DNS server), specifying the desired record type (A or AAAA) in the request. Devices that support both IPv4 and IPv6 protocols send two DNS queries to the DNS server (one indicating an A record and the other indicating an AAAA record).

[0006] Upon receiving the request, if an entry corresponding to the domain name to which the request relates is available, the DNS server responds to the device by sending at least one IP address associated with the domain name to the device. If no such entry is available, the DNS server relays the request to another server in accordance with the DNS hierarchy known to those skilled in the art. The response received from the other server is then relayed by the DNS server originally called to the device at the source of the DNS request. The device extracts one or more IP addresses contained in the response and typically establishes communication with the recipient server using one of these IP addresses.

[0007] These exchanges between devices and DNS servers (hereinafter referred to as "DNS communications") are often implemented in plain text in a mode called Do53 (or unencrypted DNS). This unencrypted mode enables entities located on the DNS communication path to access sensitive information, such as for profiling purposes. Therefore, Do53 poses a risk of violating user privacy.

[0008] In order to increase the level of confidentiality of DNS communications and restrict access to sensitive information carried by these DNS communications to only authorized or consenting entities, a number of mechanisms for encrypting DNS communications have been specified. Examples of such mechanisms are DNS over DTLS (DoD), DNS over TLS (DoT), DNS over HTTPS (DoH), DNS over QUIC (DoQ), DNS over CoAP (or DoC), etc. However, despite the implementation of such mechanisms, entities located in the DNS communication path are able to use so-called statistical analysis techniques to associate the destination address of the data packets sent after the DNS exchange with a given server or service, and thus obtain potentially sensitive information about the user. In fact, a study conducted by APNIC (Asia Pacific Network Information Center) in 2019 explored the information that can be obtained from a set of IP addresses contacted by a user's device. This study showed in particular that most websites have a unique page load fingerprint (PLF); therefore, there is a risk that the website visited by the user can be identified based on the IP address targeted by the user's device. This means that the above-mentioned encrypted DNS mechanisms have limited protection for user privacy. Summary of the invention

[0009] In particular, the present invention aims to improve the above situation by proposing a method for processing a first name resolution request from a client device, the method being implemented by a name resolution server and comprising sending a response to the first request to the client device, the response comprising at least one item of information related to a server referred to as a receiving server generated by resolving the first request. It is noteworthy that the processing method further comprises sending a plurality of elements to the client device, the plurality of elements comprising:

[0010] - at least one address of at least one relay node, selected by the name resolution server, to which the client device must address all or some of its messages containing data destined for the recipient server; and

[0011] - at least one scrambling instruction to be applied by the client device to said message before addressing said message to said at least one relay node.

[0012] Relatedly, the present invention also relates to a name resolution server, which is configured to send a response to a first name resolution request from a client device, the response including at least one information related to a server referred to as a receiving server generated by resolving the first request. It is worth noting that the name resolution server is also configured to send a plurality of elements to the client device, the plurality of elements including:

[0013] - at least one address of at least one relay node, selected by the name resolution server, to which the client device must address all or some of its messages containing data destined for the recipient server; and

[0014] - at least one scrambling instruction to be applied by the client device to said message before addressing said message to said at least one relay node.

[0015] The present invention is also directed to a communication method implemented by a client device, the communication method comprising receiving a response to a first name resolution request sent by the client device from a name resolution server, the response comprising at least one item of information related to a server referred to as a receiving server generated by resolving the first request. It is noteworthy that the communication method further comprises:

[0016] - receiving a plurality of elements from the name resolution server, the plurality of elements comprising:

[0017] o at least one address of at least one relay node selected by the name resolution server to which the client device must address all or some of its messages containing data destined for the recipient server; and

[0018] o at least one scrambling instruction to be applied by the client device to the message prior to addressing the message to the at least one relay node; and

[0019] - applying said scrambling instructions to said message.

[0020] Relatedly, the present invention also relates to a client device, which is configured to receive a response to a first name resolution request sent by the client device from a name resolution server, the response including at least one item of information related to a server referred to as a receiving server generated by resolving the first request. It is worth noting that the client device is also configured to:

[0021] - receiving a plurality of elements from the name resolution server, the plurality of elements comprising:

[0022] o at least one address of at least one relay node selected by the name resolution server to which the client device must address all or some of its messages containing data destined for the recipient server; and

[0023] o at least one scrambling instruction to be applied by the client device to the message prior to addressing the message to the at least one relay node; and

[0024] - applying said scrambling instructions to said message.

[0025] According to yet another aspect, the present invention is also directed to a method for processing a message, the method being implemented by a relay node selected by a name resolution server for a client device and a recipient server, the method comprising:

[0026] - obtaining at least one item of information relating to at least one scrambling instruction applied by the client device to messages containing data destined for the recipient server before addressing the messages to the relay node;

[0027] - upon receiving at least one scrambled message containing data destined for the recipient server and addressed by the client device to the relay node, using said acquired at least one item of information to remove the scrambling applied by the client device; and

[0028] - transmitting said at least one message obtained after removing the scrambling to the recipient server.

[0029] Relatedly, the present invention also relates to a relay node in a communication network, the relay node being selected by a name resolution server for a client device and a recipient server, the relay node being configured to:

[0030] - obtaining at least one item of information relating to at least one scrambling instruction applied by the client device to messages containing data destined for the recipient server before addressing the messages to the relay node;

[0031] - upon receiving at least one scrambled message containing data destined for the recipient server and addressed by the client device to the relay node, using said acquired at least one item of information to remove the scrambling applied by the client device; and

[0032] - transmitting said at least one message obtained after removing the scrambling to the recipient server.

[0033] The present invention therefore proposes a solution that makes it possible to prevent devices that are close to the client devices (from the point of view of network topology) from accessing sensitive information. The solution is therefore particularly applicable at the level of the access network used by the client devices (e.g. public or private WLAN (Wireless Local Area Network), mobile network, etc.) by using multiple network entities (one or more name resolution servers, one or more relay nodes) to prevent malicious actions that may be carried out during DNS communications or more generally during communications related to the resolution of resources such as URIs, domain names, etc.). These resources are more generally referred to as "names" in the rest of this document. A preferred but non-limiting application of the invention is when the communications in question are encrypted; no restrictions are attached to the encryption schemes that are then envisaged for the transmission of messages exchanged during these communications (e.g. for DNS, DoT, DoD, DoQ, DoH, DoC communications).

[0034] Similarly, no restrictions are imposed on the nature of the client device (which may be, for example, a terminal, CPE (customer premises equipment), STB (set-top box) decoder, etc.) or on the nature of the relay nodes selected by the name resolution server (which may in particular be a server, router, etc.).

[0035] The solution proposed by the present invention more particularly relies on the selection of at least one relay node by a trusted name resolution server invoked by a client device when it wishes to access a given service (usually provided by a server referred to as a recipient server), via which the client device will interact with the recipient server. Multiple relay nodes may be advantageously used during communication with the recipient server; for example, each relay node is used for a limited period of time. It should also be noted that a name resolution request may result in one or more communications with one or more recipient servers. One or more relay nodes may be utilized to manage communications with these various recipient servers.

[0036] More specifically, according to the present invention, a client device addresses messages containing data intended for a recipient server (in other words, data it wishes to send to it in the context of accessing a service) to a relay node, which is then responsible for relaying these messages to the recipient server. According to the present invention, the introduction of a relay node between the client device and the recipient server has the effect of shielding the actual recipient (i.e., the recipient server) of the data sent by the client device when accessing the service, because the address to which the message is sent is the address of the relay node rather than the address of the recipient server. The address of the recipient server is itself hidden in the content of the message addressed to the relay node, for example in the form of encryption shared with the relay node. This makes it possible to make the identity of the recipient server inaccessible in the event that messages between the client device and the relay node are intercepted, while allowing the relay node to relay these messages to the recipient server.

[0037] For example, in one particular embodiment, the message addressed to the at least one relay node comprises, in encrypted form, data destined for the recipient server and the address of the recipient server.

[0038] Thus, these provisions make it difficult or even impossible for a malicious entity located between a client device and a relay node to obtain information revealing practices of a client device user that are susceptible to compromising their privacy by performing statistical analysis of traffic from the client device and / or by establishing and analyzing page load fingerprints.

[0039] Similarly, introducing a relay node between the client device and the recipient server enables masking the actual source of these messages (i.e., the identity of the client device) in the event that the messages are intercepted and inspected by malicious entities located outside the relay node (in the direction from the client device to the recipient server).

[0040] This difficulty in obtaining sensitive data by statistical analysis of the traffic increases when the use of one (or more) relay nodes is combined with one or more (additional) scrambling actions performed by the client device (possibly supplemented with scrambling actions performed by one or more relay nodes). These scrambling actions are transmitted to the client device by the resolution server in the form of scrambling instructions and can be of various types.

[0041] For example, in a particular embodiment of the method for processing a first request, the at least one scrambling instruction transmitted by the name resolution server to the client device includes padding instructions for padding (or filling) messages containing data destined for a recipient server before addressing the messages to the at least one relay node, the instructions including at least one padding pattern to be used by the client device to scramble the messages or a technique for generating at least one such padding pattern.

[0042] Relatedly, in a specific embodiment of the communication method, the at least one scrambling instruction includes a padding instruction that pads the message, and applying the at least one scrambling instruction to the message includes padding at least one of the messages containing data destined for a recipient server and addressed to a relay node using a padding pattern provided in the padding instruction or generated by a generation technique provided in the padding instruction.

[0043] By way of illustration, message padding instructions may include, in the context of a voice communication service based on the exchange of small data packets between a client device and a recipient server, increasing the length of a data packet sent by a client device to a relay node and destined for a recipient server using a determined padding pattern, the determined padding pattern being provided by a name resolution server or generated by the client device using a padding pattern generation technique provided by a name resolution server.

[0044] The message padding performed by the client device makes it possible to normalize the profile of the messages sent by the client device and thus to homogenize the traffic leaving the client device. In order to strengthen the protection of the data carried by the messages sent to the relay node, as mentioned above, the data, the padding pattern that supplements these data, and the address of the recipient server can be encrypted before addressing them to the relay node. This also makes it possible to ensure the authenticity and integrity of the messages exchanged between the client device and the relay node and the information contained in these messages. In a specific embodiment, it is conceivable to activate encryption by default to send this critical information (for example, for scrambled mode).

[0045] In addition to or as an alternative to the above actions, other actions can be envisaged to scramble the message before it is sent to the relay node.

[0046] Thus, in another embodiment, the at least one scrambling instruction comprises instructions for the client device to establish at least one fake connection with and / or via the at least one relay node.

[0047] This fake connection is established in parallel with the connection (hereinafter referred to as the "primary connection") used by the client device to transmit messages to the recipient server to the relay node. It can end at the relay node or be relayed therefrom to a dedicated server (i.e., a server that can correctly and knowingly establish and manage the fake connection). The client device can be configured to transmit fake data on this fake connection, i.e., data that is not intended to be "consumed" (i.e., utilized, used) by the relay node and / or the dedicated server that receives the fake data. Similarly, the repeater and / or the client device do not consume fake application data that may be transmitted by the dedicated server.

[0048] In a specific embodiment, the method for processing a first name resolution request or the communication method may further comprise the step of notifying the at least one relay node of at least one item of information related to the at least one scrambling instruction.

[0049] Such notification to the relay node by the name resolution server or client device allows the relay node to easily identify the applied scrambling and remove it from scrambled messages from the client device before they are transmitted to the recipient server.

[0050] The information notified to the relay node may include the scrambling instructions themselves, as issued by the name resolution server to the client device, or may simply include certain elements representative of the scrambling instructions sufficient to allow the relay node to remove the scrambling introduced by the client device. For example, in the case of message padding instructions, when the client device notifies the relay node of the information in question, the information may be an indicator that defines or identifies the padding pattern contained in the message (e.g., such an indicator may include a bit or symbol offset).

[0051] When a relay node receives a scrambled message containing data destined for a recipient server from a client device, the relay node advantageously takes into account the scrambling action orchestrated by the name resolution server in order to identify and then remove the scrambling introduced by the client device before relaying the message to the recipient server.

[0052] Upon receiving at least one message from a recipient server and containing data destined for a client device, the relay node may also scramble the at least one message in a manner transparent to the recipient server before transmitting the at least one message to the client device.

[0053] The scrambling introduced by the relay node may be equivalent to the scrambling applied by the client device (in other words, of the same type, e.g. based on the same padding pattern). This mode is referred to as a "symmetric scrambling mode".

[0054] As a variant, the scrambling introduced by the relay node may be different from the scrambling applied by the client device; for example, message padding may be applied only in one direction, or different padding patterns may be applied in both directions, or a fake connection may be simulated in one direction (e.g., from the client device to the relay node) while message padding is applied in the other direction (e.g., from the relay node to the client device), etc. This mode is called an "asymmetric scrambling mode". This difference in the scrambling action applied makes it possible to take into account the asymmetric characteristics of the amount of traffic according to its direction. In fact, a larger amount of payload data is usually transmitted in the direction from the relay node to the client device. For a given application, these data may have a profile that is constant over time and are therefore used for user profiling (and therefore traceability / tracking) purposes. Therefore, applying appropriate scrambling in each of these two communication directions allows more effective protection of sensitive information related to the client device or its user.

[0055] Additionally, it should be noted that it is not always possible to apply the same scrambling in the client device to relay node direction as in the relay node to client device direction (e.g., it may be the case that messages sent in the client device to relay node direction do not contain as much data as in the opposite direction).

[0056] By means of the scrambling introduced by the client device and possibly by the relay nodes, it is difficult or even impossible for a malicious third-party entity to infer / extract / extrapolate information about traffic from and / or to the client device. Combined with the intervention of the relay nodes acting as intermediaries between the client device and the recipient server, it is possible to eliminate the implementation of statistical analysis by malicious third-party entities present in the network involved in routing DNS traffic, or at least reduce the scope of such statistical analysis and limit the relevance of information obtained from such statistical analysis.

[0057] The invention thus makes it possible to ensure that the confidentiality of communications established by client devices is respected and contributes to better protecting the privacy of users of these client devices and limiting the risks of user profiling. By means of the invention, network operators can incidentally provide value-added name resolution services (e.g., DNS services) and thus benefit from the trust of their users. It should be noted that the users in question are not necessarily the users to whom the operator provides a network connection.

[0058] As mentioned above, the purpose of introducing relay nodes between the client device and the recipient server is to mask the actual recipients of messages sent by the client device and the actual source of these messages (when the messages are over-examined outside the relay nodes), thereby making it difficult to perform statistical analysis on the traffic from the client device. This difficulty can be increased by judiciously selecting one or more relay nodes to be used by the client device. For example, the name resolution server can select at least one of the relay nodes so that the relay node satisfies at least one of the following conditions:

[0059] - preventing association between the relay node and the recipient server (e.g., the same relay node may be used for multiple different recipient servers, or different relay nodes may be selected for the same client device and the same recipient server but for different communications between the client device and the recipient server); and / or

[0060] - Maximizing the number of client devices using the relay node.

[0061] These standards make it possible to limit the risk of malicious entities tracking communications intended for name resolution (eg, DNS communications).

[0062] When selecting a relay node for a client device and a recipient server, other conditions to be met may be considered, such as optimizing the client devices using the selected relay node based on at least one given criterion, such as load considerations or geographical considerations (which may specifically relate to the operator's proprietary technology and / or the engineering / configuration of the relay node). According to yet another example, the reason why a relay node may be selected is that the relay node meets the condition that it (already) has a route to the recipient server.

[0063] It should be noted that the above-mentioned criteria are not exclusive; in other words, the name resolution server may consider multiple criteria simultaneously to select a relay node for the client device and the recipient server.

[0064] In a particular embodiment, the plurality of elements transmitted by the resolution server to the client device (and incidentally received by the client device from the resolution server) also includes a first indication that at least one of the relay nodes can be used by the client device to send at least one second name resolution request related to the first request.

[0065] In other words, the relay node in question is not only used by the client device to transmit messages to the recipient server, but is also responsible for resolving all or some future client device name resolution queries related to the first request, such as related to names of subdomains of the domain name involved in the first request. This enables the introduction of an additional degree of scrambling, thereby making it difficult for a malicious entity to establish a link between a particular name resolution server and the client device. Furthermore, each name resolution server involved in the communication of the client device with the recipient server has only partial knowledge of the query sent by the client device.

[0066] It is conceivable to introduce a certain degree of granularity in the name resolution query directed to the relay node. Therefore, in a specific embodiment, the plurality of elements transmitted by the resolution server to the client device (and incidentally received by the client device from the resolution server) may also include a second indication identifying the name resolution query to which the first indication relates.

[0067] In a particular embodiment, the plurality of elements transmitted by the resolution server to the client device (and incidentally received by the client device from the resolution server) further comprises at least one identifier of the at least one relay node selected by the name resolution server.

[0068] This embodiment has several advantages.

[0069] Firstly, this embodiment enables management of situations where multiple relay nodes can be reached using the same IP address.The identifier transmitted in multiple elements allows a client device to distinguish a particular relay node from multiple relay nodes sharing the same IP address.

[0070] Furthermore, transmission of the identifier of the relay node selected by the name resolution server enables the elimination of the need to maintain state at the name resolution server associating one or more relay nodes with each client device with which it contacts (in this case, refer to a stateless name resolution server).

[0071] In a particular embodiment, the first request comprises at least one identifier of at least one relay node previously selected for the client device and to which the client device sends all or some of its messages containing data destined for the recipient server.

[0072] It should be noted that the relay node in question may have been selected by the name resolution server to which the client device addressed the first request or by another name resolution server for the client device and the same recipient server (typically for the same communication with the recipient server). Inserting the identifier of the relay node currently being used by the client device allows the name resolution server to which the first request is addressed to reselect the same relay node (i.e., at least one of said relay nodes selected by the name resolution server coincides with the relay node identified in the first request) according to the adopted policy, for example to exploit an existing connection, or, on the contrary, to knowingly select a different relay node in order to make it even more difficult to track the communications of the client device. Indeed, in the latter case, it is more difficult to associate the recipient server with the identity of the relay contained in the first request.

[0073] Furthermore, this embodiment enables limiting the information stored by the name resolution server (as explained above, no state needs to be kept), thereby enhancing the security of the mechanism implemented by the invention and limiting the risk of tracking client devices based on their DNS communications.

[0074] In a particular embodiment, the plurality of elements are sent to or received by the client device in a response to the first resolution request.

[0075] This embodiment enables the invention to be applied immediately starting from the first resolution request. Furthermore, it advantageously enables the signaling required to implement the invention between the name resolution server and the client device to be limited.

[0076] It should be noted that the adjectives "first" and "second" are used merely to distinguish two consecutive name resolution queries related to each other, e.g., a request related to a domain name and a subsequent request related to a subdomain of the domain name. Such use does not presuppose the absence of a DNS exchange or more generally prior name resolution between the client device and the name resolution server, e.g., the client device sending and the name resolution server resolving a request related to another domain name.

[0077] In one embodiment, sending the plurality of elements by the name resolution server to the client device is conditional on the name resolution server detecting a certain option in the first request.

[0078] This embodiment provides the user of the client device with the possibility to choose whether they wish to benefit from the protection mechanism proposed by the present invention. For example, if the network used by the user's client device to access the service provided by the recipient server is a trusted network, the user can decide to deactivate the implementation of the present invention. On the contrary, if the network is not a trusted network, the user can decide to use the present invention. It should be noted that this deactivation can also be performed automatically (i.e., without user intervention) by the client device itself in a transparent manner to it.

[0079] In a particular embodiment, the method for processing (first) requests and messages and / or the communication method is / are computer-implemented.

[0080] The invention is also directed to a computer program on a recording medium, which program can be implemented in a computer or more generally in a name resolution server according to the invention and comprises instructions designed to implement the method for processing a first name resolution request as described above.

[0081] The invention is also directed to a computer program on a recording medium, capable of being implemented in a computer or more generally in a client device according to the invention and comprising instructions designed to implement the communication method as described above.

[0082] The invention is also directed to a computer program on a recording medium, capable of being implemented in a computer or more generally in a relay node according to the invention and comprising instructions designed to implement the method for processing messages as described above.

[0083] Each of these programs can use any programming language, and can be in the form of source code, object code, or an intermediate code between source code and object code, such as in a partially compiled form, or in any other desired form.

[0084] The present invention is also directed to a computer-readable information medium or a recording medium including instructions of the computer program as mentioned above.

[0085] The information medium or recording medium may be any entity or device capable of storing a program. For example, the medium may include a storage device such as a ROM (e.g., a CD-ROM or a microelectronic circuit ROM), or a magnetic recording device (e.g., a hard disk or a flash memory).

[0086] Furthermore, the information medium or recording medium may be a transmissible medium such as an electrical or optical signal, which may be routed via an electrical or optical cable, by a radio link, by a wireless optical link, or by other means.

[0087] Specifically, the program according to the present invention can be downloaded from the Internet.

[0088] Alternatively, the information medium or recording medium may be an integrated circuit in which a program is incorporated, the circuit being designed to execute or to execute the processing and communication method according to the present invention.

[0089] According to another aspect, the present invention also relates to a system in a communication network, the system comprising:

[0090] - a client device according to the invention;

[0091] - a name resolution server according to the invention; and

[0092] - At least one relay node according to the invention selected by a name resolution server for said client device.

[0093] The system according to the invention benefits from the same above-mentioned advantages as the client device, the name resolution server and the relay node according to the invention.

[0094] In other embodiments, it is also conceivable that the processing and communication methods, name resolution servers, client devices, relay nodes and systems according to the present invention have a combination of all or some of the above features. BRIEF DESCRIPTION OF THE DRAWINGS

[0095] Other features and advantages of the invention will emerge from the following description given with reference to the accompanying drawings, which show an exemplary embodiment of the invention which is in no way limiting. In the drawings:

[0096] [ Figure 1 ] Figure 1 In its environment is shown a system in a network according to the invention in a specific embodiment;

[0097] [ Figure 2 ] Figure 2 Schematically shows the hardware architecture of a computer capable of hosting a computer according to the present invention. Figure 1 any entity in the system;

[0098] [ Figure 3 ] Figure 3 It shows that according to the present invention Figure 1 The system's name resolution server function module;

[0099] [ Figure 4 ] Figure 4 It shows that according to the present invention Figure 1 Functional modules of client devices of the system;

[0100] [ Figure 5 ] Figure 5 It shows that according to the present invention Figure 1 Functional module of the relay node of the system;

[0101] [ Figure 6 ] Figure 6 The main steps of the method for processing a name resolution request are shown in the form of a flowchart. Figure 3 Name resolution server implementation;

[0102] [ Figure 7 ] Figure 7 The main steps of the communication method are shown in the form of a flow chart. Figure 4 Client device implementation of

[0103] [ Figure 8 ] Figure 8 The main steps of the method for processing a message are shown in the form of a flow chart. Figure 5 Relay node implementation;

[0104] [ Fig. 9 ] Fig. 9 include Fig. 9 A and Fig. 9 B, which respectively shows an option called EAO (standing for EDNS (Extension Mechanisms for DNS) ASTRA (a DNS-driven protection against statistical traffic analysis) option) that can be used in a name resolution request and in a response to the request to implement the present invention in a specific embodiment;

[0105] [ Fig.10 ] Fig.10 Partially and schematically illustrates addressing Figure 5 Relay nodes and contain Figure 1 The encrypted message of the data of the receiving server;

[0106] [ Fig.11 ] Fig.11 Schematically illustrates a specific variant embodiment of the Figure 5 changes made to port numbers and source and destination addresses by relay nodes of

[0107] [ Fig.12 ] Fig.12 include Fig.12 A and Fig.12 B, which shows the exchanges between the entities of the system 1 of the figure depending on whether the client device of the system supports the "partial offloading" function. DETAILED DESCRIPTION

[0108] Figure 1A system 1 in a communication network NW according to the invention in a specific embodiment is shown. No restrictions are imposed on the nature of the communication network NW, which may include one or more sub-networks, such as, for example, one or more access (sub-)networks (e.g., public or private WLAN networks, mobile networks, etc.), the Internet, etc.

[0109] According to the present invention, the system 1 comprises:

[0110] - A client device 2 according to the invention. Figure 1 In the example of , the client device 2 is a terminal of the user U, such as a mobile phone (e.g., a smart phone), which is connected to the public WLAN network AN1 and the mobile access network AN2, via which the terminal can access the Internet. Of course, the present invention is applicable to other fixed or mobile client devices (e.g., decoders, such as STB, CPE, etc.) and other networks (wired, wireless, etc.), and the client device 2 can be connected to one or more access networks simultaneously, directly or via an intermediate device such as CPE;

[0111] - at least one trusted name resolution server of the client device 2 according to the invention and generally indicated by 3 (generally considered as trusted by the user U of the client device 2). Figure 1 In the example of , two trusted servers 3 according to the invention are considered by way of illustration. By way of illustration, these servers 3-1 and 3-2 are domain name resolution servers, also commonly referred to as DNS servers, as defined by the IETF document RFC 1034 (November 1987). However, the invention can be applied in the context of resolving other IP resources, which are generally referred to as "names" in this document, such as, for example, URIs, etc.; and

[0112] - at least one relay node 4-1, 4-2, etc. according to the invention, more generally indicated by reference numeral 4 and interfaced with the name resolution server 3 using, for example, the RESTCONF protocol described in IETF document RFC 8040 (January 2017). Of course, other protocols may be envisaged as variants of this interface.

[0113] In the embodiment described here, the mechanism proposed by the invention, which is hereinafter referred to as AD ASTRA (standing for Advanced DNS-driven Protection against Statistical Traffic Analysis) procedure or mechanism, is activated when a client device 2 uses an access network that is not a trusted network of the client device 2 to access the Internet and more particularly to access any service S (e.g. voice communication service, web service) hosted or provided by a remote server 5 associated with (i.e. identified by) a given domain name (e.g., by way of illustration, "service-s.com"). Such a network, which is called an untrusted network, is for example a public network (such as the public WLAN network AN1) or a "tourist" network (such as a hotel network, a bar network, a city network, etc.). In practice, this entails a risk for the client device 2, whereby its communications (in particular with the local DNS server 6 of the network in question) could be intercepted by a malicious third-party entity and, where applicable, exploited by this entity, for example by performing statistical analysis, in order to obtain information that could compromise the privacy of the user U.

[0114] In contrast, when the access network used by the client device 2 is a trusted network of the client device 2 (such as, for example, the mobile network AN2), the AD ASTRA mechanism is deactivated here (although this is not mandatory). Such a trusted network is typically a network configured as such by the user U of the client device 2 or according to a default configuration, or a network identified as such, for example by using a network identity authentication mechanism. As an alternative, the trusted network can also be dynamically determined by verifying the assertion of the network in a manner known per se. The client device 2 is then configured to use a local trusted DNS server 7 (local to the trusted network) announced by the trusted network when it wishes to access the service S via such a trusted network, for example, through the announcement mechanism described in the document draft-ietf-add-dnr-13 published by the IETF and entitled "DHCP and Router Advertisement Options for the DiscoveryofNetwork-designated Resolvers (DNR)" (August 2022). The DNS server 7 can be a DNS server according to the present invention or a DNS server known in the prior art that does not implement the present invention.

[0115] Activation / deactivation of the AD ASTRA mechanism based on the trust level assigned to the access network used by the client device 2 can be configured by default on the client device 2 (thereby allowing the mechanism to be automatically activated or deactivated depending on the conditions under which the client device 2 attaches to the network), or can be decided dynamically, for example by querying the user U of the client device 2 (via a user interface provided for this purpose).

[0116] The trusted DNS server 3 belongs to a list L-DNS of trusted DNS servers, which list is for example configured by default on the client device 2 or defined by the user U of the client device 2 (for example via a user interface provided for this purpose). Such configuration can in particular be performed by the operator of the network providing the IP connection to the client device 2 (for example its Internet access provider) or by the user U of the client device 2. For the sake of simplicity, it will be assumed that the list L-DNS contains only trusted DNS servers that support the AD ASTRA mechanism. However, as a variant, the list L-DNS can also contain trusted DNS servers that do not support this mechanism.

[0117] exist Figure 1 In the example, the DNS servers 3 included in the list L-DNS are on the Internet; although there is no restriction on their actual location, the DNS servers 3 are preferably not located in an untrusted network (i.e., a network that is not a trusted network of the client device 2) or are not advertised by an untrusted network.

[0118] It should be noted that there is no limit to the number of trusted DNS (or more generally name resolution) servers as specified in the list L-DNS, which may be greater than or equal to 1. In the embodiments described herein, it will be assumed that the client device 2 embeds a DNS client referenced CL (e.g., in an application such as its operating system or OS, the DNS client CL may be shared by multiple applications), which selects one or more trusted DNS servers to be called from the list L-DNS according to a predefined local policy (e.g., via a default configuration) for each domain name resolution required when enabling a service (such as, for example, a service S provided by a remote server 5). The local policy may specify in particular:

[0119] - a continuous selection mode, whereby the same DNS server is selected according to local preferences or information characteristics based on the capabilities of the DNS servers in the list L-DNS, and is called for a determined duration;

[0120] - Sequential selection mode, whereby the DNS client CL builds a list L-CAND of candidate servers from the list L-DNS, the list being ordered according to one or more criteria. For example, the list L-CAND is built and ordered based on the encryption schemes supported by each DNS server (where applicable); such encryption schemes are, for example, the DoT, DoD, DoH, DoQ or DoC encryption schemes as described above. By way of illustration, the list L-CAND may thus contain all the DNS servers in the list L-DNS that support the DoH encryption scheme, followed by all the DNS servers in the list L-DNS that support the DoT encryption scheme. The DNS client CL then calls the DNS servers in the order of the list L-CAND thus built. Of course, criteria other than the encryption schemes may be envisaged as variants, such as, for example, the location of the DNS servers, one or more of their processing capabilities, etc.;

[0121] - Random selection mode: The DNS client CL randomly selects a DNS server for any new DNS resolution request. This random selection mode may also result in a random selection of the implemented encryption scheme;

[0122] -etc.

[0123] These examples of policies adopted by the DNS client CL of the client device 2 are given by way of illustration only, and other policies can be envisaged as variants. In addition, the client device 2 may embed one or more DNS clients CL that are capable of implementing such policies when activated.

[0124] In the embodiment described here, the communication between the client device 2 (and more specifically its DNS client CL) and the trusted DNS server 3 selected by the DNS client CL of the client device 2 is encrypted. For example, they are in accordance with any of the DoT, DoD, DoH, DoQ or DoC protocols. The use of encrypted DNS transport to transmit messages between the client device 2 and the DNS server 3 guarantees the authenticity and integrity of these messages.

[0125] For the sake of simplicity, it is also assumed that the client device 2 exchanges directly with the trusted DNS server 3 selected by the DNS client CL, without involving a DNS relay (or forwarder). However, the present invention also applies in the case where there is a DNS forwarder selected by the DNS client CL and located between the client device 2 and the trusted DNS server 3. More specifically, if the DNS forwarder is trusted, the client device 2 addresses its DNS query to the forwarder; in this case, the DNS forwarder is configured to relay the DNS query from the client device 2 to the DNS server 3 selected by the DNS client CL. If the DNS forwarder is not trusted, the client device 2 is configured to address its DNS query directly to the DNS server 3 selected by the DNS client CL (and thus bypass the DNS forwarder). Therefore, in the following text, for the sake of simplicity, the term "DNS request addressed by the client device" specifies a DNS request directly from the client device or via a DNS forwarder, as just mentioned.

[0126] According to the invention, when the AD ASTRA mechanism is activated and the client device 2 calls a trusted DNS server 3 to resolve a domain name associated with a service S hosted by a remote server 5, the DNS server 3 in question is configured to, in addition to resolving the domain name in question (directly or indirectly by calling another DNS server), select one or more relay nodes from the relay nodes 4 of the system 1 to which the client device 2 should be directed to send its message containing data sent in the context of the service S to the remote server 5 (recipient server within the meaning of the invention). The communication between the client device 2 and the selected one or more relay nodes 4 of the system 1 and between these relay nodes 4 and the DNS server 3 that selected them is encrypted in the embodiment described here, for example by means of the TLS (Transport Layer Security) protocol version 1.3, possibly in combination with the use of the ECH (Encrypted Client Hello) function. Of course, this assumption itself is not limiting and other encryption protocols and extensions can be envisaged as variants in the context of the invention.

[0127] In the embodiment described here, the client device 2, the DNS server 3 and the relay node 4 have the hardware architecture of a computer 8, such as Figure 2Schematically shown in . The hardware architecture is based on a processor PROC, a random access memory MEM, a read-only memory ROM, a non-volatile memory NVM and communication means COM, which enable each of the above-mentioned devices to communicate in particular with other devices of the system 1. These communication means COM can in particular rely on a wired or wireless communication interface known per se and not described in detail here, and / or on one or more software interfaces (such as an application programming interface (API) or a point-to-point communication interface, etc.), and implement one or more encryption schemes as mentioned above.

[0128] The non-volatile memory NVM (or read-only memory ROM as a variant) of the computer 8 constitutes a recording medium according to the invention which can be read by the processor PROC and on which the computer program according to the invention is recorded.

[0129] In the case of a DNS server 3 according to the invention, the computer program is referenced PROG3 and comprises instructions defining the main steps of the method for handling a (first) name resolution request according to the invention. In the case of a client device 2 according to the invention, the computer program is referenced PROG2 and comprises instructions defining the main steps of the communication method according to the invention. Finally, in the case of a relay node 4 according to the invention, the computer program is referenced PROG4 and comprises instructions defining the main steps of the method for handling a message according to the invention.

[0130] The computer program PROG3 defines the functional modules of the DNS server 3 according to the invention, which depend on or control the elements PROC, MEM, ROM, NVM and COM of the computer 8. In the embodiment described here, these functional modules include in particular the following items, such as Figure 3 Shown in:

[0131] a reception module 3A configured to receive a name resolution query REQ-DNS (a DNS query in the example envisaged here) sent by a client device, and in particular by the client device 2 ;

[0132] a processing module 3B configured to process (in other words, to parse) the queries REQ-DNS received by the reception module 3A and to prepare responses REP-DNS to these queries;

[0133] - a providing module 3C configured to provide, to each client device that has called a DNS server 3 supporting (and incidentally calling) an implementation of the AD ASTRA mechanism, a plurality of elements AD ASTRA-ELTS in addition to the information normally provided in response to a request REQ-DNS, as described in more detail later. In the embodiment described here, the plurality of elements ADASTRA-ELTS are provided to the client device that has addressed the request REQ-DNS to the DNS server 3 in a response REP-DNS to that request (for example in an EDNS (Extended Mechanisms of DNS) option), as explained in more detail later. However, these assumptions are not limiting and it is conceivable that the plurality of elements ADASTRA-ELTS are provided to the client device using one or more messages different from the response REP-DNS; and

[0134] A sending module 3D configured to send the response REP-DNS prepared by the processing module 3B and the plurality of elements AD ASTRA-ELTS provided by the providing module 3C to the client device that has invoked the DNS server 3 .

[0135] In order to resolve the request REQ-DNS received from the client device, the processing module 3B typically establishes a match between the name involved in the request REQ-DNS (for example, the domain name "service-s.com" used to access service S) and the IP resources (for example, IP address) of the server associated with the name (server 5 in the example of the domain name "service-s.com") based on the records RR owned by the DNS server 3 or accessible to it (via one or more other DNS servers organized hierarchically).

[0136] In the example envisaged here, for simplicity, restrictions are drawn at A record RR (a match is established between a name and the IPv4 address of a server associated with the name) and AAAA record RR (a match is established between a name and the IPv6 address of a server associated with the name), the server associated with the name being able to be identified by an IPv4 address and / or an IPv6 address (and therefore corresponding to an A record and / or an AAAA record). However, it should be noted that the present invention is not limited to these two types of records and is also applicable to other types of records RR, such as SVCB (Service Binding), SRV (Service Resource Record), CNAME, etc., which may be associated with name resources other than IP addresses, such as, for example, an alias, another name, a URI, etc.

[0137] The response REP-DNS to the request REQ-DNS prepared by the processing module 3B thus comprises at least one item of information contained in a record RR relating to a server associated with the name to which the request REQ-DNS relates (herein referred to as "receiving server") and generated by the resolution of the request REQ-DNS by the processing module 3B. In the example of A and AAAA records RR envisaged here, this information comprises at least one IP (IPv4 and / or IPv6) address of the receiving server.

[0138] As mentioned above, in the embodiment described here, the response REP-DNS also includes a plurality of elements AD ASTRA-ELTS provided by the providing module 3C of the DNS server 3. According to the present invention, the plurality of elements AD ASTRA-ELTS include at least the following elements:

[0139] - at least one IP address of at least one relay node 4 selected by the DNS server 3 (for example by its provision module 3C) for the client device 2 and the recipient server associated with the name to which the request REQ-DNS relates (the remote server 5 in the envisaged example) to which the client device must send all or some of its messages containing data destined for the recipient server. This IP address may be supplemented by the port number to be used by the client device to address its messages to the relay node 4, if no default port number is defined. In other words, the client device must address these messages to the relay node 4, instead of addressing the messages related to the services it wishes to access to the recipient server identified in the response REP-DNS (i.e. indicating the address of the relay node 4 as the destination address of these messages instead of the address of the recipient server). However, the recipient server to which the payload data contained in these messages are actually destined is still identified in the content of the messages addressed to the relay node 4-1, enabling it to relay these payload data to this recipient server. Thus, in the envisaged example of service S, if a plurality of elements AD ASTRA-ELTS specify the relay node 4-1, this means that the client device 2 must address messages containing data destined for the remote server 5 to the relay node 4-1. Each message addressed to the relay node 4-1 has as its destination address the address of the relay node 4-1 (including its IP address represented as @IP4-1 and the port number P4-1, which port number may be defined by default or may have been provided by the DNS server 3 with the IP address of the relay node 4-1 as mentioned above), and contains a data packet, referred to as an inner data packet, encrypted by an encryption scheme (e.g. TLS, DTLS). The inner data packet contains payload data destined for the remote server 5 and has as its destination address the IP address of the remote server 5 and its port number (more generally also referred to as the “transport address”). Thus, the address of the remote server 5 is masked by being encrypted in the content of the message addressed to the relay node 4-1; and

[0140] at least one scrambling instruction INST intended to be applied (in other words, to be applied) by the client device 2 to said message containing data destined for the recipient server, said message then being addressed to said at least one relay node 4. As further explained below, such scrambling instructions may comprise, for example, padding instructions for padding all or some messages, and / or instructions for emulating a connection between the client device and a relay node or via the relay node to a dedicated server other than the connection used to send the message containing data destined for the recipient server (in other words, instructions for the client device to establish a "fake" connection).

[0141] refer to Figure 6The steps of the method for processing a (first) name resolution request shown in FIG. 1 describe in more detail the configuration and operation of modules 3A to 3D of the DNS server 3 according to the present invention.

[0142] With regard to the client device 2, the program PROG2 stored in the memory NVM (or as a variant ROM) of the computer 8 defines the functional modules of the client device 2 which depend on or control the elements PROC, MEM, ROM, NVM and COM of the computer 8. In the embodiment described here, these functional modules include in particular the following, such as Figure 4 Shown in:

[0143] - a sending module 2A embedded in the DNS client CL and configured to send a name resolution request REQ-DNS to one of the DNS servers 3 in the list L-DNS selected by the DNS client CL of the client device 2. In the example envisaged here, this request REQ-DNS concerns a domain name and an A or AAAA record RR attached to this domain name. The sending module 2A is activated by the DNS client CL each time the client device 2 wishes to access a service (for example, a service S hosted by a remote server 5 and associated with the domain name “service-s.com”). In the embodiment described here, the request REQ-DNS also comprises an EDNS EAO option indicating to the called DNS server 3 that the client device 2 supports (and incidentally calls) the ADASTRA mechanism. As a variant, the fact that the client device 2 supports the AD ASTRA mechanism may be signaled to the DNS server 3 in other ways (for example, in a message other than the request REQ-DNS, in another option, etc.);

[0144] - a receiving module 2B embedded in the DNS client CL and configured to receive, from the called DNS server 3, the response REP-DNS to the request REQ-DNS thus prepared. As indicated above, this response REP-DNS comprises at least one item of information related to the record RR requested by the client device 2 from the recipient server associated with the name to which the request REQ-DNS relates, such as the IP address of the recipient server. Furthermore, in the embodiment described here, the response REP-DNS contains a plurality of elements AD ASTRA-ELTS provided by the DNS server 3 according to the AD ASTRA mechanism;

[0145] - an execution module 2C configured to apply said at least one scrambling instruction contained in the plurality of elements AD ASTRA-ELTS before addressing messages containing data destined for a recipient server associated with the name to which the request REQ-DNS relates to one of the relay nodes 4 identified in the plurality of elements AD ASTRA-ELTS; and

[0146] A sending module 2D configured to send the scrambled message obtained by the execution module 2C to the relay node 4 in question.

[0147] refer to Figure 7 The steps of the communication method shown in FIG. 1 describe in more detail the configuration and operation of the modules 2A to 2D of the client device 2 according to the present invention.

[0148] Similarly, the program PROG4 stored in the memory NVM (or as a variant ROM) of the computer 8 defines the functional modules of the relay node 4 according to the invention, which functional modules rely on or control the elements PROC, MEM, ROM, NVM and COM of the computer 8. In the embodiment described here, these functional modules include in particular the following, such as Figure 5 Shown in:

[0149] an acquisition module 4A configured to acquire information related to at least one scrambling instruction INST applied by a client device according to the invention, such as the client device 2, for which a relay node 4 has been selected, said scrambling instruction INST being applied to messages containing data destined for a recipient server before the client device addresses them to the relay node 4. The information related to the scrambling instruction INST may be acquired via a trusted DNS server 3 located at the origin of the instruction or by a client device configured to apply the instruction; and

[0150] - A processing module 4B, which is configured to:

[0151] o upon receipt of such a message, removing the scrambling applied to the message by the client device in accordance with the scrambling instruction INST using the acquired information; and

[0152] o Transmit the message obtained after removing the scrambling to the receiving server. It should be noted that in the case of cascade deployment of multiple relay nodes, the relay node 4 can transmit the obtained message to the receiving server directly or via another relay node. The working method of the processing module 4B is not difficult for those skilled in the art and will not be described in detail here.

[0153] In the embodiment described herein, module 4B is also configured to, upon receiving a message from a receiving server and destined for a client device selected therefor (e.g., client device 2), scramble the message and transmit the obtained scrambled message to the client device. It should be noted that module 4B does not necessarily apply the scrambling that has been applied to the relay node direction in the client device in the relay node to the client device direction (i.e., the scrambling applied in one direction and the scrambling applied in the other direction are not necessarily the same). For example, the scrambling applied in the relay node to the client device direction is selected by the trusted DNS server 3. If the scrambling is different from the scrambling applied in the client device to the relay node direction, the relay node 4 is notified of this situation, for example, by the trusted DNS server 3, and receives therefrom, via its acquisition module 4A, a scrambling instruction INST′ describing the scrambling to be applied. As an alternative, the instruction for identifying the scrambling is explicitly encoded in the encrypted message and is therefore communicated by the client device (respectively the relay node).

[0154] refer to Figure 8 The steps of the method for processing a message shown in FIG. 4 describe in more detail the configuration and operation of the modules 4A and 4B of the relay node 4 according to the present invention.

[0155] Now refer to Figures 6 to 8 A method for processing a name resolution request according to the present invention is given. Figure 6 ), communication method ( Figure 7 ) and the method for processing the message ( Figure 8 ) as implemented in a specific embodiment respectively by a DNS server 3 (in the example envisaged below, the DNS server 3-1), a client device 2 and a relay node 4 (in the example envisaged below, the relay node 4-1) according to the present invention.

[0156] refer to Figure 7 As mentioned above, it will be assumed in the embodiments described herein that the client device 2 is configured (eg by its Internet access provider or by its user) with a list L-DNS of trusted DNS servers 3 supporting the AD ASTRA mechanism according to the present invention.

[0157] In a manner known per se, when a client device, such as client device 2, wishes to access a service hosted within a computing environment via, for example, an application installed on the client device, the application in question sends a DNS request associated with the name (in the DNS sense) of the computing environment to a DNS server in order to obtain the address (e.g., IP address) of a server with which to perform an exchange in order to benefit from the service.

[0158] It will be assumed here that the client device 2 wishes to access, via the application APP, a service S associated with the domain name “service-s.com” and hosted by a remote server 5 .

[0159] The client device 2 then sends, via its sending module 2A, a request REQ-DNS (a first request within the meaning of the invention) for resolving the domain name "service-s.com" to one of the trusted DNS servers 3 identified in the list L-DNS, namely here to the DNS server 3-1 (step E10). The selection of the DNS server 3-1 from the list L-DNS results from a local policy applied by the client device 2 and already preconfigured in the client device 2, as mentioned above. It should also be recalled that the exchanges between the client device 2 and the DNS server 3-1 (in particular the DNS queries and the responses to the DNS queries) are encrypted, for example using one of the above-mentioned DoT, DoD, DoH, DoQ or DoC encryption schemes.

[0160] The request REQ-DNS specifies in a manner known per se the domain name "service-s.com" that the client device 2 wishes to access, and the type of record RR to which the request is directed (e.g., here an A record RR if the client device 2 supports the IPv4 protocol, or here an AAAA record RR if the client device 2 supports the IPv6 protocol). In the embodiment described here, the request REQ-DNS also includes an EDNS option called EAO (newly introduced for the purposes of the present invention), which indicates to the called DNS server 3 (i.e., DNS server 3-1) that the client device 2 supports and is invoking the implementation of the AD ASTRA mechanism.

[0161] Fig. 9 A shows an exemplary format of the EAO option inserted by the client device 2 in its request REQ-DNS, which indicates to the DNS server 3-1 that the client device 2 supports and is invoking the implementation of the AD ASTRA mechanism. According to the document RFC 6891 (April 2013) published by IETF and entitled "Extension Mechanisms for DNS (EDNS (0))", the EAO option includes three fields OPTION-CODE, OPTION-LENGTH and OPTION-DATA, and the OPTION-LENGTH field indicates the byte size of the OPTION-DATA field.

[0162] exist Fig. 9In the example shown, the OPTION-DATA field includes a "partial offload" parameter and an "AID" (AD ASTRA relay identifier) ​​parameter and a reserved location, allowing the client device 2 to communicate its capabilities and other information that may be useful to the called DNS server 3 in conjunction with the AD ASTRA mechanism. More specifically:

[0163] - The client device 2 sends a first name resolution request (request REQ-DNS) to the DNS server 3-1 using a "partial offload" parameter to indicate in the request whether it supports (e.g., the parameter is set to 1) or does not support (e.g., the parameter is set to 0) and then sends a subsequent name resolution query (a second query within the meaning of the present invention, denoted as REQ'-DNS, REQ"-DNS, etc.) related to the first name resolution request REQ-DNS to a name resolution server other than the DNS server 3-1, to which the reachability information (e.g., its IP address) is communicated by the DNS server 3-1. According to the present invention, this other name resolution server can typically be a relay node selected by the DNS server 3-1. The term "related query" is understood here to mean that there is a connection between the two questions raised in the two queries, for example, the first request relates to a request for a "parent" domain name (e.g., "ser vice-s.com"), while the second request involves the resolution of a name of a subdomain of the parent domain (i.e., "*.service-s.com" in the example envisioned above, where * represents a string). Another related example is that the client device 2 discovers names (or references or referrals) that need to be resolved during the processing of data sent by the receiving server resulting from the resolution of the first request; within the meaning of the present invention, one or more second queries sent to resolve these names are related to the first request. Once the client device 2 associates the receiving server as the source of the name, the client device establishes the association. The "partial offload" parameter can be set to 0 by default. In the rest of this specification, if the "partial offload" parameter is set to 1 by the client device 2, it is considered that this supports the "partial offload" function (the function of "offloading" DNS queries to a server other than the DNS server 3-1 responsible for processing the first request REQ-DNS); and

[0164] - In the context of implementing the AD ASTRA mechanism of a service S associated with a domain name "service-S.com" hosted by a server 5, the client device 2 uses the "AID" parameter to indicate whether it has made an active connection (in other words, sent a message containing data destined for the server 5) using a relay node according to the invention and, where applicable, an identifier of this relay node. No restrictions are imposed on the form of the identifier in question: it may be an alias, a number, a domain name, a hash, etc. The client device 2 may associate this identifier with a preference intended for the DNS server 3-1, for example, the two "match" if the client device wants the DNS server 3-1 to choose the same relay node when processing the request REQ-DNS, or the two "do not match" if another relay node is requested to be used. In the embodiment described here, such a preference is not necessarily binding on the DNS server 3-1 and may therefore not be taken into account. Of course, this is only an implementation choice and, as a variant, it is conceivable that such a preference of the client device 2 is binding on the DNS server 3-1.

[0165] refer to Figure 6 , when its reception module 3A receives the request REQ-DNS (step F10 ), the DNS server 3 - 1 determines whether the latter contains the EAO option (test step F20 ).

[0166] If the request REQ-DNS does not contain the EAO option (the response to the test step F20 is "No"), the DNS server 3-1 processes (i.e. resolves) the request REQ-DNS in a conventional manner and known to those skilled in the art via its processing module 3B (step F30), based on the records RR it has or by querying one or more other DNS servers as mentioned above, and then sends its response REP-DNS-0 to the client device 2 (step F40). This response REP-DNS-0 here includes the IP address of the server 5 associated with the domain name "service-s.com", denoted as @IP5.

[0167] If the request REQ-DNS contains the EAO option (response to the test step F20 is "yes"), as is the case in the example envisaged here, the DNS server 3-1 processes (resolves) the request REQ-DNS via its processing module 3B in a conventional manner and known to those skilled in the art (step F50), based on the records RR it possesses or by asking one or more other DNS servers. This processing is identical to that performed in step F30.

[0168] The processing module 3B of the DNS server 3-1 obtains the record RR from the server 5 (the receiving server in the sense of the present invention) associated with the domain name "service-s.com" by resolving the request REQ-DNS, and more particularly obtains its IP address @IP5, which is contained in this record RR (the information related to the receiving server generated by resolving the request REQ-DNS in the sense of the present invention). It includes the address @IP5 in the response REP-DNS to the request REQ-DNS.

[0169] Furthermore, according to the invention, the DNS server 3-1 supporting the AD ASTRA mechanism selects, via its provision module 3C, at least one relay node 4 for the recipient server 5 (step F60). In the example envisaged here, it selects the relay node 4-1. The relay node 4-1 thus selected is intended to be used by the client device 2 to address to it the messages it wishes to send to the recipient server 5 in the context of its access to the service S (instead of sending these messages directly to the recipient server 5). The relay node 4-1 is then responsible for relaying these messages to the recipient server 5, either directly or via another relay node 4 when the relay nodes are deployed in cascade.

[0170] It should be noted that if the client device 2 addresses the request REQ-DNS to a trusted DNS server that does not support the AD ASTRA mechanism and in particular the EAO option (for example, when the list L-DNS contains both trusted DNS servers that support the AD ASTRA mechanism and trusted DNS servers that do not support the mechanism), the server responds to it by sending an error message to the client device 2. Upon receiving the error message, the client device 2 may call another DNS server, send the request back to the same server but without the EAO option, terminate the communication and generate a local notification (application, user, etc.) indicating that the resolution attempt failed, etc.

[0171] In order to select a relay node 4 for the recipient server 5 and the client device 2, the providing module 3C of the DNS server 3-1 may take into account one or more selection criteria. In particular, the providing module 3C may select a relay node 4 that satisfies one or more of the following conditions:

[0172] - prevent the establishment of an association between the selected relay node 4 and the recipient server. In general, the provision module 3C must prevent the relay node 4 from being selected only for a single recipient server, or for a single communication between the client device 2 and the recipient server, it may select a different relay node 4;

[0173] - maximizing the number of client devices using the selected relay node 4;

[0174] - optimizing the client devices using the selected relay node 4 based on at least one given criterion (such as for example load considerations, geographical considerations, etc.);

[0175] - (already) has a route from the selected relay node 4 to the recipient server. This information can be obtained by the provision module 3C by interrogating the relay nodes 4 of the system 1 in order to obtain the routing table maintained thereby;

[0176] -etc.

[0177] In another embodiment, the providing module 3C of the DNS server 3 - 1 may randomly select a pre-configured relay node 4 from the relay node list.

[0178] Furthermore, as mentioned above, the DNS server 3 - 1 may also select a plurality of relay nodes, each intended to be used by the client device 2 for a determined duration (eg, the duration of the connection), by applying the above mentioned criteria.

[0179] In addition, if the EAO option of the request REQ-DNS includes an identifier AID of a relay node previously selected for the client device 2 and the recipient server 5 associated with the service S, the DNS server 3-1 may take this identifier AID into account when selecting the relay node (and, where applicable, the preference associated with this identifier AID indicated by the client device 2). For example, if the client device 2 has inserted the identifier AID of the relay node 4 in the EAO option, the DNS server 3-1 may select the relay node 4 to avoid associating the same relay node with the same recipient server of the client device 2, so as to minimize the risk of the DNS communication of the client device 2 being tracked by a malicious entity (such an entity will in fact have difficulty in establishing an association between the recipient server and the identifier of the relay node). As a variant, it may decide to select a relay node that matches the relay node identified in the identifier AID of the request REQ-DNS.

[0180] However, it should be noted that, depending on the configuration, the DNS server 3 - 1 may ignore the indication provided by the client device 2 in the “AID” ​​parameter of the EAO option of the request REQ-DNS.

[0181] After selecting at least one relay node 4 (relay node 4-1 in the illustrative envisaged example), the providing module 3C inserts the address of the selected relay node (or nodes) in the EDNS EAO option of the response REP-DNS to the request REQ-DNS (step F70). In the embodiment described here, this address is an IP address (IPv4 address or IPv6 address). It forms part of the plurality of elements AD ASTRA-ELTS provided by the providing module 3C to the client device 2.

[0182] As a variant, it is possible to envisage providing a domain name associated with each selected relay node as a reachability address instead of an IP address. Using IP addresses has the advantage that no additional name resolution is required (thus allowing the client device 2 to access the service S more quickly).

[0183] In yet another variant, the address inserted by the providing module 3C is the transport address of the relay node 4 and comprises the IP address of the relay node 4 and the port number to be used.

[0184] Fig. 9 B shows an exemplary format of the EAO option inserted by the DNS server 3-1 in its response REP-DNS (the response responds to the EAO option inserted by the client device 2 in its request REQ-DNS). As shown in the figure, the OPTION-DATA field of the EAO option includes multiple parameters, in particular, a "relay-locator" parameter in which the IP address of the selected relay node 4-1 (or multiple IP addresses of multiple selected relay nodes) is inserted.

[0185] Furthermore, according to the invention, the providing module 3C also inserts at least one scrambling instruction INST into the plurality of elements AD ASTRA-ELTS provided by the providing module to the client device 2 in the EAO option in response to the REP-DNS, whereby the at least one scrambling instruction will be applied to the message which will be addressed to the relay node 4-1 and go to the recipient server.

[0186] In the embodiment described here, the scrambling instructions INST include padding instructions for padding (or filling) the messages sent by the client device 2 before they are sent to the relay node 4-1. The scrambling instructions are inserted into the "Padding" parameter in the OPTION-DATA field of the EAO option, such as Fig. 9As shown. The padding instruction is an instruction for supplementing the message sent by the client device 2 to the relay node 4-1 to the recipient server to make it uniform in size. For example, one or more padding patterns (denoted as PATT) applied by the client device 2 are selected to make the templates of the messages sent by multiple client devices consistent. This advantageously enables further enhancement of the anonymity of the communication of the client device in question.

[0187] The padding instructions inserted into the "padding" parameter by the providing module 3C may take a variety of forms. It may include a generation technique to be used by the client device 2 to generate one or more padding patterns PATT. Such a technique may be based on, for example, a reinforcement learning technique that enables the client device 2 to determine the padding pattern to be applied and to adjust it over time if necessary.

[0188] As a variant, this generation technique may be directly applied by the provision module 3C of the DNS server 3-1, and the padding instructions inserted into the "Padding" parameter may record one or more padding patterns PATT generated by the provision module 3C through this generation technique.

[0189] In the embodiment described herein, the providing module 3C also notifies the relay node 4-1 selected for the client device 2 and the recipient server 5 of the content of the filling instructions (and more particularly, one or more filling patterns PATT or techniques for generating such patterns), and the providing module requires the client device 2 to apply the filling instructions to the message it will send to the relay node 4-1 to the recipient server 5 (step F80).

[0190] This notification of the DNS server 3-1 to the relay node 4-1 allows it to obtain information related to one or more scrambling instructions issued by the DNS server 3-1 to the client device 2, and therefore to process messages from the client device 2 containing data destined for the recipient server 5 before relaying these messages to the recipient server 5.

[0191] As a variant, the relay node 4-1 may obtain such information from the client device 2 itself. For example, in the case of a padding instruction, the client device 2 may inform the relay node 4-1 by inserting in its message containing data destined for the recipient server 5 and addressed to the relay node 4-1 an indicator defining or identifying the padding mode applied.

[0192] In another embodiment, in addition to the "main" connection established with the relay node 4-1 for transmitting data to the recipient server 5 in the context of the client device 2 accessing the service S, the scrambling instructions INST may include instructions for the client device 2 to establish one or more fake connections to the relay node 4-1 and / or via the relay node 4-1 (to one or more dedicated servers). The client device 2 then uses these fake connections to transmit "fake" data to the relay node 4-1 and / or one or more dedicated servers, in other words, this "fake" data is data that is strictly speaking not intended to be utilized ("consumed") by the relay node 4-1 and / or one or more dedicated servers but is only intended to scramble data going to the recipient server 5. Such instructions for establishing fake connections can be inserted into the appropriate parameters of the OPTION-DATA field of the EAO option and notified to the relay node 4-1 as described above for the filling instructions.

[0193] Of course, for the purpose of introducing noise around the connection of the client device 2 to the recipient server (the remote server 5 in the example envisaged here) and making it difficult to exploit information intercepted by a malicious entity placed on the path of the connection, the DNS server 3-1 may transmit other scrambling instructions to the client device 2. These other scrambling instructions are also notified to the relay node 4-1 so that they can be taken into account when receiving the scrambled message from the client device 2.

[0194] In the embodiment described here, the providing module 3C of the DNS server 3-1 provides two other elements of the plurality of elements AD ASTRA-ELTS inserted into the EAO option of the response REP-DNS, namely:

[0195] - an "AID" parameter, in which the providing module 3C of the DNS server 3-1 supplies the identifier of the relay node 4-1, whose address appears in the "Relay-Locator" parameter and which has been selected for the domain name "service-s.com" and the recipient server 5. If multiple relay nodes are selected, the "AID" parameter comprises the identifier of each of the selected relay nodes. As indicated above, there is no restriction on the form of the identifier in question: it can be an alias, a number, a domain name, a hash, etc.;

[0196] - "Partial Offload" parameter: If the client device 2 has indicated in the "Partial Offload" parameter of the EAO option of the request REQ-DNS that it supports the partial offload functionality, the DNS server 3-1 indicates in the "Partial Offload" parameter of the EAO option of its response REQ-DNS whether the relay node it has selected (relay node 4-1) is able to take over the subsequent DNS exchange of the client device 2 related to the request REQ-DNS (i.e., the "second" query within the meaning of the present invention), in other words, whether it supports the partial offload functionality. The providing module 3C may optionally add an additional indication to the "Partial Offload" parameter, which additional indication identifies the DNS query to which the partial offload functionality relates (e.g., a query related to a specific subdomain or any other filter to be submitted to the DNS system, such as the source of the DNS resource (domain name (e.g. "service.example.com"), service (SRV, such as "service._tcp.example.com"), etc.)). By way of illustration, in the example of a request REQ-DNS related to the domain name "service-s.com" envisaged here, the fact that the relay node 4-1 supports the "partial offload" functionality indicates to the client device 2 that it can send all its subsequent queries related to the subdomain "*.service-s.com" to the relay node 4-1. It should be noted that the fact that the relay node 4-1 supports the partial offload functionality does not necessarily mean that subsequent DNS queries sent by the client device 2 are directly processed (i.e. resolved) by the relay node 4-1. In fact, the relay node may be configured to address these queries to another trusted DNS server capable of resolving these queries.

[0197] As mentioned above, the various elements indicated by the DNS server 3-1 in the "Relay-Locator", "AID" and "Partial Offload" parameters constitute a plurality of elements AD ASTRA-ELTS, which are provided by the providing module 3C of the DNS server 3-1 to the client device 2. In the embodiment described here, in the EAO option, the plurality of elements are provided in the response REP-DNS to the request REQ-DNS. As a variant, all or some of the plurality of elements may be provided in one or more options or messages different from the response REP-DNS.

[0198] Then, the transmission module 3D of the DNS server 3 - 1 transmits a response REP-DNS including the EAO option to the client device 2 (step F90 ).

[0199] Reference again Figure 7 , the client device 2 (and more particularly its reception module 2B) receives the response REP-DNS to its request REQ-DNS prepared by the DNS server 3 - 1 (step E20 ).

[0200] The client device 2 extracts from the EAO option a plurality of elements AD ASTRA-ELTS present in the response REP-DNS, and more particularly the elements contained in the “Relay-locator”, “Padding”, “AID” ​​and “Partial offload” parameters of the option (step E30). It will be recalled that the use of an encrypted DNS transport to transmit these parameters advantageously guarantees the authenticity and integrity of the message carrying these parameters and therefore, incidentally, of the parameters received by the client device 2.

[0201] The receiving module 2B records the identifier AID in association with the corresponding IP resource (i.e. the domain name "service-s.com" here) in the local cache of the DNS client CL of the client device 2. If an entry for the same resource already exists in the cache, the DNS client CL replaces its content with the new AID supplied in the response REP-DNS. When sending subsequent DNS queries related to the request REQ-DNS, the DNS client CL provides the current content of the local cache to the "AID" parameter of the EAO option of these subsequent DNS queries.

[0202] If the client device 2 supports the partial offloading functionality (as is the case in the example envisaged here), the receiving module 2B also records in the local cache of the DNS client CL the information transmitted in the “partial offloading” parameter, i.e. all or some of the relay nodes indicated in the “relay-locator” parameter can be used for subsequent DNS queries related to the first request REQ-DNS, and, where applicable, records the additional indications provided by the DNS server 3-1 and identifying the relevant subsequent DNS queries (step E50). It should be noted that in the embodiment described here, the DNS server 3-1 supplies the “partial offloading” parameter in the EAO option of the response REQ-DNS only if the client device 2 supports the partial offloading functionality and notifies the DNS server 3-1 of this by setting the “partial offloading” parameter of the request REQ-DNS to 1.

[0203] The scrambling instructions INST (here the message padding instructions) contained in the "Padding" parameter are transmitted by the receiving module 2B to the application APP of the client device 2 at the source of the request REQ-DNS to resolve the domain name "service-s.com" so that it can execute (i.e. apply) the instructions before sending the message destined for the recipient server 5 to the relay node 4-1 indicated in the "Relay-Locator" parameter (step E60). To this end, the application APP includes an execution module 2C according to the invention. It should be noted that all the modules 2A to 2D of the client device 2 can be hosted in the application APP.

[0204] like Fig.10 , the message destined for the recipient server 5 contains payload data DATA exchanged by the application APP with the recipient server 5 when accessing the service S. As briefly mentioned above, these data are encrypted by the first encryption mechanism ENC1 according to the needs of the service S provided by the recipient server 5 and recorded in internal data packets denoted I-PKT (internal packet). Each internal data packet I-PKT is destined for the recipient server 5, i.e. its destination address (contained in Fig.10 In the header of the IP packet I-PKT (in the figure marked DEST) are the IP address @IP5 of the recipient server 5 and the port number P5 of the recipient server 5. This port number is here, for example, a port number defined by default (as a variant, it can be obtained in a manner known per se during the resolution of the domain name associated with the recipient server 5). The internal data packets I-PKT constitute data packets destined for the recipient server within the meaning of the invention. The application APP then applies, through its execution module 2C, the scrambling instructions INST recorded in the element AD ASTRA-ELTS to each internal data packet I-PKT containing data destined for the recipient server 5 (step E60). As mentioned above and Fig.10 As shown in , in the embodiment described here, the scrambling instruction INST is a filling instruction including at least one filling pattern PATT or a technique for generating such a pattern PATT. Therefore, the application APP adds filling bits or symbols according to one or more filling patterns PATT indicated in the filling instruction INST or generated by the execution module 2C by applying the generation technique indicated in the filling instruction INST. The application APP thus obtains a so-called scrambled data packet B-PKT, which is composed of an internal data packet I-PKT supplemented with the filling bits or symbols of the applied one or more filling patterns PATT.

[0205] It should be noted that in Fig.10 In the example shown in , the filling pattern PATT is inserted after the data DATA. However, this assumption itself is not restrictive; the filling pattern PATT can be inserted at other positions, or segmented and interleaved in the middle of the data DATA.

[0206] In the embodiment described here, the scrambled data packet B-PKT is then encrypted (where applicable, according to the encryption scheme applied between the client device 2 and the relay node 4-1, which is encrypted in Fig.10The scrambled message BM is obtained by the execution module 2C, which contains the IP address of the relay node 4-1 (or one of the relay nodes 4 supplied in the "Relay-locator" parameter) provided by the multiple elements ADASTRA-ELTS (indicated as @IP4-1) and its port number P4-1. This port number may be a port number defined by default or, as a variant, may have been recorded in the multiple elements ADASTRA-ELTS together with the address @IP4-1. The message BM obtained is, within the meaning of the invention, a scrambled message containing data destined for the recipient server 5 but addressed to the relay node 4-1, the message containing here the payload data DATA destined for the recipient server 5, the IP address @IP5 of the recipient server 5 and its port number P5 (usually referred to as the transport address of the recipient server 5), and the padding pattern PATT, which are all information items in encrypted form. Each scrambled message BM obtained by the execution module 2C is then sent by the sending module 2D of the client device 2 to the relay node 4-1 (step E70).

[0207] It should be noted that Fig.10 The scrambled message BM is only partially shown and is provided by way of illustration only for a better understanding of the present invention. Of course, such a message includes other elements, such as source IP address and port number (which may also be encrypted) and the like.

[0208] As a variant, as mentioned above, the scrambling instruction INST may include instructions for the client device 2 to establish one or more false connections to or via the relay node 4-1 in order to scramble a message addressed to the relay node 4-1 and containing data destined for the recipient server 5. According to this variant, the execution module 2C proceeds as described above: it inserts an internal data packet I-PKT into the message M in encrypted form (encrypted by the encryption mechanism ENC2), the internal data packet having the address @IP5 of the recipient server 5 as its destination address and including the payload data DATA destined for the recipient server 5 in a form encrypted by the encryption mechanism ENC1 (unless the scrambling instruction INST contains a padding instruction in addition to this instruction, no padding pattern is added). The destination address of the message M is the transmission address of the relay node, which transmission address includes its IP address @IP4-1 and its port number P4-1.

[0209] The message M thus formed is sent by the sending module 2D of the client device 2 to the relay node 4-1 in a manner known per se on the main connection established by the client device 2 to the relay node 4-1. In this variant embodiment, in addition to the main connection for addressing the message M to the relay node 4-1, the execution module 2C of the client device 2 also establishes one or more other false connections to the relay node 4-1 and / or via the relay node 4-1 to one or more dedicated servers according to the instruction INST. It sends a message FM containing false data (i.e., data that is not intended to be consumed or strictly utilized by the relay node 4-1 and / or the dedicated server) on these false connections and at the same time as sending the message M on the main connection. These false data are randomly generated, for example, by the execution module 2C.

[0210] The fake connection thus simulated by the execution module 2C is advantageously added to the main connection established between the client device 2 and the relay node 4-1. Thus, a malicious third-party entity cannot distinguish a message comprising payload data M destined for the recipient server 5 from a fake message FM sent simultaneously on the fake connection. Thus, the fake connection established by the client device 2 "scrambles" the message M (which, like the previous variant, is referred to hereinafter as the scrambled message BM) by means of a fake message FM sent simultaneously with the message M to the relay node 4-1 or via the relay node 4-1.

[0211] refer to Figure 8 , the relay node 4 - 1 receives each scrambled message BM sent by the client device 2 via its receiving module 4A (step G10 ).

[0212] The node 4-1 decrypts each scrambled message BM received and then removes, via its processing module 4B, the scrambling introduced by the execution module 2C of the client device 2 (step G20). In the embodiment described here, the scrambling introduced by the client device 2 is achieved by filling the internal data packet sent by the application APP with at least one filling pattern PATT provided in the instruction INST or generated using the generation technique recorded in the instruction. In addition, in the notification step F80 / step G00, these one or more filling patterns PATT or the generation techniques used to generate them are transmitted by the DNS server 3-1 to the relay node 4-1. Obtaining these one or more filling patterns PATT or the techniques used to generate them itself constitutes a step of obtaining information related to the scrambling instruction INST applied by the client device 2 within the meaning of the present invention.

[0213] Of course, other ways can be envisaged for the relay node 4-1 to obtain information representative of the scrambling instructions INST applied by the client device 2. For example, the scrambling mode may be explicitly indicated by the client device in the scrambled packet itself, as mentioned above.

[0214] Thus, in the embodiment described herein, removing the scrambling introduced by the execution module 2C of the client device 2 comprises removing, for the processing module 4B, the padding bits / symbols corresponding to one or more padding patterns PATT that have been received from the DNS server 3-1 or generated using a generation technique received from the DNS server 3-1. Thus, it obtains an inner data packet I-PKT destined for the recipient server 5.

[0215] In a variant in which the scrambling instructions INST include instructions for establishing a fake connection, the processing module 4B can locally terminate the fake connection established with it (or relay the message FM to one or more dedicated servers where applicable) and extract the inner data packet I-PKT from the message M received on the main connection after decrypting the packet.

[0216] like Fig.11 As schematically shown in the figure, the processing module 4B replaces the source IP address and port number (represented as @IP2 and P2, respectively) of the client device 2 located at the source of the internal data packet I-PKT with its external IP address and its external source port number (represented as @IP4-1_e and P4-1_e, respectively) (or any other identifier used by the transmission protocol, such as the identifier int-VTag or rem-VTag of the SCTP protocol) in each obtained internal data packet I-PKT. It stores the source port number P2 and the source IP address @IP2 of the client device 2 in a local table in its non-volatile memory NVM. Then, it transmits the obtained data packet to the receiving server 5 in a manner known per se (step G30). For the sake of simplicity, it will be considered here that the obtained data packet is directly transmitted to the receiving server 5 (without any intermediary between the relay node 4-1 and the receiving server 5). However, this assumption itself is not restrictive, and the present invention is also applicable to transmitting data packets to the receiving server 5 via one or more other relay nodes.

[0217] Similarly, for simplicity, the same port number P2 is considered here for the message BM and the internal data packet I-PKT of the client device. However, the client device 2 may use a different port number.

[0218] In a particular embodiment, the relay node 4-1 adds scrambling before transmitting the data packet I-PKT to the recipient server 5. For this purpose, it can in particular establish a fake connection to a dedicated server or to another ("real") server, as described above for the client device 2. Such scrambling introduced between the relay node 4-1 and the recipient server 5 is particularly advantageous, in particular when the number of client devices using the same relay node 4 is less than a given threshold.

[0219] It will be assumed here that the receiving server 5 responds to at least one of the data packets I-PKT received from the client device 2 via the relay node 4-1 by a so-called "return" data packet (denoted as R-PKT), and the payload data contained in the "return" packet is encrypted according to the needs of the service S by the encryption mechanism ENC1.

[0220] The return data packet R-PKT is sent by the receiving server 5 to the relay node 4-1 according to the source port number and IP address indicated in the internal data packet I-PKT received from the relay node 4-1. When the relay node 4-1 receives the return packet R-PKT (step G40), the processing module 4C replaces its external port number P4-1_e and its external IP address @IP4-1_e in the destination address of the return data packet R-PKT with the port number P2 and IP address @IP2 of the client device 2. In addition, it scrambles the return data packet R-PKT by applying the same type of scrambling as that applied by the client device 2 according to the scrambling instruction INST to the return data packet R-PKT thus modified. In the example envisaged here, the processing module 4C thus applies one or more scrambling patterns PATT notified by the DNS server 3-1 in step F80 / G00 (or generated using a generation technique provided by the DNS server 3-1) (step G50), and then encrypts the obtained scrambled return data packet as a whole (i.e. including its header) according to the encryption scheme ENC2 used between the relay node 4-1 and the client device 2. The processing module 4C inserts the encrypted scrambled return data packet thus obtained into a return message whose destination address is the IP address of the client device 2 (extracted from the local table of the relay node 4-1). The obtained scrambled return message B-MR is then transmitted by the relay node 4-1 to the client device 2 (step G60).

[0221] In a variant embodiment ( Fig.11 (not shown), before scrambling and encryption, the processing module 4C also replaces the source port number P5 and IP address @IP5 of the receiving server 5 with its port number P4-1 and its IP address @IP4-1 (which can be said to be "inside" relative to the visible external port number P4-1_e and IP address @4-1_e of the receiving server 5) in the return data packet R-PKT.

[0222] When the client device 2 receives the encrypted return message B-MR (step E80), the client device decrypts it, then removes the scrambling introduced by the relay node 4-1 (by removing the bits / symbols added according to one or more padding patterns PATT) and accesses the return data packet R-PKT sent by the recipient server 5 (step E90).

[0223] Of course, other internal data packets and return data packets can be exchanged in a similar or identical manner between the client device 2 and the recipient server 5 via the relay node 4-1 or via another relay node 4 designated by the DNS server 3-1 for the client device 2 and the recipient server 5, and supplied in the "relay-locator" parameter of the response REP-DNS.

[0224] It will now be assumed that a new name resolution request REQ'-DNS is sent as part of a client device 2 accessing a service S and that this new request REQ'-DNS is related to a previously sent request REQ-DNS (e.g. it is related to the resolution of a name of a subdomain of the domain to which the request REQ-DNS relates).

[0225] If the client device 2 supports the partial offloading function (the "partial offloading" parameter in the request REQ-DNS is set to 1), and if the DNS server 3-1 indicates the relay node 4-1 in the "partial offloading" parameter of its response REQ-DNS, the client device 2 addresses the new request REQ'-DNS directly to the relay node 4-1, such as Fig.12 A. The same applies to all subsequent name resolution queries (REQ"-DNS, etc.) connected to the request REQ-DNS. It should be noted that the resolution of subsequent queries may result in the recipient server 5' being different from the recipient server 5, such as Fig.12 As shown in A.

[0226] If the client device 2 does not support the partial offloading function (the "partial offloading" parameter in the request REQ-DNS is set to 0), the client device 2 continues to use the DNS server 3-1, such as Fig.12 B. This also applies if the new DNS request REQ'-DNS is not related to the request REQ-DNS, including when the client device 2 supports partial offloading functionality.

[0227] In the embodiments described here, DNS exchanges between the client device 2, one or more DNS servers 3 and the relay node 4 have been considered. However, the present invention is applicable to any type of name to be resolved, regardless of the format, and not only to domain names as defined in document RFC 1034. Therefore, everything described above with reference to domain names is applicable to the resolution of any name of an IP resource.

Claims

1. A method for processing a first name resolution request (REQ-DNS) from a client device (2), the method being implemented by a name resolution server (3-1) and comprising sending (F90) to the client device a response (REP-DNS) to the first request, the response comprising at least one item of information (@IP5) relating to a server (5) referred to as a recipient server, resulting from the resolution of the first request, the method being characterized in that the method further comprises sending (F90) to the client device a plurality of elements (AD ASTRA-ELTS), the plurality of elements comprising: - at least one address of at least one relay node (4-1) selected (F60) by the name resolution server, to which the client device must address all or some of its messages containing data destined for the recipient server; as well as - at least one scrambling instruction (INST) to be applied by the client device to said message before addressing said message to said at least one relay node.

2. The processing method according to claim 1, wherein: At least one of the relay nodes (4-1) selected by the name resolution server satisfies at least one of the following conditions: - preventing association between the relay node and the recipient server; and / or - maximizing the number of client devices using the relay node; and / or - optimizing client devices using said relay node according to at least one given criterion; and / or -Having a route from the relay node to the recipient server.

3. The processing method according to claim 1 or 2, wherein: The at least one scrambling instruction (INST) comprises padding instructions for padding the message before addressing the message to the at least one relay node, the instructions comprising at least one padding pattern (PATT) to be used by the client device to scramble the message or a technique for generating at least one such padding pattern.

4. A communication method implemented by a client device (2), the communication method comprising receiving (E20) from a name resolution server (3-1) a response (REP-DNS) to a first name resolution request (REQ-DNS) sent by the client device, the response comprising at least one item of information (@IP5) related to a server (5) referred to as a receiving server, generated by resolving the first request, the communication method being characterized in that the method further comprises: - receiving (E20) a plurality of elements from the name resolution server, the plurality of elements comprising: o at least one address of at least one relay node (4-1) selected by the name resolution server, to which the client device must address all or some of its messages containing data destined for the recipient server; and o at least one scrambling instruction (INST) to be applied by the client device to the message before addressing the message to the at least one relay node; - Applying (E60) said at least one scrambling instruction to said message.

5. The communication method according to claim 4, wherein: The at least one scrambling instruction (INST) comprises a padding instruction for padding the message, and applying (E60) the at least one scrambling instruction comprises padding at least one of the messages using a padding pattern (PATT) provided in the padding instruction or generated by a generation technique provided in the padding instruction.

6. The communication method according to claim 4 or 5, wherein: The at least one scrambling instruction (INST) comprises instructions for establishing at least one false connection with and / or via the at least one relay node.

7. The method according to any one of claims 1 to 6, wherein: Said message addressed to said at least one relay node comprises, in encrypted form, data destined for the recipient server and the address of said recipient server.

8. The method according to any one of claims 1 to 7, wherein: The plurality of elements (ADASTRA-ELTS) further comprises a first indication that at least one of the relay nodes can be used by the client device to send at least one second name resolution request related to the first request.

9. The method of claim 8, wherein: The plurality of elements (AD ASTRA-ELTS) further includes a second indication identifying a name resolution query to which the first indication relates.

10. The method according to any one of claims 1 to 9, wherein: The plurality of elements (ADASTRA-ELTS) further comprises at least one identifier (AID) of the at least one relay node selected by the name resolution server.

11. The method according to any one of claims 1 to 10, wherein: The first request (REQ-DNS) comprises at least one identifier (AID) of at least one relay node previously selected for the client device and to which the client device addresses all or some of its messages comprising data destined for the recipient server.

12. The method of claim 11, wherein: At least one of the relay nodes selected by the name resolution server is consistent with the relay node identified in the first request.

13. The method according to any one of claims 1 to 12, wherein: All or some of said plurality of elements (ADASTRA-ELTS) are sent to or received by the client device in said response (REP-DNS) to the first request.

14. The method according to any one of claims 1 to 13, further comprising a step (F90) of notifying the at least one relay node of at least one item of information related to the at least one scrambling instruction.

15. A method for processing a message, the method being implemented by a relay node (4-1) selected by a name resolution server (3-1) for a client device (2) and a server (5) referred to as a recipient server, the method comprising: - obtaining (G00) at least one item of information relating to at least one scrambling instruction (INST) applied by the client device to messages comprising data destined for the recipient server before addressing them to the relay node; - upon receiving (G10) at least one scrambled message comprising data destined for the recipient server and addressed by the client device to the relay node, removing (G20) the scrambling applied by the client device using said acquired at least one item of information; as well as - transmitting (G30) said at least one message obtained after removing the scrambling to the recipient server.

16. The processing method as described in claim 15 also includes, when receiving (G40) at least one message from the receiving server and including data destined for the client device, scrambling (G50) the at least one message before transmitting the at least one message to the client device.

17. A name resolution server (3-1), the name resolution server being configured to send a response to a first name resolution request from a client device, the response comprising at least one item of information related to a server referred to as a receiving server generated by resolving the first request, the server being characterized in that the server is further configured to send a plurality of elements to the client device, the plurality of elements comprising: - at least one address of at least one relay node selected by the name resolution server, to which the client device must address all or some of its messages comprising data destined for the recipient server; as well as - at least one scrambling instruction to be applied by the client device to said message before addressing said message to said at least one relay node.

18. A client device (2), the client device being configured to receive, from a name resolution server, a response to a first name resolution request sent by the client device, the response comprising at least one item of information related to a server referred to as a receiving server generated by resolving the first request, the client device being characterized in that the client device is further configured to: - receiving a plurality of elements from the name resolution server, the plurality of elements comprising: o at least one address of at least one relay node selected by the name resolution server to which the client device must address all or some of its messages including data destined for the recipient server; as well as o at least one scrambling instruction to be applied by the client device to said messages addressed to said at least one relay node; - applying said scrambling instructions to said message.

19. A relay node (4-1) in a communication network, the relay node being selected by a name resolution server for a client device and a recipient server, the relay node being configured to: - obtaining at least one item of information relating to at least one scrambling instruction applied by the client device to messages comprising data destined for the recipient server before addressing the messages to the relay node; - upon receiving at least one scrambled message comprising data destined for the recipient server and addressed by the client device to the relay node, using said acquired at least one item of information to remove the scrambling applied by the client device; as well as - transmitting said at least one message obtained after removing the scrambling to the recipient server.

20. A system (1) in a communication network, the system comprising: - A client device (2) as claimed in claim 18; - A name resolution server (3-1) as claimed in claim 17; as well as - at least one relay node (4-1) selected by the name resolution server for the client device as claimed in claim 19.

Images