Methods for name resolution, communication, message processing and server, corresponding 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). It comprises sending, to the client device (2), a response to the first request comprising at least one piece of information relating to a so-called recipient server (5) resulting from a resolution of 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 its messages containing data intended for the recipient server; and - at least one scrambling instruction to be applied by the client device to the messages before addressing them to the at least one relay node.

Description

Description NAME RESOLUTION, COMMUNICATION, MESSAGE PROCESSING METHODS AND CORRESPONDING SERVER, CLIENT DEVICE AND RELAY NODE Prior art

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

[0002] It concerns more specifically communications with a domain name resolution server (or DNS for “Domain Name System” in English) in a telecommunications network, such as for example an IP network (for “Internet Protocol” in English).

[0003] The DNS system is a fundamental component in the provision of IP services. Indeed, it allows a resource (such as a domain name, a URI (for "Uniform Resource Identifier"), etc.) to be associated with one or more IP addresses that allow a device (such as a terminal) to access this resource.

[0004] For example, a server reachable in IPv4 publishes a DNS record (or RR for "Resource Record" in English) of type "A" to the DNS system, while a server reachable in IPv6 publishes a DNS record of type "AAAA" (or "Quad A Resource Record" in English); a server reachable in IPv4 and IPv6 publishes both types of record.

[0005] When a device wishes to establish communication with a so-called "recipient" server identified by a domain name (or FQDN for "Fully Qualified Domain Name" in English), the DNS client embedded in the device sends a domain name resolution request (called a DNS request) to a server in the DNS system (or DNS server for the sake of simplification) specifying in the request the desired record type (A or AAAA). A device supporting both IPv4 and IPv6 protocols sends two DNS requests to a DNS server (one indicating an A record type, the other an AAAA record type).

[0006] Upon receiving this query, the DNS server responds to the device by sending it at least one IP address associated with the domain name to which the query relates if an entry corresponding to this domain name is available. If it does not have such an entry, the DNS server relays the query to another server according to the DNS hierarchy known to those skilled in the art. The response received from this other server is then relayed by the DNS server initially requested to the device that originated the DNS query. The device extracts the IP address or addresses contained in the response and establishes communication with the destination server, typically using one of these IP addresses.

[0007] These exchanges between the device and the DNS server (hereinafter referred to as "DNS communications" for the sake of simplification) are conventionally implemented in clear text, using a mode called Do53 (or "unencrypted DNS"). This unencrypted mode makes it possible for entities located along the DNS communications path to access sensitive information, for example for profiling purposes. Do53 therefore presents a risk of harming users' privacy.

[0008] In order to improve the level of confidentiality of DNS communications and restrict access to sensitive information carried by these DNS communications to only authorized or consented entities, numerous mechanisms have been specified to encrypt DNS communications. 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, an entity located in the DNS communications path can associate the destination address of data packets sent after a DNS exchange with a given server or service using so-called statistical analysis techniques (or "statistical analysis in English), and thus obtain potentially sensitive information about users. A 2019 study by APNIC (for "Asia Pacific Network Information Centre" in English) looked at the information that can be extracted from a set of IP addresses contacted by a user device. This study shows in particular that the majority of websites have a unique page load fingerprint or PLF (for "Page Load Fingerprint" in English); there is therefore a risk that a website visited by a user could be identified from the IP addresses targeted by their user device. This results in limited protection of user privacy by the aforementioned encrypted DNS mechanisms. Statement of the invention

[0009] The invention notably improves the aforementioned situation by proposing a method for processing a first name resolution request originating from a client device, this method being implemented by a name resolution server and comprising sending to the client device a response to the first request comprising at least one piece of information relating to a so-called recipient server resulting from a resolution of the first request. The processing method is remarkable in that it further comprises sending to the client device a 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 part of its messages containing data intended for the recipient server; and at least one scrambling instruction to be applied by the client device to said messages before addressing them to said at least one relay node.

[0010] Correlatively, the invention also relates to a name resolution server configured to send a response to a first name resolution request originating from a client device, this response comprising at least one piece of information relating to a so-called recipient server resulting from a resolution of the first request. The name resolution server is remarkable in that it is further configured to send to the client device a 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 part of its messages containing data intended for the recipient server; and at least one scrambling instruction to be applied by the client device to said messages before addressing them to said at least one relay node.

[0011] The invention also relates to a communication method implemented by a client device, comprising a reception, from a name resolution server, of a response to a first name resolution request sent by the client device, this response comprising at least one piece of information relating to a so-called recipient server resulting from a resolution of the first request.The communication method is remarkable in that it further comprises: a reception of a plurality of elements, originating from the name resolution server, 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 part of its messages containing data intended for the destination server; and o at least one scrambling instruction to be applied by the client device to said messages before addressing them to said at least one relay node; and an application of said scrambling instruction to said messages.

[0012] Correlatively, the invention also relates to a client device configured to receive, from a name resolution server, a response to a first name resolution request sent by the client device, this response comprising at least one piece of information relating to a so-called recipient server resulting from a resolution of the first request. The client device is remarkable in that it is further configured to: receive a plurality of elements, from the name resolution server, 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 part of its messages containing data intended for the recipient server; and o at least one scrambling instruction to be applied by the client device to said messages before addressing them to said at least one relay node; and apply said scrambling instruction to said messages.

[0013] According to yet another aspect, the invention also relates to a method for processing messages implemented by a relay node selected by a name resolution server for a client device and a destination server, this method comprising: an acquisition of at least one information relating to at least one scrambling instruction applied by the client device to messages containing data intended for the destination server before sending them to the relay node; upon receipt of at least one scrambled message containing data intended for the destination server and sent to the relay node by the client device, a deletion, using said at least one acquired information, of the scrambling applied by the client device; and a transfer of said at least one message obtained after deletion of the scrambling to the destination server.

[0014] Correlatively, the invention also relates to a relay node in a communications network selected by a name resolution server for a client device and a destination server, this relay node being configured to: acquire at least one piece of information relating to at least one scrambling instruction applied by the client device to messages containing data intended for the destination server before addressing them to the relay node; upon receipt of at least one scrambled message containing data intended for the destination server and addressed to the relay node by the client device, remove, using said at least one piece of acquired information, the scrambling applied by the client device; and transfer said at least one message obtained after removing the scrambling to the destination server.

[0015] The invention therefore proposes a solution that makes it possible to prevent access to sensitive information by equipment that is close to the client device (from the point of view of the network topology). Thus, the solution applies particularly at the level of the access network used by a client device (e.g. public or private WLAN (“Wireless Local Area Network”), mobile network, etc.) by relying on a plurality of network entities (name resolution server(s), relay node(s), to prevent malicious actions likely to be implemented 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 remainder of this document.The invention has a preferred but non-limiting application when the communications in question are encrypted; no limitation is attached to the encryption scheme then envisaged for transporting the messages exchanged during these communications (for example, for DNS, DoT, DoD, DoQ, DoH, DoC communications).

[0016] Similarly, no limitation is imposed on the nature of the client device (which may be, for example, a terminal, a CPE (for “Customer Premises Equipment” in English), a decoder of the STB type (for “Set Top Box” in English), etc.), nor on that of the relay node selected by the name resolution server (which may be, in particular, a server, a router, etc.).

[0017] The solution proposed by the invention is based more particularly on the selection, by a trusted name resolution server requested by the client device when it wishes to access a given service, typically provided by a so-called recipient server, of at least one relay node via which the client device will interact with the recipient server. Several relay nodes can be advantageously used during communication with a 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 can give rise to one or more communications with one or more recipient servers. Communications with these different recipient servers can be managed with one or more relay nodes.

[0018] More specifically, in accordance with the invention, the client device addresses the messages containing the data that it intends for the recipient server (in other words containing the data that it wishes to send to it as part of accessing the service) to a relay node, which is then responsible for relaying them to the recipient server. The introduction of a relay node between the client device and the recipient server has the effect of masking the true recipient (namely the recipient server) of the data sent by the client device when it accesses the service, since the address to which the messages are sent is that of the relay node and not that of the recipient server, in accordance with the invention. The address of the recipient server is, for its part, concealed in the content of the messages addressed to the relay node, for example in encrypted form by means of an encryption mechanism shared with the relay node.This makes the identity of the recipient server inaccessible in the event of interception of messages between the client device and the relay node, while still allowing the relay node to relay these messages to the recipient server.

[0019] For example, in a particular embodiment, the messages addressed to said at least one relay node comprise, in encrypted form, data intended for the recipient server and an address of the recipient server.

[0020] These provisions thus make it difficult or even impossible for a malicious entity located between the client device and the relay node to obtain, by statistical analysis of the traffic from the client device and / or by establishing and analyzing a page loading fingerprint, information revealing the practices of the user of the client device and likely to infringe on their privacy.

[0021] Similarly, the introduction of a relay node between the client device and the destination server makes it possible to mask the true source of the messages (i.e. the identity of the client device), in the event of interception and inspection of these messages by a malicious entity located beyond the relay node (in the direction from the client device to the destination server).

[0022] This difficulty in obtaining sensitive data through statistical analysis of traffic is increased when the use of one (or more) relay node(s) is combined with one or more (additional) jamming actions implemented by the client device (possibly supplemented by jamming actions implemented by the relay node(s). These jamming actions are transmitted in the form of jamming instructions to the client device by the resolution server and can be of different natures.

[0023] For example, in a particular embodiment of the method for processing the first request, said at least one scrambling instruction transmitted by the name resolution server to the client device comprises an instruction for stuffing (or filling or "padding" in English) the messages containing data intended for the recipient server before sending them to said at least one relay node, this instruction comprising at least one stuffing pattern to be used by the client device to scramble said messages or a technique for generating at least one such stuffing pattern.

[0024] Correlatively, in a particular embodiment of the communication method, said at least one scrambling instruction comprises an instruction for stuffing said messages and the application of said at least one scrambling instruction to said messages comprises stuffing at least one said message containing data intended for the recipient server and addressed to the relay node using a stuffing pattern provided in said stuffing instruction or generated by means of a generation technique provided in said stuffing instruction.

[0025] By way of illustration, a message stuffing instruction may consist, in the context of a voice-type communication service based on the exchange of small data packets between the client device and the destination server, of increasing the length of the data packets sent to the relay node by the client device and intended for the destination server by using a determined stuffing pattern, provided by the name resolution server, or generated by the client device according to a stuffing pattern generation technique provided by the name resolution server.

[0026] The padding of messages by the client device makes it possible to standardize the profile of the messages sent by the client device and thus to standardize the traffic leaving the client device. To strengthen the protection of the data carried by the messages sent to the relay node, as mentioned above, the data, the padding pattern completing this data, and the address of the destination server can be encrypted before being sent to the relay node. This also makes it possible to guarantee 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 particular embodiment, it is possible to envisage activating encryption by default for sending this critical information (e.g. for the scrambling pattern).

[0027] Other actions for scrambling messages before they are sent to the relay node may be considered in addition to or instead of the above-mentioned actions.

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

[0029] Such a dummy connection is established in parallel with the connection used by the client device to transmit to the relay node the messages intended for the destination server (hereinafter referred to as the “main connection”). It may terminate at the relay node or be relayed by the latter to a dedicated server (i.e., capable of establishing and managing a dummy connection appropriately and with full knowledge of the facts). The client device may be configured to transmit on this dummy connection dummy data, i.e., data that is not intended to be “consumed” (i.e., exploited, used) by the relay node and / or by the dedicated server that receives it. Similarly, any dummy application data transmitted by the dedicated server is not consumed by the relay and / or by the client device.

[0030] In a particular embodiment, the method for processing a first name resolution request or the communication method may further comprise a step of notifying said at least one relay node of at least one piece of information relating to said at least one scrambling instruction.

[0031] This notification of the relay node by the name resolution server or the client device allows the relay node to easily identify and remove the scrambling applied to the scrambled messages from the client device before their transmission to the destination server.

[0032] The information notified to the relay node may include the scrambling instruction itself, as directed by the name resolution server to the client device, or only certain representative elements of this scrambling instruction, sufficient to enable the relay node to be able to remove the scrambling introduced by the client device. For example, in the case of a message stuffing instruction, the information in question, when notified to the relay node by the client device, may be an indicator delimiting or identifying the stuffing pattern contained in a message (for example, such an indicator may include a bit or symbol offset).

[0033] Obfuscation actions ordered by the name resolution server are advantageously taken into account by the relay node when it receives scrambled messages from the client device containing data intended for the destination server, in order to identify and then remove the jamming introduced by the client device before relaying the messages to the destination server.

[0034] The relay node may also, upon receipt of at least one message from the destination server and containing data intended for the client device, apply scrambling to said at least one message before transferring it to the client device, transparently for the destination server.

[0035] The interference introduced by the relay node may be equivalent to that applied by the client device (i.e. of the same nature, for example based on the same padding patterns). This mode is called "symmetric jamming mode".

[0036] Alternatively, the jamming introduced by the relay node may be different from that 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 emulation of dummy connections may be performed 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 "asymmetric jamming mode". This difference in the jamming actions applied makes it possible to take into account the asymmetric nature of the traffic volume depending on its direction. Indeed, a larger quantity of useful data is generally transmitted in the relay node to client device direction.These data may present, for a given application, constant profiles over time and thus be used for profiling purposes (and therefore traceability / * tracking”) of the user. Consequently, the application of adequate scrambling in each of the two directions of communication allows more effective protection of sensitive information relating to the client device or its user.

[0037] Furthermore, 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 (for example, messages sent in the client device to relay node direction may not contain as much data as in the reverse direction).

[0038] Thanks to the jamming introduced by the client device, and possibly by the relay node, it is difficult or even impossible for a malicious third-party entity to deduce / extract / extrapolate information about the traffic coming from and / or going to the client device. Combined with the intervention of the relay node acting as an intermediary between the client device and the destination server, it is possible to eliminate the implementation of statistical analyses by malicious third-party entities present in the networks involved in the routing of DNS traffic or at least to reduce the scope of such statistical analyses and to limit the relevance of the information that is obtained from such statistical analyses.

[0039] The invention therefore makes it possible to guarantee the confidentiality of communications established by client devices, and contributes to better preserving the privacy of users of these client devices and to limiting the risks of user profiling. Network operators can incidentally, by means of the invention, offer 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 those to whom the operators provide network connectivity.

[0040] As mentioned previously, the purpose of introducing a relay node between the client device and the destination server is to hide the true recipient of the messages sent by the client device, as well as the true source of these messages (when an undue inspection of the messages takes place beyond the relay node), making it difficult to implement statistical analysis of the traffic originating from the client device. This difficulty can be increased through a judicious choice of the relay node(s) to use by a client device. For example, at least one said relay node may be selected by the name resolution server such that the relay node satisfies at least one of: preventing correlation between that relay node and the destination server (e.g., the same relay node may be used for several distinct destination servers, or different relay nodes may be selected for the same client device and the same destination server but for different communications between the client device and the destination server); and / or maximizing the number of client devices using said relay node. These criteria help limit the risk of tracing communications aimed at name resolution (e.g. DNS communications) by a malicious entity.

[0041] Other conditions to be verified may be considered when selecting a relay node for a client device and a destination server, 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 be a matter of operator know-how and / or relay node engineering / configuration). In yet another example, a relay node may be selected because it satisfies a condition of (already) having a route to the destination server.

[0042] It should be noted that the criteria mentioned above are not exclusive; that is, the name resolution server can consider several criteria simultaneously to select a relay node for the client device and the destination server.

[0043] 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 a first indication that at least one said relay node can be used by the client device to send at least one second name resolution request correlated to the first request.

[0044] In other words, not only is the relay node in question used by the client device to transmit messages to the destination server, but it is also responsible for resolving all or part of the client device's future name resolution queries correlated with the first query, for example, relating to a name in a subdomain of a domain name to which the first query related. This allows for an additional degree of obfuscation to be introduced, by making it difficult for a malicious entity to establish a link between a particular name resolution server and a client device. Furthermore, each name resolution server involved in the client device's communication with the destination server has only partial knowledge of the queries issued by the client device.

[0045] It may be contemplated to introduce a degree of granularity into the name resolution requests directed to a relay node. Thus, 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) may further comprise a second indication identifying the name resolution requests affected by the first indication.

[0046] 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 said at least one relay node selected by the name resolution server.

[0047] This embodiment has several advantages.

[0048] First, it allows for handling situations where multiple relay nodes may be reachable using the same IP address. The identifier transmitted in the plurality of elements allows the client device to distinguish a particular relay node from among the plurality of relay nodes sharing the same IP address.

[0049] In addition, the transmission of the identifier of the relay node selected by the name resolution server makes it possible to avoid having to maintain at the level of the name resolution server states associating one or more relay nodes with each client device contacting it (in this case we speak of a stateless name resolution server).

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

[0051] It should be noted that the relay node in question may have been selected for the client device and for the same destination server (typically for the same communication with this destination server), by the name resolution server to which the client device addresses the first request or by another name resolution server. The insertion of the identifier of the relay node currently in use by the client device allows the name resolution server to which the first request is addressed, depending on the strategy adopted, either to reselect the same relay node (i.e. at least one said relay node selected by the name resolution server coincides with a relay node identified in the first request), for example to exploit an existing connection, or on the contrary, to knowingly select a different relay node, so as to make it even more difficult to trace the communications of the client device.In the latter case, it is indeed more difficult to correlate the recipient server with the identity of the relay included in the first request.

[0052] Furthermore, this embodiment makes it possible to limit the information stored by the name resolution server (no state maintenance required, as explained previously), which reinforces the security of the mechanism implemented by the invention and limits the risks of tracing the client device based on its DNS communications.

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

[0054] This embodiment allows the invention to be applied without delay from the first resolution request. In addition, it advantageously allows the signaling required between the name resolution server and the client device to be limited to implement the invention.

[0055] It should be noted that the use of the adjectives "first" and "second" is only intended to distinguish two successive, interrelated name resolution requests, for example, a request for a domain name and a subsequent request for a subdomain of that domain name. This use does not presuppose the absence of DNS exchanges or, more generally, prior name resolution between the client device and the name resolution server, for example, the sending by the client device and the resolution by the name resolution server of a request for another domain name.

[0056] In one embodiment, the sending of said plurality of elements by the name resolution server to the client device is conditioned by a detection by the name resolution server of a determined option in the first request.

[0057] This embodiment offers the user of the client device the possibility of choosing whether or not he wishes to benefit from the protection mechanism proposed by the 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 invention. Conversely, if the network is not a trusted network, the user can decide to use the invention. It should be noted that this deactivation can also be carried out by the client device itself, automatically, that is to say without user intervention, in a transparent manner for the user.

[0058] In a particular embodiment, the methods of processing a (first) request and messages, and / or communication are implemented by a computer.

[0059] The invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a name resolution server in accordance with the invention and comprising instructions adapted to the implementation of a method for processing a first name resolution request as described above.

[0060] The invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a client device in accordance with the invention and comprising instructions adapted to the implementation of a communication method as described above.

[0061] The invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a relay node in accordance with the invention and comprising instructions adapted to the implementation of a message processing method as described above.

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

[0063] The invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.

[0064] The information or recording medium may be any entity or device capable of storing programs. For example, the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a hard disk, or a flash memory.

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

[0066] The program according to the invention can in particular be downloaded from an Internet-type network.

[0067] Alternatively, the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the processing and communication methods according to the invention.

[0068] According to another aspect, the invention also relates to a system in a communications network comprising: a client device according to the invention; a name resolution server according to the invention; and at least one relay node according to the invention selected by the name resolution server for said client device.

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

[0070] It may also be envisaged, in other embodiments, that the processing and communications methods, the name resolution server, the client device, the relay node and the system according to the invention have in combination all or part of the aforementioned characteristics. Brief description of the drawings

[0071] Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate an exemplary embodiment thereof without any limiting character. In the figures: [Fig. 1] Figure 1 represents, in its environment, a system in a network according to the invention, in a particular embodiment; [Fig. 2] Figure 2 schematically represents the hardware architecture of a computer capable of host any of the entities according to the invention belonging to the system of figure 1; [Fig. 3] Figure 3 represents the functional modules of a name resolution server of the system of Figure 1, in accordance with the invention; [Fig. 4] Figure 4 represents the functional modules of a client device of the system of Figure 1, according to the invention; [Fig. 5] represents the functional modules of a relay node of the system of Figure 1, in accordance with the invention; [Fig. 6] Figure 6 represents in flowchart form the main steps of a method for processing a name resolution request as implemented by the name resolution server of Figure 3; [Fig. 7] Figure 7 represents in flowchart form the main steps of a communication method as implemented by the client device of Figure 4; [Fig. 8] Figure 8 represents in flowchart form the main steps of a message processing method as implemented by the relay node of Figure 5; [Fig. 9] Figure 9 includes Figures 9A and 9B respectively representing an EAO option (for "EDNS (Extension Mechanisms for DNS) ASTRA (A DNS-driven Guard Against STatistical Trafic Analysis) Option") that can be used in a name resolution query and in the response to this query to implement the invention, in a particular embodiment; [Fig. 10] Figure 10 illustrates in a partial and schematic manner a scrambled message addressed to the relay node of Figure 5 and containing data intended for the recipient server of Figure 1; [Fig. 11] Figure 11 schematically illustrates the changes in port numbers and source and destination addresses made by the relay node of Figure 5, in a particular embodiment; and [Fig. 12] Figure 12 includes Figures 12A and 12B representing the exchanges between the entities of System 1 of the figure depending on whether or not the client device of the system supports the “partial-offload” function. Description of the invention

[0072] Figure 1 represents a system 1 in an NW communications network, according to the invention, in a particular embodiment. No limitation is imposed as to the nature of the NW communications network, the latter being able to comprise one or more sub-networks, such as for example one or more access (sub-)networks (for example a public or private network of the WLAN type, a mobile network, etc.), the Internet network, etc.

[0073] In accordance with the invention, the system 1 comprises: a client device 2, in accordance with the invention. In the example of Figure 1, the client device 2 is a terminal of a user U such as a mobile telephone (for example of the “smartphone” type), connected to a public WLAN network AN 1 and to a mobile access network AN2 via which it can access the Internet network. The invention of course applies to other fixed or mobile client devices (for example to a decoder such as an STB, a CPE, etc.), as well as to other networks (wired, wireless, etc.), the client device 2 being able to be connected simultaneously to one or more access networks, directly or via intermediate equipment such as a CPE; at least one trusted name resolution server for the client device 2 (typically, considered as such by the user U of the client device 2), in accordance with the invention, and generally referenced by 3.In the example of Figure 1, two trusted servers 3 conforming to the invention are considered for illustrative purposes. These servers 3-1 and 3-2 are, for illustrative purposes, domain name resolution servers as defined by the IETF RFC 1034 document. November 1987, also commonly referred to as DNS servers. The invention may, however, be applied in the context of resolving other IP resources generally referred to in this document as "names", such as URIs, etc.; and at least one relay node 4-1, 4-2, etc. in accordance with the invention, more generally referred to as 4 and interfacing with the name resolution servers 3, for example using the RESTCONF protocol described in IETF RFC 8040, January 2017. Of course, other protocols may be considered as a variant for this interface.

[0074] In the embodiment described here, the mechanism proposed by the invention, referred to hereinafter as the AD ASTRA procedure or mechanism (for "Advanced DNS-driven protection Against Statistical TRaffic Analysis" in English), is activated when the client device 2 uses, to access the Internet network and more particularly any service S (e.g. voice communication service, web service, etc.) hosted or provided by a remote server 5 associated with (i.e. identified by) a given domain name (for example, for illustrative purposes, "service-s.com"), an access network which is not a trusted network for the client device 2. Such a network, called "Untrusted" in English, is for example a public network such as the public WLAN network AN1, or a "visitor" network such as a hotel, bar, city network, etc.It presents a risk for the client device 2 in that its communications, in particular with a local DNS server 6 of the network in question, may be intercepted by a malicious third-party entity and, where appropriate, exploited by this entity, for example by carrying out a statistical analysis, to obtain information likely to compromise the privacy of the user U.

[0075] The AD ASTRA mechanism is, however, deactivated here (although this is not mandatory), when the access network used by the client device 2 is a trusted network for the client device 2 (also referred to as a “Trusted Network” in English), such as for example the mobile network AN2. Such a trusted network is typically a network that has been configured as such by the user U of the client device 2, or according to a default configuration, or which has been identified as such for example by using a network identity verification mechanism, etc. Alternatively, a trusted network can also be determined dynamically by validating the network assertions, in a manner known per se.The client device 2 is then configured to use, when it wishes to access the service S via such a trusted network, a local trusted DNS server 7 (to the trusted network), announced by the trusted network, for example by means of an advertisement mechanism as described in the document draft-ietf-add-dnr-13 published by the IETF and entitled “DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)”, August 2022. The DNS server 7 can be either a DNS server conforming to the invention or a DNS server known from the state of the art not implementing the invention.

[0076] The activation / deactivation of the AD ASTRA mechanism depending on the level of trust granted to the access network used by the client device 2 can be configured by default at the level of the client device 2 (which allows automatic activation or deactivation of the mechanism depending on the conditions of attachment to the network of the client device 2) or be decided dynamically, for example by querying the user U of the client device 2, via a user interface provided for this purpose.

[0077] The trusted DNS servers 3 belong to an L-DNS list of trusted DNS servers, configured for example 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). This configuration may have been carried out in particular by the network operator providing IP connectivity to the client device 2 (for example, its Internet service provider) or by the user U of the client device 2. For the sake of simplification, it is assumed that the L-DNS list only includes trusted DNS servers supporting the AD ASTRA mechanism. However, as a variant, the L-DNS list may also include trusted DNS servers not supporting this mechanism.

[0078] In the example of Figure 1, the DNS servers 3 included in the L-DNS list are located in the Internet network; although no limitation is attached to their location strictly speaking, preferably, the DNS servers 3 are not located in or announced by an “Untrusted” network (i.e. by a network which is not a trusted network for the client device 2).

[0079] It should be noted that there is no limitation as to the number of trusted DNS (or more generally name resolution) servers as specified in the L-DNS list, which may be greater than or equal to 1. In the embodiment described here, it is assumed that the client device 2 embeds a DNS client referenced by CL (for example in an application such as its operating system or OS for "Operating System" in English, the DNS client CL being able to be shared by several applications), which chooses according to a predefined local strategy (for example via a default configuration) the trusted DNS server(s) to be requested from the L-DNS list for each domain name resolution required when invoking a service such as for example the service S provided by the remote server 5.This local strategy may in particular specify: a persistent choice mode according to which the same DNS server is chosen according to a local preference or on the basis of information characteristic of the capacities of the DNS servers in the L-DNS list, and requested for a determined duration; a sequential choice mode, according to which the DNS client CL establishes a list of candidate L-CAND servers from the L-DNS list, which it orders according to one or more criteria. For example, the L-CAND list is established and ordered according to an encryption scheme supported where appropriate by each DNS server; such an encryption scheme is for example a DoT, DoD, DoH, DoQ, or DoC encryption scheme as mentioned above. By way of illustration, the L-CAND list may thus comprise all the DNS servers in the L-DNS list supporting the DoH encryption scheme, followed by all the DNS servers in the L-DNS list supporting the DoT encryption scheme.The DNS servers are then requested by the CL DNS client in the order of the L-CAND list thus established. Of course, criteria other than the encryption schemes can be considered as a variant, such as the location of the DNS servers, their processing capacity(s), etc.; a random selection mode: a DNS server is chosen randomly by the CL DNS client for any new DNS resolution request. This random selection mode can also result in a random choice of the implemented encryption scheme; etc.

[0080] These examples of strategies adopted by the CL DNS client of the client device 2 are given for illustrative purposes only, and other strategies may be considered as alternatives. In addition, the client device 2 may embed one or more CL DNS clients capable of implementing such a strategy when activated.

[0081] In the embodiment described here, communications between the client device 2 (and more specifically its DNS client CL) and a trusted DNS server 3, selected by the DNS client CL of the client device 2 are encrypted. They are for example compliant with any of the DoT, DoD, DoH, DoQ, or DoC protocols. The use of an encrypted DNS transport to transmit messages between the client device 2 and a DNS server 3 guarantees the authenticity and integrity of these messages.

[0082] It is further assumed, for the sake of simplification, that the client device 2 exchanges directly with the trusted DNS server 3, selected by the DNS client CL, without the intervention of a DNS relay (or “forwarder”). However, the invention also applies in the presence of a DNS forwarder located between the client device 2 and the trusted DNS server 3, selected by the DNS client CL. More specifically, if the DNS forwarder is trusted, the client device 2 addresses its DNS requests to it; in this case, the DNS forwarder is configured to relay the DNS requests 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 requests directly to the DNS server 3 selected by the CL DNS client (and thus bypass the DNS forwarder). Thus, for the sake of simplification in the following, the terminology "DNS query addressed by a client device" refers indifferently to a DNS query coming directly from the client device or via a DNS forwarder as just mentioned.

[0083] According to the invention, when the AD ASTRA mechanism is activated and a trusted DNS server 3 is requested by the client device 2 to resolve a domain name associated with the service S hosted by the 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 requesting another DNS server), select one or more relay nodes from among the relay nodes 4 of the system 1 to which to direct the client device 2 to send its messages containing data intended for the remote server 5 (recipient server within the meaning of the invention), sent within the framework of the service S.The communications between the client device 2 and the selected relay node(s) 4 of the system 1, as well as between these relay nodes 4 and the DNS servers 3 having selected them, are encrypted in the embodiment described here, for example by means of the TLS protocol (for “Transport Layer Security”), version 1.3, possibly combined with the use of an ECH function (for “Encrypted Client Hello”). Of course, this hypothesis is not limiting in itself and other encryption protocols and extensions can be envisaged as a variant in the context of the invention.

[0084] In the embodiment described here, the client device 2, the DNS servers 3 and the relay nodes 4 have the hardware architecture of a computer 8 as shown schematically in FIG. 2. This 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 allowing each of the aforementioned devices to communicate in particular with the other devices of the system 1. These communication means COM can in particular be based 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 (or API for "Application Programming Interface" in English) or a point-to-point communication interface, etc., and implement one or more encryption schemes as mentioned previously.

[0085] The non-volatile memory NVM (or alternatively the read-only memory ROM) of the computer 8 constitutes a recording medium in accordance with the invention, readable by the processor PROC, and on which a computer program in accordance with the invention is recorded.

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

[0087] The computer program PROG3 defines the functional modules of a DNS server 3 according to the invention, which rely on or control the PROC, MEM, ROM, NVM, and COM elements of the computer 8. In the embodiment described here, these functional modules comprise in particular, as illustrated by FIG. 3: a reception module 3A, configured to receive REQ-DNS name resolution requests (DNS requests in the example envisaged here) sent by client devices, and in particular by the client device 2; a processing module 3B, configured to process (in other words resolve) the REQ-DNS requests received by the reception module 3A and to prepare REP-DNS responses to these requests; a provisioning module 3C, configured to provide each client device having requested the DNS server 3, supporting (and incidentally requesting) the implementation of the AD ASTRA mechanism, a plurality of AD ASTRA-ELTS elements in addition to the information conventionally provided in response to a REQ-DNS query, as detailed further below. In the embodiment described here, the plurality of AD ASTRA-ELTS elements is provided to a client device having addressed a REQ-DNS query to the DNS server 3 in the REP-DNS response to this query, for example in an EDNS option (for "Extension Mechanisms for DNS") as explained in more detail later.These hypotheses are however not limiting and it is possible to envisage that the plurality of AD ASTRA-ELTS elements is provided to the client device using one or more messages distinct from the REP-DNS response; and a sending module 3D, configured to send to the client devices having requested the DNS server 3, the REP-DNS responses prepared by the processing module 3B as well as the plurality of AD ASTRA-ELTS elements provided by the supply module 3C.

[0088] The processing module 3B proceeds, to resolve a REQ-DNS request received from a client device, in a conventional manner by establishing, from RR records available to the DNS server 3 or to which it can access (via one or more other DNS servers organized hierarchically), a correspondence between the name to which the REQ-DNS request relates (for example, the domain name “service-s.com” allowing access to the service S) and an IP resource (for example an IP address) of a server associated with this name (the server 5 in the example of the domain name “service-s.com”).

[0089] In the example considered here, for the sake of simplification, we are limited to RR records of type A (establishing a correspondence between a name and an IPv4 address of a server associated with this name) and RR records of type AAAA (establishing a correspondence between a name and an IPv6 address of a server associated with this name), a server associated with a name being able to be identified by an IPv4 address and / or an IPv6 address (and therefore corresponding to a record of type A and / or to a record of type AAAA). It should be noted that the invention is not limited to these two types of records and also applies to other types of RR records such as RR records of type SVCB (for "Service Binding"), SRV (for "Service resource record"), CNAME, etc., which can associate names with resources other than an IP address, such as for example an alias, another name, a URI, etc.

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

[0091] As mentioned previously, this REP-DNS response further comprises, in the embodiment described here, the plurality of AD ASTRA-ELTS elements provided by the provision module 3C of the DNS server 3. This plurality of AD ASTRA-ELTS elements comprises, in accordance with the invention, at least the following elements: 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 for the destination server associated with the name to which the REQ-DNS request relates (remote server 5 in the example envisaged), to which the client device must address all or part of its messages containing data intended for the destination server. This IP address may optionally be supplemented by a port number to be used by the client device to address its messages to the relay node 4, if a default port number is not defined.In other words, instead of addressing messages relating to the service it wishes to access to the destination server identified in the REP-DNS response, the client device must address these messages to relay node 4 (i.e. indicate as the destination address of these messages the address of the relay node 4 instead of the address of the recipient server). The recipient server for which the useful data contained in these messages are actually intended remains, however, identified in the content of the messages addressed to the relay node 4-1 so that it can relay this useful data to the recipient server. Thus, in the example envisaged for service S, if the plurality of AD ASTRA-ELTS elements designates the relay node 4-1, this means that the client device 2 must address the messages containing data intended 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 noted @IP4-1 and a port number P4-1, which may be defined by default or have been provided by the DNS server 3 with the IP address of the relay node 4-1 as mentioned previously), and contains a data packet, called an inner data packet, encrypted using an encryption scheme (for example, TLS, DTLS). The inner data packet contains useful data intended for the remote server 5, and as its destination address, the IP address of the remote server 5 and its port number (also more commonly referred to as a “transport address”).The address of the remote server 5 is therefore masked by means of encryption in the content of the message addressed to the relay node 4-1; and at least one scrambling instruction INST, intended to be applied (in other words to be applied) by the client device 2 to said messages containing data intended for the destination server before addressing them to said at least one relay node 4. Such a scrambling instruction may comprise for example an instruction for padding all or part of the messages, and / or an instruction for emulating connections between the client device and the relay node or via the relay node to a dedicated server in addition to the connection used to send the messages containing the data intended for the destination server (in other words an instruction for establishing “dummy” connections by the client device), as explained further below.

[0092] The configuration and operation of the modules 3A to 3D of a DNS server 3 according to the invention are described in more detail with reference to the steps of the method for processing a (first) name resolution request illustrated by Figure 6.

[0093] As regards the client device 2, the program PROG2 stored in the NVM memory (or alternatively ROM) of the computer 8 defines the functional modules of the client device 2, which rely on or control the PROC, MEM, ROM, NVM, and COM elements of the computer 8. These functional modules include in particular, in the embodiment described here, as illustrated in FIG. 4: a sending module 2A, embedded in the DNS client CL, and configured to send to one of the DNS servers 3 of the L-DNS list chosen by the DNS client CL of the client device 2, a name resolution request REQ-DNS. In the example envisaged here, this REQ-DNS request relates to a domain name and to an RR record of type A or AAAA 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 the service S hosted by the remote server 5 and associated with the domain name “service-s.com ». In the embodiment described here, the REQ-DNS request further comprises an EDNS EAO option, indicating to the requested DNS server 3 that the client device 2 supports (and incidentally requests) the AD ASTRA mechanism. Alternatively, the support of the AD ASTRA mechanism by the client device 2 may be signaled to the DNS server 3 by other means (for example in a message other than in the REQ-DNS request, in another option, etc.); a reception module 2B, embedded in the DNS client CL, and configured to receive from the requested DNS server 3, the REP-DNS response to the REQ-DNS request prepared by. the latter. This REP-DNS response comprises, as indicated previously, at least one information relating to the RR record requested by the client device 2 of the recipient server associated with the name to which the REQ-DNS request relates, for example an IP address of the recipient server. Furthermore, in the embodiment described here, the REP-DNS response contains the plurality of AD ASTRA-ELTS elements provided by the DNS server 3 in accordance with the AD ASTRA mechanism; an execution module 2C, configured to apply said at least one scrambling instruction contained in the plurality of AD ASTRA-ELTS elements to the messages containing data intended for the recipient server associated with the name to which the REQ-DNS request relates before addressing them to one of the relay nodes 4 identified in the plurality of AD ASTRA-ELTS elements; and a sending module 2D configured to send to the relay node 4 in question the scrambled messages obtained by the execution module 2C.

[0094] The configuration and operation of the modules 2A to 2D of the client device 2 according to the invention are described in more detail with reference to the steps of the communication method illustrated by FIG. 7.

[0095] Similarly, the PROG4 program stored in the NVM memory (or alternatively ROM) of the computer 8 defines the functional modules of a relay node 4 according to the invention, these functional modules relying on or controlling the PROC, MEM, ROM, NVM, and COM elements of the computer 8. They comprise in particular, in the embodiment described here, as illustrated by FIG. 5: an acquisition module 4A, configured to acquire information relating to at least one scrambling instruction INST applied by a client device according to the invention such as the client device 2, for which the relay node 4 has been selected, said scrambling instruction INST being applied to messages containing data intended for a destination server before the client device addresses them to the relay node 4.The acquisition of the information relating to the scrambling instruction INST can be done via the trusted DNS server 3 at the origin of this instruction or by the client device configured to apply it; and a processing module 4B, configured to: o upon receipt of such a message, remove, using the acquired information, the scrambling applied by the client device to the message in accordance with the scrambling instruction INST; and o transfer the message obtained after removal of the scrambling to the destination server. It should be noted that the relay node 4 can transfer the message obtained directly to the destination server or via another relay node, in the case where several relay nodes are deployed in cascade. The way in which the processing module 4B proceeds does not present any difficulty for those skilled in the art and is not described in more detail here.

[0096] In the embodiment described here, the module 4B is further configured to, upon receipt of a message from the destination server and intended for the client device for which it has been selected (for example the client device 2), scramble this message and transfer the obtained scrambled message to the client device. It should be noted that the module 4B does not necessarily apply in the relay node to client device direction the scrambling that was applied in the client device to relay node direction (i.e. the scrambling applied in one direction and in the other are not necessarily the same). The scrambling applied in the relay node to client device direction is for example chosen by the trusted DNS server 3.If it differs from that applied in the client device to relay node direction, the relay node 4 is informed, for example, by the trusted DNS server 3 and receives from the latter, via its acquisition module 4A, an INST' jamming instruction. lage describing the jamming to be applied. Alternatively, the instruction for jamming identification is explicitly coded in the encrypted message and thus communicated by the client device (resp. the relay node).

[0097] The configuration and operation of the modules 4A and 4B of a relay node 4 according to the invention are described in more detail with reference to the steps of the message processing method illustrated by Figure 8.

[0098] We will now describe, with reference to figures 6 to 8, the main steps of the methods for processing a name resolution request (figure 6), communication (figure 7) and message processing (figure 8) according to the invention, as they are implemented respectively by a DNS server 3 (in the example envisaged below, the DNS server 3-1), the client device 2 and a relay node 4 (in the example envisaged below the relay node 4-1) in accordance with the invention, in a particular embodiment.

[0099] With reference to Figure 7, as mentioned previously, it is assumed in the embodiment described here that the client device 2 is configured (for example, by its Internet service provider or by its user) with an L-DNS list of trusted DNS servers 3, in accordance with the invention supporting the AD ASTRA mechanism.

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

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

[0102] The client device 2 then sends, via its sending module 2A, a DNS REQ request for resolving the domain name “service-s.com” (first request within the meaning of the invention) to one of the trusted DNS servers 3, identified in the L-DNS list, namely here to the DNS server 3-1 (step E10). The choice of the DNS server 3-1 from the L-DNS list results from a local strategy applied by the client device 2 and which has been previously configured in the client device 2, as mentioned above. It is also recalled that the exchanges between the client device 2 and the DNS server 3-1 (DNS requests and responses to DNS requests in particular) are encrypted, for example using one of the DoT, DoD, DoH, DoQ, or DoC encryption schemes previously mentioned.

[0103] The REQ-DNS request, in a manner known per se, specifies in particular the domain name “service-s.com” which the client device 2 wishes to access, as well as the type of RR record targeted by the request (for example here an RR record of type A if the client device 2 supports the IPv4 protocol or an RR record of type AAAA if the client device 2 supports the IPv6 protocol). In the embodiment described here, the REQ-DNS request further comprises an EDNS option called EAO (newly introduced for the purposes of the invention), indicating to the requested DNS server 3, i.e. the DNS server 3-1, that the client device 2 supports and requests the implementation of the AD ASTRA mechanism.

[0104] Figure 9A illustrates an example format of the EAO option inserted by client device 2 in its REQ-DNS request indicating to DNS server 3-1 that client device 2 supports and requests implementation of the AD ASTRA mechanism. In accordance with RFC 6891 published by the IETF and entitled "Extension Mechanisms for DNS (EDNS(0))", April 2013, the EAO option comprises three fields OPTION-CODE, OPTION-LENGTH and OPTION-DATA, the OPTION-LENGTH field indicating the size in bytes of the OPTION-DATA field.

[0105] In the example shown in Figure 9, the OPTION-DATA field includes a “partial- offload” and an “AID” ​​parameter (for “AD ASTRA relay IDentifier” in English), as well as a reserved location, allowing the client device 2 to communicate capabilities it has in relation to the AD ASTRA mechanism as well as other information that may be useful to the requested DNS server 3. More particularly: the parameter “partial-offload” is used by the client device 2 in a request to indicate to the DNS server 3-1 whether it supports (parameter valued at 1 for example) or not (parameter valued at 0 for example) the sending of a first name resolution request to the DNS server 3-1 (REQ-DNS request) then the sending of subsequent name resolution requests (second requests within the meaning of the invention, noted REQ'-DNS, REQ"-DNS, etc.), correlated to the first name resolution request REQ-DNS, to a name resolution server other than the DNS server 3.1 whose reachability information (for example its IP address) is communicated to it by the DNS server 3-1. This other name resolution server may typically be a relay node selected by the DNS server 3-1 in accordance with the invention. By "correlated queries" is meant here that there is a link between the two questions asked in the two queries, for example the first query relates to the resolution of a "parent" domain name (for example "service-s.com") while the second query relates to the resolution of a name of a subdomain of the parent domain (i.e. "*. service-s. corn" in the example considered above where * denotes a character string).Another example of correlation is the discovery by the client device 2 of names (or “references” or “referrals” in English) requiring resolution when processing data sent by the recipient server resulting from the resolution of the first query; the second query(s) sent to resolve these names are correlated within the meaning of the invention to the first query. The correlation is established by the client device 2 as soon as it associates the recipient server as the source of the names. The “partial-offload” parameter can be set to 0 by default.In the remainder of the description, if the “partial-offload” parameter is set to 1 by the client device 2, it is said that the latter supports the “partial-offload” function (function of “offloading” DNS requests to a server other than the DNS server 3-1 responsible for processing the first REQ-DNS request); and the “AID” ​​parameter is used by the client device 2 to indicate whether it already uses, for active connections, a relay node in accordance with the invention, within the framework of an implementation of the AD ASTRA mechanism for the service S associated with the domain name “service-S.com” hosted by the server 5 (in other words to send messages containing data intended for the server 5), and where appropriate an identifier of this relay node. There are no limitations on the form of the identifier in question: it can be an alias, a number, a domain name, a hash, etc.The client device 2 may optionally associate this identifier with a preference intended for the DNS server 3-1, for example “match” if it wishes the DNS server 3-1 to select the same relay node when processing the REQ-DNS request, or “not match” to request the use of another relay node. In the embodiment described here, this preference is not necessarily binding for the DNS server 3-1 and may not be taken into account by it. Of course, this is only an implementation choice and it is possible, as a variant, to envisage this preference of the client device 2 being binding for the DNS server 3-1.

[0106] With reference to Figure 6, upon receipt of the REQ-DNS request by its reception module 3A (step F10), the DNS server 3-1 determines whether the latter contains the EAO option (test step F20).

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

[0108] If the REQ-DNS request contains the EAO option (response “yes” to the test step F20), as is the case in the example considered here, the DNS server 3-1 processes (resolves) via its processing module 3B the REQ-DNS request in a conventional manner known to those skilled in the art, from the RR records available to it or by querying one or more other DNS servers (step F50). This processing is identical to that carried out during step F30.

[0109] The module 3B for processing the DNS server 3-1 obtains, by resolving the REQ-DNS request, the RR record of the server 5 (recipient server within the meaning of the invention) associated with the domain name “service-s.com” and more particularly its IP address @IP5 which is contained in this RR record (information relating to the recipient server resulting from the resolution of the REQ-DNS request within the meaning of the invention). It includes the address @IP5 in the REP-DNS response to the REQ-DNS request.

[0110] Furthermore, in accordance with the invention, the DNS server 3-1, supporting the AD ASTRA mechanism, selects via its provisioning module 3C at least one relay node 4 for the destination 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 send it the messages that it wishes to send to the destination server 5, as part of its access to the service S (instead of sending them directly to the destination server 5). The relay node 4-1 is then responsible for relaying these messages to the destination server 5, directly or via another relay node 4 when relay nodes are deployed in cascade.

[0111] It should be noted that if the REQ-DNS query is addressed by the client device 2 to a trusted DNS server that does not support the AD ASTRA mechanism and in particular the EAO option (for example when the L-DNS list includes both trusted DNS servers that support the AD ASTRA mechanism and trusted DNS servers that do not), then the latter responds to the client device 2 by sending it an error message. Upon receipt of the error message, the client device 2 can request another DNS server, resend the query to the same server but without the EAO option, terminate the communication and generate a local notification (application, user, etc.) indicating the failure of the resolution attempt, etc.

[0112] To select a relay node 4 for a destination server 5 and a client device 2, the module 3C for providing the DNS server 3-1 may take into account one or more selection criteria. In particular, the provision module 3C may select a relay node 4 satisfying one or more of the following conditions: preventing the establishment of a correlation between the selected relay node 4 and the destination server.Typically, the provisioning module 3C must avoid that a relay node 4 is selected only for a single destination server, or for distinct communications between the client device 2 and the destination server, it can select different relay nodes 4; maximize the number of client devices using a selected relay node 4; optimize the client devices using a selected relay node 4 according to at least one given criterion, such as for example load considerations, geographical considerations, etc.; have (already) a route from the selected relay node 4 to the destination server. This information can be obtained by the provisioning module 3C by querying the relay nodes 4 of the system 1 to obtain the routing tables maintained by them; etc.

[0113] In another embodiment, the module 3C for providing the DNS server 3-1 can randomly select a relay node 4 from a list of relay nodes with which it has been previously configured.

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

[0115] Furthermore, if the EAO option of the REQ-DNS request includes an AID identifier of a relay node previously selected for the client device 2 and the destination server 5 associated with the service S, the DNS server 3-1 can take this AID identifier into account when selecting the relay node (and, where applicable, the preference associated with this AID identifier indicated by the client device 2). For example, if the client device 2 has inserted in the EAO option an AID identifier of a relay node 4, the DNS server 3-1 can select a relay node 4 so as to avoid associating the same relay node with the same destination server for this client device 2, so as to minimize the risk of tracing the DNS communications of the client device 2 by a malicious entity (such an entity would then have great difficulty in establishing a correlation between the destination server and the identifier of the relay node).Alternatively, it may decide to select a relay node coinciding with the one identified in the AID identifier of the REQ-DNS request.

[0116] It should be noted, however, that depending on its configuration, DNS server 3-1 may ignore the indications provided by client device 2 in the "AID" parameter of the EAO option of the REQ-DNS request.

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

[0118] Alternatively, one may consider providing a domain name associated with each selected relay node as the reachability address, instead of an IP address. Using an IP address has the advantage of not requiring additional name resolution (which allows client device 2 to access service S more quickly).

[0119] In yet another variant, the address inserted by the provisioning module 3C is a transport address of the relay node 4 and includes an IP address of the relay node 4 as well as a port number to be used.

[0120] Figure 9B illustrates an example of the format of the EAO option inserted by the DNS server 3-1 in its REP-DNS response (which echoes the EAO option inserted by the client device 2 in its REQ-DNS request). As shown in this figure, the OPTION-DATA field of the EAO option includes several parameters, including in particular a “relay-locators” parameter, in which the IP address of the selected relay node 4-1 (or the IP addresses of the selected relay nodes) is (are) inserted.

[0121] Furthermore, in accordance with the invention, the supply module 3C also inserts into the EAO option of the REP-DNS response, in the plurality of AD ASTRA-ELTS elements that it supplies to the client device 2, at least one INST scrambling instruction to be applied by the latter to the messages that it will address to the relay node 4-1 and which are intended for the destination server.

[0122] In the embodiment described here, the scrambling instruction INST consists of an instruction for stuffing (or filling or "padding") the messages sent by the client device 2 before they are sent to the relay node 4-1. It is inserted into a "padding" parameter of the OPTION-DATA field of the EAO option, as illustrated in FIG. 9. This stuffing instruction is an instruction to complete the messages intended for the destination server that the client device 2 sends to the relay node 4-1 so as to homogenize their sizes. The padding pattern(s) applied by the client device 2, denoted PATT, are chosen for example so as to make the template of the messages sent by several client devices uniform. This advantageously makes it possible to reinforce further anonymity of communications from the client devices in question.

[0123] The padding instruction inserted into the “padding” parameter by the provisioning module 3C may take several forms. It may include a generation technique to be used by the client device 2 to generate one or more padding PATT patterns. Such a technique may rely, for example, on a reinforcement learning technique allowing the client device 2 to determine the padding patterns to be applied and to adjust them over time if necessary.

[0124] Alternatively, such a generation technique may be applied directly by the 3C provisioning module of the DNS server 3-1, and the padding instruction inserted in the "padding" parameter logs the padding PATT pattern(s) generated by the 3C provisioning module using this generation technique.

[0125] In the embodiment described here, the provision module 3C further notifies the relay node 4-1 selected for the client device 2 and the destination server 5, of the content of the stuffing instruction (and more particularly of the stuffing PATT pattern(s) or the technique for generating such patterns) that it requests the client device 2 to apply to the messages intended for the destination server 5 that it will send to the relay node 4-1 (step F80).

[0126] This notification of the relay node 4-1 by the DNS server 3-1 allows it to acquire information relating to the scrambling instruction(s) ordered by the DNS server 3-1 to the client device 2 and thus to be able to process the messages from the client device 2 containing data intended for the destination server 5 before relaying them to the destination server 5.

[0127] Alternatively, the relay node 4-1 may acquire such information from the client device 2 itself. For example, in the case of a stuffing instruction, the client device 2 may notify the relay node 4-1 by inserting into its messages containing data intended for the destination server 5 and addressed to the relay node 4-1, indicators delimiting or identifying the stuffing patterns applied.

[0128] In another embodiment, the scrambling instruction INST may comprise an instruction for the client device 2 to establish one or more dummy connections with the relay node 4-1 and / or via the relay node 4-1 (with one or more dedicated servers), in addition to its “main” connection established with the relay node 4-1 to transmit data to the destination server 5 as part of access to the service S by the client device 2. The client device 2 then uses these dummy connections to transmit “dummy” data to the relay node 4-1 and / or to the dedicated server(s), in other words, data which are not strictly speaking intended to be used (“consumed”) by the relay node 4-1 and / or by the dedicated server(s), but which are only intended to scramble the data intended for the destination server 5.This dummy connection establishment instruction can be inserted into a suitable parameter of the OPTION-DATA field of the EAO option, and notified to relay node 4-1 as described previously for the padding instruction.

[0129] Of course, other scrambling instructions may be transmitted by the DNS server 3-1 to the client device 2 in order to introduce noise around the connection of the client device 2 with the destination server (remote server 5 in the example considered here) and to make it difficult to exploit the information intercepted by a malicious entity placed on the path of this connection. They are also notified to the relay node 4-1 so that it can take them into account when receiving scrambled messages from the client device 2.

[0130] In the embodiment described here, the 3C module for providing the DNS server 3-1 provides two other elements in the plurality of AD ASTRA-ELTS elements inserted in the EAO option of the REP-DNS response, namely: an “AID” ​​parameter, in which the 3C module for providing the DNS server 3-1 provides an identifier of the relay node 4-1 whose address appears in the “relay-locators” parameter, and which it selected for the domain name "service-s.com" and the destination server 5. If multiple relay nodes are selected, the "AID" parameter includes the identifiers of each of the selected relay nodes. As previously stated, there is no limitation on the form of the identifier in question: it can be an alias, a number, a domain name, a hash, etc.; a “partial-offload” parameter: if the client device 2 has indicated in the “partial-offload” parameter of the EAO option of the REQ-DNS request, the support of the partial-offload function, the DNS server 3-1 indicates in the “partial-offload” parameter of the EAO option of its REQ-DNS response whether the relay node that it has selected (relay node 4-1) can support the subsequent DNS exchanges of the client device 2 correlated to the REQ-DNS request (i.e. the “second” requests within the meaning of the invention), in other words whether it supports the partial-offload function. The 3C provisioning module can optionally add in the "partial-offload" parameter an additional indication identifying the DNS queries concerned by the partial-offload function (for example, queries relating to a particular subdomain or any other filter such as the origin of DNS resources (domain names (e.g. "service.example.com", service (SRV, e.g. "service._tcp.example.com"), etc.) to be submitted to the DNS system). For illustrative purposes, in the example considered here of a REQ-DNS query relating to the domain name "service-s.com", the support of the "partial-offload" function by the relay node 4-1 indicates to the client device 2 that it can send all its subsequent queries relating to a subdomain "*.service-s.com" to the relay node 4-1. It should be noted that the support of the partial-offload function by the relay node 4-1 does not necessarily imply that subsequent DNS queries sent by the client device 2 are processed (i.e. resolved) directly by the relay node 4-1. The latter can in fact be configured to address these queries to another trusted DNS server capable of resolving them.

[0131] The various elements indicated by the DNS server 3-1 in the “relay-locators”, “AID” ​​and “partial-offload” parameters constitute, as mentioned previously, a plurality of AD ASTRA-ELTS elements provided by the 3C module for providing the DNS server 3-1 to the client device 2. In the embodiment described here, this plurality of elements is provided in the REP-DNS response to the REQ-DNS request, in an EAO option. Alternatively, all or part of this plurality of elements may be provided in one or more separate options or messages of the REP-DNS response.

[0132] The REP-DNS response including the EAO option is then sent by the 3D sending module of the DNS server 3-1 to the client device 2 (step F90).

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

[0134] The client device 2 extracts from the EAO option the plurality of AD ASTRA-ELTS elements present in the REP-DNS response, and more particularly the elements included in the “relay-locators”, “padding”, “AID” ​​and “partial-offload” parameters of the option (step E30). As a reminder, the use of an encrypted DNS transport to transmit these parameters advantageously guarantees the authenticity and integrity of the messages conveying these parameters, and therefore incidentally, of the parameters received by the client device 2.

[0135] The AID identifier is recorded by the receiving module 2B in a local cache of the DNS client CL of the client device 2, in association with the corresponding IP resource, namely here the domain name “service-s.com”. If an entry is already present in the cache for this same resource, the DNS client CL replaces its content with the new AID provided in the REP-DNS response. When sending subsequent DNS queries correlated with the REQ-DNS query, the DNS client CL fills in the “AID” ​​parameter of the EAO option of these subsequent DNS queries with the current content of the local cache.

[0136] If the client device 2 supports the partial-offload function (as is the case in the example envisaged here), the reception module 2B also records in the local cache of the DNS client CL the information transmitted in the “partial-offload” parameter, namely that all or part of the relay nodes indicated in the “relay-locators” parameter can be used for subsequent DNS queries correlated with the first REQ-DNS query as well as, where appropriate, the additional indications provided by the DNS server 3-1 and identifying the subsequent DNS queries concerned (step E50). It should be noted that in the embodiment described here, the “partial-offload” parameter is entered by the DNS server 3-1 in the EAO option of the REQ-DNS response only if the client device 2 supports the partial-offload function and has notified the DNS server 3-1 by setting the “partial-offload” parameter of the REQ-DNS query to 1.

[0137] The scrambling instruction INST included in the “padding” parameter (message stuffing instruction here) is transmitted by the reception module 2B to the APP application of the client device 2 at the origin of the REQ-DNS request for resolving the domain name “service-s.com”, so that it can execute (i.e. apply) this instruction before sending messages intended for the destination server 5 to the relay node 4-1 indicated in the “relay-locators” parameter (step E60). For this purpose, the APP application comprises an execution module 2C according to the invention. It should be noted that all of the modules 2A to 2D of the client device 2 can be hosted in the APP application.

[0138] As schematically illustrated in Figure 10, the messages intended for the destination server 5 contain useful data DATA exchanged by the application APP with the destination server 5 when accessing the service S. As briefly mentioned previously, this data is encrypted using a first encryption mechanism ENC1 according to the needs of the service S offered by the destination server 5, and recorded in inner data packets denoted I-PKT (“inner packets” in English). Each inner data packet I-PKT is intended for the destination server 5, that is to say that it has as its destination address (contained in a header of the IP packet I-PKT referenced by DEST in Figure 10), the IP address @IP5 of the destination server 5 and the port number P5 of the destination server 5.This port number is for example here a port number defined by default (alternatively it may have been obtained during the resolution of the domain name associated with the destination server 5, in a manner known per se). The internal data packet I-PKT constitutes a data packet intended for the destination server within the meaning of the invention. The application APP then applies, by means of its execution module 2C, the scrambling instruction INST recorded in the AD ASTRA-ELTS elements, to each internal data packet I-PKT containing data intended for the destination server 5 (step E60). As mentioned previously and illustrated in FIG. 10, in the embodiment described here, the scrambling instruction INST is a stuffing instruction comprising at least one stuffing pattern PATT or a technique for generating such a pattern PATT.As a result, the APP application adds stuffing bits or symbols in accordance with the stuffing PATT pattern(s) indicated in the INST stuffing instruction or generated by the execution module 2C by applying the generation technique indicated in the INST stuffing instruction. The APP application thus obtains a so-called scrambled B-PKT data packet, consisting of the inner I-PKT data packet supplemented by the stuffing bits or symbols of the applied stuffing PATT pattern(s).

[0139] It should be noted that in the example illustrated in Figure 10, the padding pattern PATT is inserted after the DATA data. This assumption is not limiting in itself, however; the padding pattern PATT may be inserted at other locations, or may be fragmented and interspersed in the middle of the DATA data.

[0140] In the embodiment described herein, the scrambled B-PKT data packet is then encrypted (according to the encryption scheme applied where applicable between the client device 2 and the relay node 4-1, referenced by ENC2 in Figure 10), and then inserted by the execution module 2C into a BM message whose destination address includes the IP address of the relay node 4-1 noted @IP4-1 (or of one of the relay nodes 4 entered in the “relay-locators” parameter) provided by the plurality of ASTRA-ELTS AD elements, as well as its port number P4-1. This port number may be a port number defined by default, or alternatively may have been recorded with the address @IP4-1 in the plurality of ASTRA-ELTS AD elements. The BM message obtained, which here contains the useful data DATA intended for the destination server 5, the IP address @IP5 of the destination server 5 and its port number P5 (commonly referred to as the transport address of the destination server 5), and the padding pattern PATT, information which is all in encrypted form, is a scrambled message within the meaning of the invention containing data intended for the destination server 5 but addressed to the relay node 4-1.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).

[0141] Note that Figure 10 only partially represents the scrambled message BM, and is provided only for illustrative purposes for a better understanding of the invention. Such a message of course includes other elements, such as a source IP address and port number (which can also be encrypted), etc.

[0142] Alternatively, as mentioned previously, the scrambling instruction INST may comprise an instruction for establishing fictitious connection(s) by the client device 2 with or via the relay node 4-1 to scramble the messages containing data intended for the destination server 5 addressed to the relay node 4-1. According to this variant, the execution module 2C proceeds as described previously: it inserts into a message M, in encrypted form (by means of the encryption mechanism ENC2), an internal data packet I-PKT having as destination address the address @IP5 of the destination server 5, and comprising in encrypted form by means of the encryption mechanism ENC1 the useful data DATA intended for the destination server 5 (no addition of padding pattern(s) unless the scrambling instruction INST also contains a padding instruction in addition to the instruction).The M message has as destination address the transport address of the relay node including its IP address @IP4-1 and its port number P4-1.

[0143] The message M thus formed is sent to the relay node 4-1 by the sending module 2D of the client device 2 on the main connection established by the client device 2 with the relay node 4-1 in a manner known per se. In this embodiment variant, the execution module 2C of the client device 2 further establishes, in addition to the main connection used to address the message M to the relay node 4-1, one or more other fictitious connections with the relay node 4-1 and / or via this relay node 4-1 with one or more dedicated servers, in accordance with the instruction INST. It sends on these fictitious connections, simultaneously with the sending of the message M on the main connection, FM messages containing fictitious data, that is to say data which are not intended to be consumed or to be exploited strictly speaking by the relay node 4-1 and / or by the dedicated servers. These fictitious data are for example randomly generated by the execution module 2C.

[0144] The fictitious connections thus emulated by the execution module 2C are advantageously added to the main connection established between the client device 2 and the relay node 4-1. A malicious third-party entity is therefore not able to distinguish the message comprising useful data M intended for the recipient server 5 from the fictitious messages FM sent simultaneously on the fictitious connections. The fictitious connections established by the client device 2 therefore come via the fictitious messages FM sent to the relay node 4-1 or via the relay node 4-1 at the same time as the message M to “scramble” the message M (which is referred to hereinafter as a scrambled message BM as in the previous variant).

[0145] With reference to Figure 8, the relay node 4-1 receives via its reception module 4A each scrambled message BM sent by the client device 2 (step G 10).

[0146] Node 4-1 decrypts each received scrambled message BM, 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 jamming introduced by the client device 2 is a padding of the internal data packets transmitted by the application APP by means of at least one padding PATT pattern provided in the INST instruction or generated from a generation technique recorded in this instruction. This or these padding PATT pattern or patterns or the generation technique for generating them have moreover been transmitted by the DNS server 3-1 to the relay node 4-1 during the notification step F80 / step G00. Obtaining this or these padding PATT pattern or patterns or the technique for generating them constitutes in itself a step of acquiring information relating to the INST jamming instruction applied by the client device 2 within the meaning of the invention.

[0147] Of course, other ways can be envisaged for the relay node 4-1 to acquire information representative of the INST scrambling instruction applied by the client device 2. For example, the scrambling pattern can be explicitly indicated by the client device in the scrambled packet itself, as discussed previously.

[0148] Thus, in the embodiment described here, the suppression of the interference introduced by the execution module 2C of the client device 2 consists for the processing module 4B in removing the stuffing bits / symbols corresponding to the stuffing PATT pattern(s) that it has received from the DNS server 3-1 or generated from the generation technique received from the DNS server 3-1. It thus obtains the internal data packets I-PKT intended for the destination server 5.

[0149] In the variant where the scrambling instruction INST comprises an instruction for establishing dummy connections, the processing module 4B can locally terminate the dummy connections established with it (or relay the FM messages to the dedicated server(s) if applicable) and extract the inner data packet I-PKT from the message M received on the main connection after decryption of the packet.

[0150] As schematically illustrated by Figure 11, the processing module 4B replaces in each internal data packet I-PKT obtained the source IP address and port number of the client device 2 (respectively noted in the figure @IP2 and P2) at the origin of the internal data packet I-PKT by its external source IP address and port number (or any other identifier used by the transport protocol such as for example the identifiers int-VTag or rem-VTag for the SCTP protocol), noted respectively @IP4-l_e and P4-l_e. It stores the source port number P2 and IP address @IP2 of the client device 2 in a local table, in its non-volatile memory NVM. Then it transfers the data packet obtained to the destination server 5, in a manner known per se (step G30). For the sake of simplification, it is considered here that the data packet obtained is transferred directly to the destination server 5 (without an intermediary between the relay node 4-1 and the destination server 5).However, this hypothesis is not limiting in itself, and the invention also applies to the transfer of the data packet to the destination server 5 via one or more other relay nodes.

[0151] Similarly, for the sake of simplification, the same port number P2 has been considered here for the client device for the BM message and for the internal data packet I-PKT. However, different port numbers may be used by the client device 2.

[0152] In a particular embodiment, the relay node 4-1 adds scrambling before transferring the I-PKT data packet to the destination server 5. It can in particular for this purpose, as described previously for the client device 2, establish fictitious connections with dedicated servers, or with other (“real”) servers. This scrambling introduced between the relay node 4-1 and the destination server 5 has a particular advantage in particular when the number of client devices using the same relay node 4 is less than a given threshold.

[0153] It is assumed here that the destination server 5 responds to at least one of the I-PKT data packets received from the client device 2 via the relay node 4-1, by means of a so-called “return” data packet and noted R-PKT, the useful data contained in this return packet being encrypted as required. of the S service using the ENC1 encryption mechanism.

[0154] According to the source port number and IP address indicated in the internal data packets I-PKT received from the relay node 4-1, the return data packet R-PKT is sent by the destination server 5 to the relay node 4-1. Upon receiving this return packet R-PKT by the relay node 4-1 (step G40), the processing module 4C replaces its external port number P4-1_e and 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. Furthermore, it scrambles the return data packet R-PKT thus modified by applying thereto the same type of scrambling as that applied by the client device 2 in accordance with the scrambling instruction INST.In the example envisaged here, the processing module 4C thus applies the PATT scrambling pattern(s), notified by the DNS server 3-1 during steps F80 / G00 (or generated from the generation technique provided by the DNS server 3-1) (step G50), then encrypts the scrambled return data packet obtained in its entirety (i.e. including its headers) in accordance with the ENC2 encryption scheme 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 scrambled return message B-MR obtained is then transferred by the relay node 4-1 to the client device 2 (step G60).

[0155] In an alternative embodiment (not illustrated in Figure 11), the processing module 4C also replaces in the return data packet R-PKT the source port number P5 and IP address @IP5 of the destination server 5 with its port number P4-1 and its IP address @IP4-1 (which can be described as “internal” with respect to the external port number P4-l_e and IP address @4-l_e visible to the destination server 5), before scrambling and encrypting it.

[0156] Upon receipt of the scrambled return message B-MR by the client device 2 (step E80), the latter decrypts it, then removes the scrambling introduced by the relay node 4-1 (by removing the bits / symbols added in accordance with the padding PATT pattern(s)) and accesses the return data packet R-PKT sent by the destination server 5 (step E90).

[0157] Of course, other internal and return data packets can be exchanged in a similar or identical manner between the client device 2 and the destination 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 destination server 5 and entered in the “relay-locators” parameter of the REP-DNS response.

[0158] It is now assumed that a new REQ'-DNS name resolution request is sent as part of access to the service S by the client device 2, and that this new REQ'-DNS request is correlated to the REQ-DNS request previously sent (for example, it relates to the resolution of the name of a subdomain of the domain to which the REQ-DNS request relates).

[0159] If the client device 2 supports the partial-offload function (parameter "partial-offload" valued at 1 in the REQ-DNS request), and the DNS server 3-1 has indicated in the parameter "partial-offload" of its REQ-DNS response the relay node 4-1, then the client device 2 addresses the new REQ'-DNS request to the relay node 4-1 directly, as illustrated in Figure 12A. The same applies to all subsequent name resolution requests (REQ"-DNS, etc.) connected to the REQ-DNS request. Note that the resolution of subsequent requests may result in a destination server 5' different from the destination server 5, as illustrated in Figure 12A.

[0160] If the client device 2 does not support the partial-offload function (parameter “partial-offload” valued at 0 in the REQ-DNS request), the client device 2 continues to use the DNS server 3-1, as illustrated by Figure 12B. The same is true if the new DNS request REQ'-DNS is not correlated to the REQ-DNS request, including when the client device 2 supports the partial-offload function.

[0161] In the embodiment described here, DNS exchanges between the client device 2, the DNS server(s) 3 and the relay nodes 4. The invention, however, applies to any type of name to be resolved, regardless of the format, and not only to a domain name as defined by the RFC 1034 document. Thus, everything previously described with reference to a domain name applies to the resolution of any name of an IP resource.

Claims

Claims

1. Method for processing a first name resolution request (REQ-DNS) originating from a client device (2), said method being implemented by a name resolution server (3-1) and comprising sending (F90) to said client device a response (REP-DNS) to the first request comprising at least one piece of information (@IP5) relating to a so-called recipient server (5) resulting from a resolution of said first request, said method being characterized in that it further comprises sending (F90) to said client device a plurality of elements (AD ASTRA-ELTS) 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 part of its messages containing data intended for the recipient server;and at least one scrambling instruction (INST) to be applied by the client device to said messages before sending them to said at least one relay node.;

2. A processing method according to claim 1 wherein at least one said relay node (4-1) selected by the name resolution server satisfies at least one condition among: preventing a correlation between said relay node and the destination server; and / or maximizing a number of client devices using said relay node; and / or optimizing client devices using said relay node according to at least one given criterion; and / or having a route from said relay node to the destination server.

3. Processing method according to claim 1 or 2 wherein said at least one scrambling instruction (INST) comprises an instruction for stuffing said messages before sending them to said at least one relay node, said instruction comprising at least one stuffing pattern (PATT) to be used by the client device to scramble said messages or a technique for generating at least one such stuffing pattern.

4. Communication method implemented by a client device (2), comprising a reception (E20), from a name resolution server (3-1), of a response (REP-DNS) to a first name resolution request (REQ-DNS) sent by the client device, this response comprising at least one item of information (@IP5) relating to a so-called recipient server (5) resulting from a resolution of the first request, said communication method being characterized in that it further comprises: a reception (E20) of a plurality of elements, from the name resolution server, 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 part of its messages containing data intended for the recipient server;and o at least one scrambling instruction (INST) to be applied by the client device to said messages before sending them to said at least one relay node; an application (E60) of said at least one scrambling instruction to said messages.

5. Communication method according to claim 4 wherein said at least one scrambling instruction (INST) comprises an instruction for stuffing said messages and the application (E60) of said at least one scrambling instruction comprises stuffing at least one said message using a stuffing pattern (PATT) provided in said stuffing instruction or generated by means of a generation technique provided in said stuffing instruction.

6. Communication method according to claim 4 or 5 wherein said at least one scrambling instruction (INST) comprises an instruction to establish at least one dummy connection with and / or via said at least one relay node.

7. Method according to any one of claims 1 to 6 wherein said messages addressed to said at least one relay node comprise, in encrypted form, data intended for the recipient server and an address of said recipient server.

8. A method according to any one of claims 1 to 7 wherein said plurality of elements (AD ASTRA-ELTS) further comprises a first indication that at least one said relay node can be used by said client device to send at least a second name resolution request correlated to the first request.

9. The method of claim 8 wherein said plurality of elements (AD ASTRA-ELTS) further comprises a second indication identifying the name resolution requests affected by the first indication.

10. Method according to any one of claims 1 to 9 wherein said plurality of elements (AD ASTRA-ELTS) further comprises at least one identifier (AID) of said at least one relay node selected by the name resolution server.

11. Method according to any one of claims 1 to 10 in which the first request (REQ-DNS) comprises at least one identifier (AID) of at least one relay node previously selected for the client device to which the client device addresses all or part of its messages comprising data intended for the recipient server.

12. The method of claim 11 wherein at least one said relay node selected by the name resolution server matches a relay node identified in the first query.

13. A method according to any one of claims 1 to 12 wherein all or part of said plurality of elements (AD ASTRA-ELTS) is sent to the client device or received by the client device in said response (REP-DNS) to the first query.

14. Method according to any one of claims 1 to 13 further comprising a step (F90) of notifying said at least one relay node of at least one piece of information relating to said at least one scrambling instruction.

15. Method for processing messages implemented by a relay node (4-1) selected by a name resolution server (3-1) for a client device (2) and a so-called recipient server (5), said method comprising: an acquisition (G00) of at least one piece of information relating to at least one scrambling instruction (INST) applied by the client device to messages comprising data intended for the recipient server before addressing them to the relay node; upon receipt (G10) of at least one scrambled message comprising data intended for the recipient server and addressed to the relay node by the client device, a deletion (G20), using said at least one acquired information, of the jamming applied by the client device; and a transfer (G30) of said at least one message obtained after deletion of the jamming to the recipient server.

16. Processing method according to claim 15 further comprising upon receipt (G40) of at least one message from the recipient server and comprising data intended for the client device, scrambling (G50) said at least one message before transferring it to the client device.

17. Name resolution server (3-1) configured to send a response to a first name resolution request from a client device, said response comprising at least one piece of information relating to a so-called recipient server resulting from a resolution of said first request, said server being characterized in that it is further configured to send to said client device a 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 part of its messages comprising data intended for the recipient server; and at least one scrambling instruction to be applied by the client device to said messages before addressing them to said at least one relay node.

18. Client device (2) configured to receive, from a name resolution server, a response to a first name resolution request sent by the client device, this response comprising at least one piece of information relating to a so-called recipient server resulting from a resolution of the first request, said client device being characterized in that it is further configured to: receive a plurality of elements, from the name resolution server, 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 part of its messages comprising data intended for the recipient server; and o at least one scrambling instruction to be applied by the client device to said messages addressed to said at least one relay node; apply said scrambling instruction to said messages.

19. Relay node (4-1) in a communications network selected by a name resolution server for a client device and a destination server, said relay node being configured to: acquire at least one piece of information relating to at least one scrambling instruction applied by the client device to messages comprising data intended for the destination server before addressing them to the relay node; upon receipt of at least one scrambled message comprising data intended for the destination server and addressed to the relay node by the client device, remove by using said at least one piece of acquired information the scrambling applied by the client device; and transfer said at least one message obtained after removal of the scrambling to the recipient server.

20. A system (1) in a communications network comprising: a client device (2) according to claim 18; a name resolution server (3-1) according to claim 17; and at least one relay node (4-1) according to claim 19 selected by the name resolution server for said client device.

Images