Method for detecting malicious domain name server, corresponding device, trusted server and computer program

Abstract

The invention relates to a method for detecting malicious DNS servers, implemented in a device configured with at least one trusted DNS server, the method implementing:-sending (111) at least one request to activate a DNS validation service to at least one of the trusted servers, -receiving (112) at least one response comprising at least one domain name generated by said trusted server,-sending (113) at least one request to resolve said at least one domain name,-if said trusted server does not receive a request to resolve said at least one domain name, or if at least one request is received but comprises an exception,-sending (113) at least one request to resolve said at least one domain name,-sending (113) at least one response to said trusted server,-if said trusted server does not receive a request to resolve said at least one domain name. If so, at least one notification requiring the device to take an action is received (114).

Description

Field of the Invention

[0001] The field of the invention is the field of communications within a communications network, such as a computer network implementing the IP protocol.

[0002] More specifically, the invention relates to name resolution services, such as DNS (Domain Name System), and proposes a solution that helps to detect the presence of malicious servers involved in name resolution. Background Art

[0003] The development of the Internet is based on a series of service offers for the consumer and business markets. Among them, multi-service offers, including "Triple Play" offers (simultaneously offering access to the Internet, video content (including television program broadcasts), and session services (IP telephony)), have taken an important share of the market.

[0004] One of the factors common to the offers of operators is the presence of a system of home or business gateways, commonly referred to as CPE (Customer Premises Equipment), HG (Home Gateway), or box. Such a CPE typically serves as an interface between the user's local area network (LAN) and the network of the operator (Internet Service Provider, ISP) to which the user has subscribed to a service offer. Thus, it is a device for accessing the operator's network, through which the traffic characteristics of the various services subscribed to by the user are transmitted.

[0005] The CPE is a crossroads for traffic from or to the user via the operator network, and attacks can be carried out on this device, for example, to intercept sensitive data of the user, such as bank details.

[0006] As an example, the attack includes modifying the configuration of DNS information stored in the CPE, which describes at least one trusted server associated with at least one network interface through which the CPE can communicate.

[0007] As a reminder, the DNS service enables resources (such as types of domain names, URIs (Uniform Resource Identifiers), etc.) to be associated with one or more IP addresses to access the resource. For example, the DNS service allows a terminal connected to the CPE to obtain an IPv4 and / or IPv6 address associated with a domain name. Thus, when a terminal connected to the CPE wants to reach an application server identified by a domain name, the DNS resolution request is relayed by the CPE to at least one of the trusted DNS servers configured in the CPE. Then, the connection between the terminal and the application server is established using the (multiple) IP addresses returned by the DNS server to the CPE.

[0008] If an attacker wants to capture a user's traffic and intercept some of their data, then according to the first example, they can provide the user with the IP address of a malicious application server used by the attacker, rather than the IP address of the (legitimate) application server that the user originally wanted to access. To do this, the attacker can modify the configuration of the DNS information stored in the CPE so that it relays DNS requests sent by the terminal to a malicious DNS server managed by the attacker, rather than the initially configured trusted DNS server. As a result, all communications that require DNS exchanges can be intercepted by the malicious DNS server. The attacker can then redirect the traffic of the attacked user victim to a fraudulent server that will simulate certain sites (e.g., a server for completing financial transactions).

[0009] According to the second example, the attacker can also decide to redirect the application requests sent by the user to a "legitimate" application server to prevent the user from realizing that they are the target of an attack. In this case, the attacker first guides the user's request to a "fraudulent" application server by manipulating the DNS request, and then to a "legitimate" application server. To do this, as in the first example, the attacker can modify the configuration of the DNS information stored in the CPE so that it relays DNS requests sent by the terminal to a malicious DNS server managed by the attacker, rather than the initially configured trusted DNS server. However, in the second example, the fraudulent application server does not "simulate" the requested service, but acts as a relay ("proxy") that terminates the secure association with the user terminal and relays messages between that terminal and the legitimate application server. In doing so, the fraudulent application server accesses the content of the encrypted messages.

[0010] Protecting access to the CPE management interface (which is specifically used to configure DNS information in the CPE) with a password is not sufficient to protect the CPE from the previously described attacks. In fact, since most users do not use the CPE management interface (or are not even aware of its existence), access to this management interface is usually poorly protected. Similarly, protecting access to the CPE management interface with a MAC ("Media Access Control") address may prove ineffective because the attacker can change the MAC address of their terminal so that it is the same as the (multiple) MAC addresses authorized by the CPE. For example, these MAC addresses can actually be maliciously obtained by listening to Wi-Fi exchanges.

[0011] Therefore, a new solution is needed to detect fraudulent modifications of DNS configuration information, especially to maintain the security of user personal data. Summary of the Invention

[0012] The present invention proposes a solution for detecting malicious domain name servers, which is implemented in a device configured with at least one trusted domain name server associated with at least one network interface, and the device is capable of communicating via the at least one network interface.

[0013] Such a device implements:

[0014] - Sending at least one request to activate the domain name resolution verification service to at least one of the trusted servers,

[0015] - Receiving at least one response, the at least one response including at least one domain name generated by the trusted server for the at least one interface,

[0016] - Sending at least one request to resolve the at least one domain name,

[0017] - If the trusted server does not receive a request to resolve the at least one domain name, or if the trusted server receives at least one request to resolve the at least one domain name but includes an anomaly, receiving at least one notification requiring the device to take action.

[0018] Therefore, if a trusted domain name server configured for at least one network interface (such as Ethernet, wireless LAN, etc.) of a device (such as a terminal, CPE, etc.) detects an anomaly in a specific domain name resolution request sent via the interface of the device, the proposed solution allows the device to take action.

[0019] More specifically, according to the proposed solution, the trusted server can generate one or more specific domain names for at least one interface of the device. For example, such a domain name (such as labeled "TARGET_HB_FQDN") can be randomly generated by the trusted server. Therefore, such a domain name is considered unique, and the trusted server is identified as the authorized server for the domain name so generated. The trusted server can send the (multiple) domain names generated for at least one of its interfaces to the device. Therefore, such a domain name is known only to the trusted server and the device. If the trusted server does not receive a request to resolve the domain name or these domain names, or if it receives one or more requests to resolve the domain name or these domain names (for example, hereinafter referred to as "HB") but includes an anomaly (such as the source address of the request to resolve the domain name is not the address of the device), the trusted server can detect the presence of a malicious server.

[0020] In this case, a notification is sent by the trusted server to the device so that the device can take at least one action, for example, correcting the active domain name resolution configuration. Thus, such an action can be automatically performed by the device without any intervention by the user. Therefore, even if the user does not have technical knowledge of the computer system, the DNS configuration information of the device can be reset, or the traffic to or from the malicious application server can be stopped.

[0021] Therefore, the proposed solution helps to improve the robustness of value-added IP services, including DNS services, and protects users from attacks based on name resolution services such as DNS services.

[0022] In addition, the proposed solution does not require any traffic inspection in the network (e.g., in the access network) or any profiling of the communication to detect anomalies. Therefore, the solution can be implemented independently of the underlying connection provisioning.

[0023] It should be noted that the device according to the present invention may embed one or more "DNS clients". In other words, the DNS client can be supported by the operating system (OS) of the device or be application-specific. In the latter case, several DNS clients can be activated on the same device, and each of these clients is identified in a univocal manner. The method according to the present invention can be implemented by one of these DNS clients or be supported by a dedicated application. In particular, each DNS client of the device can implement the above steps. The present invention makes no assumptions about the internal interfaces used between the application and the name resolution function, which is typically a DNS client.

[0024] According to a particular embodiment, the at least one response further includes verification data (denoted, for example, as "CHALLENGE") generated by the trusted server for the at least one activation request. Then, the at least one request for resolving the at least one domain name generated by the device includes a proof of integrity obtained from the verification data.

[0025] When the parsing request is received by the trusted server, the trusted server can thus check the integrity of the parsing request based on the proof of integrity, which helps to improve the security of the proposed solution. For example, the proof of integrity is a hash of the verification data.

[0026] In a particular embodiment, the at least one request for resolving the at least one domain name includes an indicator requesting the trusted server to generate new verification data.

[0027] This change in the verification data helps to strengthen the security of the proposed solution.

[0028] Then, the device can initiate a change in the authentication data. As described in the description of specific embodiments below, the device sends a resolution request labeled, for example, "HB (C, NONCE1)".

[0029] As a variant, the server can initiate a change in the authentication data. Such a change in the authentication data can be implemented in particular on a regular basis or according to other policies local to the name resolution server.

[0030] In particular, the at least one response and / or the resolution request can be encrypted.

[0031] Such encryption makes it possible to preserve the authentication data sent in the response to the activation request (i.e., the response from the trusted server to the device) or the proof of integrity sent in the "HB" resolution request.

[0032] In a particular embodiment, the at least one response further includes recurrence information (denoted, for example, "EPOCH"). The at least one request for resolving the at least one domain name is sent taking into account the recurrence information.

[0033] For example, the recurrence information provides the periodicity of the sending of the resolution request ("HB") by the device, when the device restarts, when connected to a new network, the sending of the resolution request, etc.

[0034] In a particular embodiment, the at least one activation request includes at least one contact address of the device (denoted, for example, "CONTACT_URI").

[0035] In this way, the trusted server can send a notification to the device at this contact address to inform the device of an anomaly or anomalies observed in the domain name resolution. Assume that the device establishes appropriate procedures to be able to receive these messages (e.g., configuration of firewalls, NAT). These procedures are known per se and are not repeated here. An example is described in particular in the document RFC6887 "Port Control Protocol (PCP)" of April 2013.

[0036] According to a particular embodiment, the information describing the at least one trusted server is stored in a registry maintained by the device and its access is protected. Recall that at least one list of at least one trusted server associated with at least one interface of the device is typically configured. According to the invention, this configuration information (i.e., the information describing the at least one trusted server) is stored in a specific registry, the access to which is protected, for example, using a password or an authentication key. In this way, an attacker cannot directly access this configuration information, which helps to strengthen the security of the proposed solution.

[0037] In particular, the registry whose access is protected is different from any other registry used to store other information related to domain name resolution.

[0038] In particular, the location of the protected registry is not predefined and can be different for various devices. When activating the domain name resolution verification service, the location of the registry can be randomly selected in particular.

[0039] According to a specific embodiment, the device is configured to perform at least one action, and the device performs the at least one given action when receiving a notification requesting it to perform (e.g., pre-configured) at least one given action. For example, the at least one action belongs to the group including the following:

[0040] - Replacing the active domain name resolution configuration with the configuration of one of the trusted servers,

[0041] - Disabling outgoing communications other than the communication with one of the trusted servers,

[0042] - Generating a local notification for notifying the user of the modification to the domain name resolution configuration,

[0043] - Requesting to send the active domain name resolution configuration.

[0044] In particular, such actions may have been previously configured for the device. Therefore, when receiving the notification, the device knows the actions it must perform. Therefore, the proposed solution does not involve the user in resolving the exception. Therefore, it is not expected that the user has any specific technical knowledge for implementing the present invention.

[0045] The present invention also relates to a method for detecting malicious domain name servers implemented in a trusted server. Such a trusted server performs the following steps:

[0046] - Receiving at least one request from the device to activate the domain name resolution verification service,

[0047] - Sending at least one response, where the at least one response includes at least one domain name generated by the trusted server for the at least one interface,

[0048] - If the trusted server does not receive a request to resolve the at least one domain name, or if the trusted server receives at least one request to resolve the at least one domain name but includes an exception, sending at least one notification to the device requesting the device to perform an action.

[0049] As already noted, the trusted server can generate one or more specific domain names for at least one interface of the device, and detect a problem in the domain name resolution verification service if a request to resolve a specific domain name is not received, or if a request to resolve a specific domain name is received but includes an anomaly. If a problem is detected, the trusted server can send a notification to at least one contact address of the device carried by the activation request or to the address used by the device to send the activation request. Since the trusted server is authorized for the domain names generated for at least one interface of the device, these verifications are possible.

[0050] According to a particular embodiment, an anomaly is detected if the at least one request to resolve the at least one domain name and the at least one activation request are not from the same device.

[0051] For example, the trusted server compares the address used to send the activation request and the address used to send the request to resolve the at least one domain name. If they are different or not associated with the same device, the trusted server detects an anomaly.

[0052] According to a particular embodiment, the at least one response also includes verification data generated by the trusted server for the at least one activation request. In this case, the at least one request to resolve the at least one domain name includes a proof of integrity obtained from the verification data, and an anomaly is detected if the proof of integrity carried by the at least one request to resolve the at least one domain name is not consistent with the proof of integrity obtained from the verification data known to the trusted server.

[0053] For example, the trusted server randomly generates verification data and sends it in its response. The device calculates the hash of the verification data and sends the hash in the request to resolve the specific domain name. Upon reception, the trusted server can locally calculate the hash of the verification data it knows and compare it with the hash received in the resolution request.

[0054] According to a particular embodiment, the at least one response includes new verification data generated by the trusted server for the device either when the trusted server initiates or when a request is received from the device.

[0055] As previously mentioned, the verification data can be effectively updated either at the initiative of the device or the trusted server, for example, periodically, in order to enhance the security of the proposed solution.

[0056] According to a particular embodiment, the at least one response further includes parsing duplicate information (e.g., denoted as "EPOCH") of the at least one request for parsing the at least one domain name, and if the trusted server does not receive a request for parsing the at least one domain name, or if the at least one request for parsing the at least one domain name is inconsistent with the duplicate information, an anomaly is detected.

[0057] Again, using such information helps to strengthen the security of the proposed solution.

[0058] According to a particular embodiment, the activation request and / or the request for parsing the at least one domain name uses options according to the DNS mechanism as described in document RFC 6891 ("Extension Mechanisms for DNS" (EDNS) in April 2013) to transmit various information (e.g., domain name ("TARGET_HB_FQDN"), authentication data ("CHALLENGE"), duplicate information ("EPOCH"), contact address ("CONTACT_URI"), etc.) between the device and the trusted server.

[0059] In another embodiment, the present invention relates to a corresponding device. Such a device is particularly suitable for implementing a method for detecting malicious domain name servers according to at least one embodiment of the present invention. Therefore, such a device may include various features related to the method according to the present invention, which may be combined or adopted individually. For example, the device is of the type such as CPE, terminal, etc. The device may be connected to a fixed network, a mobile network, a network of connected objects (e.g., a mesh network according to the "Thread" protocol), etc.

[0060] In another embodiment, the present invention relates to a corresponding trusted server. Such a trusted server is particularly suitable for implementing a method for detecting malicious domain name servers according to at least one embodiment of the present invention. Therefore, such a server may include various features related to the method according to the present invention, which may be combined or adopted individually.

[0061] In yet another embodiment, the present invention relates to one or more computer programs, which include instructions for implementing a method for detecting malicious domain name servers according to at least one embodiment of the present invention when the program or these programs are executed by a processor.

[0062] Therefore, the method according to the present invention can be implemented in various ways, particularly in a wired form and / or in a software form.

[0063] In particular, the method according to the present invention can be implemented by a general module, an application, etc. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] Other features and advantages of the present invention will become more apparent upon reading the following description and the drawings of specific embodiments provided as simple illustrative and non - limiting examples, wherein:

[0065] - Figure 1 shows the main steps of a method for detecting malicious domain name servers according to one embodiment;

[0066] - Figure 2 shows the general format of WADE options according to one embodiment;

[0067] - Figure 3 shows an example of WADE options according to one embodiment;

[0068] - Figure 4 shows an example of messages exchanged between a DNS client and a trusted server when no anomalies are detected;

[0069] - Figure 5 shows an example of messages exchanged between a DNS client and a trusted server, where the verification data is modified at the initiative of the DNS client;

[0070] - Figure 6 shows an example of messages exchanged between a DNS client and a trusted server, where the verification data is modified at the initiative of the trusted server;

[0071] - Figure 7 shows an example of messages exchanged between a DNS client and a trusted server, where an anomaly inconsistent with duplicate information is detected;

[0072] - Figure 8 shows an example of messages exchanged between a DNS client and a trusted server, where an anomaly related to the source address is detected;

[0073] - Figure 9 shows an example of messages exchanged between a DNS client and a trusted server for deactivating the domain name resolution verification service;

[0074] - Figure 10 shows a simplified structure of a device (correspondingly, a trusted server) according to one embodiment. DETAILED DESCRIPTION

[0075] GENERAL PRINCIPLES

[0076] This context is that of a device (e.g., a terminal, a CPE) configured with information describing at least one trusted domain name server associated with a network interface, capable of communicating via that network interface.

[0077] The general principle of the present invention is based on generating, by a trusted server, at least one specific domain name for at least one interface of the device, and establishing a process for sending a resolution request related to the specific domain name. Thus, if the trusted server does not receive any request for resolving the specific domain name, or if the request for resolving the specific domain name received by it includes an anomaly, the trusted server can detect a problem in the domain name resolution service. Then, the trusted server can notify the device, and then the device can take appropriate actions.

[0078] Regarding Figure 1 , the main steps implemented for detecting a malicious domain name server according to the present invention are presented.

[0079] Consider a device H11 configured with at least one trusted domain name server DNS 12 associated with at least one network interface, the device being capable of communicating via the network interface.

[0080] During a first step 111, the device 11 sends, via at least one network interface, at least one request ACTIV for activating the domain name resolution verification service to the trusted server 12. During step 121, the trusted server 12 receives the at least one activation request ACTIV.

[0081] The activation request can in particular be a dedicated request, such as a DNS request reserved for activating the domain name resolution verification service. An example of such a dedicated request is a request for resolving a dedicated domain name, which can trigger the activation of the verification service. The dedicated domain name can be a name configured at the time of subscribing to the service (e.g., "peraspera.example") or a domain name reserved for this purpose and usable by all operators (e.g., "peraspera.arpa").

[0082] As a variant, the activation request can be a "non-dedicated" request. In this case, the device does not generate a DNS request related to a domain name dedicated to activating the domain name resolution verification service, but uses a conventional DNS request, such as a DNS request sent for an application embedded in the device, and inserts information for activating the domain name service therein. Thus, the conventional DNS request is diverted by inserting specific information (e.g., in the form of a new option according to the DNS extension mechanism described below) into the conventional DNS request.

[0083] During step 122, the trusted server 12 can generate at least one specific domain name for the network interface used, and send at least one response including the (multiple) specific domain names to the device 11. Thus, such a domain name is considered unique, and the trusted server is authorized for the domain name so generated. According to Figure 1In the example shown, the trusted server sends a single response REP carrying a unique domain name. The device 11 receives the response REP during step 112.

[0084] Then, during step 113, the device 11 may send at least one request REQ DNS to resolve the unique domain name to the trusted server 12. Such a resolution request related to the unique domain name is also referred to hereinafter as HB ("Heartbeat").

[0085] If the trusted server 12 receives the request REQ DNS during step 123, but the request REQ DNS includes an anomaly, the trusted server 12 sends a notification NOTIF to the device 11 during step 124, requesting it to perform an action.

[0086] If the trusted server 12 does not receive any request REQ DNS related to the unique domain name transmitted to the device 11 when activating the process (step 122 / 112), the trusted server 12 sends a notification NOTIF to the device 11, requesting it to perform an action, for example, after a waiting period. The waiting period may be predefined in particular, configured in the trusted server, known to the device, or sent to the device, etc.

[0087] Thus, the device 11 may receive a notification NOTIF during step 114, requesting it to perform an action (e.g., a predefined action). Then, the device may perform such an action without any interaction with the user of the device or the administrator of the local area network (e.g., the administrator of a home network, the administrator of a CPE).

[0088] As described below, during the processing of the domain name resolution request, the trusted server may use different information to detect anomalies.

[0089] In particular, verification data and / or duplicate information may be sent from the trusted server to the device in the response REP and used by the device to manage the sending of the request REQ DNS to resolve the unique domain name to the trusted server. For example, if the activation request ACTIV and the request REQ DNS to resolve the unique domain name do not come from the same device, or if the integrity proof obtained from the verification data and transmitted by the request REQ DNS is inconsistent with the integrity proof obtained from the verification data known to the trusted server and locally maintained by the trusted server, or if the sending of the (multiple) requests REQ DNS does not conform to the duplicate information, or if the request REQ DNS includes information about DNS relay, an anomaly can be detected in particular.

[0090] Detailed description of specific embodiments

[0091] Initial configuration

[0092] The following describes detailed embodiments of the present invention. Consider that a user of a device (e.g., a terminal) wants to activate a domain name resolution verification service. Hereinafter, such a service is referred to as "PER ASPERA" ("Protecting Each DNS Client Against Malicious DNS Server Exchanges, Traffic Interception, and Data Theft").

[0093] For example, a user can subscribe to the PER ASPERA service using a dedicated interface. The PER ASPERA service can be specifically provided to terminals directly connected to the network of the service provider or reserved for the provision of CPE-based offerings. As already noted, the "device" is a terminal or CPE used by a user who wants to utilize the PER ASPERA service. It should be noted that the PERASPERA service can be proposed by a connectivity service provider, a DNS service provider, etc. In particular, a user can call upon a DNS service provider different from the provider that provides them with connectivity.

[0094] The user's device can be connected to several networks using the same access device or different devices. The user's device can use the same DNS service for all access networks (fixed and mobile) to which it can be connected. The PER ASPERA service can be proposed independently of the nature of the (multiple) access networks used by the user's device. In addition, the PER ASPERA server can be used for only some of the interfaces.

[0095] Conventionally, the device or at least one network interface of the device is configured with at least one list of at least one trusted DNS server. To improve the security of the proposed solution, in the embodiments described herein, the connection between the device and the (multiple) trusted servers is secure. Thus, the (multiple) trusted servers can support at least one encryption scheme based on the use of one or another of the following protocols: TLS-based DNS (DoT), DTLS-based DNS (DoD), HTTPS-based DNS (DoH), QUIC-based DNS (DoQ), CoAP-based DNS (DoC), etc.

[0096] A list of (one or more) trusted servers can be configured using a mechanism based on neighbor Designated Name Resolver (DNR) discovery, as described in the August 2022 document "DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)", a mechanism based on key exchange (IKE, "Internet Key Exchange", as described in the September 2022 document "Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS"), etc. If the device has several network interfaces, at least one list of trusted servers can be configured via the network interfaces (wired, wireless, 5G, etc.). In this case, the list of at least one trusted server can be associated with the identifier of the network interface involved.

[0097] According to a particular embodiment, the device can also be configured with at least one action. For example, the device is configured with an index list of predefined actions. Such a list can (non-exhaustively) include the following actions:

[0098] - Policy / Action Index "0": Replace the active domain name resolution configuration with the configuration of one of the trusted servers,

[0099] - Policy / Action Index "1": Disable outgoing communication on a given interface except for communication with one of the trusted servers in the trusted servers,

[0100] - Policy / Action Index "2": Generate a local notification to inform the user of the modification of the domain name resolution configuration,

[0101] - Policy / Action Index "3": Request to send the active domain name resolution configuration,

[0102] - And so on.

[0103] According to a particular embodiment, information describing the (one or more) trusted servers (i.e., the configuration of the list of at least one trusted server) is stored in a registry maintained by the device and its access is protected. Access to this registry can be implemented with a strong authentication mechanism in particular (for example, using a dedicated password or a multi-level verification key). When the PERASPERA service is activated, the location of such a registry can be decided in particular. The registry can correspond to a dedicated entry in the Windows© registry, a file, a database, etc.

[0104] In particular, such a registry is different from any other registry used to store other information related to domain name resolution. Thus, the registry storing the list(s) of at least one trusted server is isolated from other registries used to store information for DNS management.

[0105] Possibly, the information describing the trusted server(s) can be replicated, stored on the one hand in a registry whose access is protected, and on the other hand in a registry commonly used to store information related to domain name resolution.

[0106] The purpose of this isolation is to prevent the list of trusted DNS servers from being modified by malicious applications or subsequent fraudulent access to the device.

[0107] Specifically, an application accessing the local DNS configuration without user consent may be able to modify the active DNS configuration, but not the trusted server configuration stored in a registry whose access is protected.

[0108] Activate the PER ASPERA service

[0109] Hereinafter, the term "DNS client" is used to denote the device implementing the proposed solution or at least one network interface of the device.

[0110] As Figure 1 As described in, during the first step 111, the DNS client sends at least one DNS request to at least one of its trusted servers to activate the PER ASPERA service. As already indicated, this activation request can be dedicated to the activation of the domain name resolution verification service. In this case, the activation request is a DNS request reserved for the PER ASPERA service. As a variant, the activation request can be non-dedicated, especially when a traditional request is used for the purpose of using an application. In this case, the DNS client uses a request sent, for example, by an application embedded in the device and inserts the information required to activate the PER ASPERA service.

[0111] It should be noted that if the same trusted server is associated with several interfaces of the device, each interface can send an activation request; each of these requests is routed to the trusted server through the relevant interface. In fact, sending these various requests via the interface makes it possible to transmit the external address of the device (DNS client) to the trusted server, which makes it reachable via that interface.

[0112] If several lists of trusted servers are configured, the activation request is sent to each of these lists, i.e., to at least one trusted server in each list. This makes it possible to control their DNS activities in particular when all the interfaces of the device are associated with different trusted servers.

[0113] According to one embodiment of the present invention, the (multiple) activation requests use a new option according to the EDNS mechanism. Such an option is hereinafter referred to as WADE ("EDNS Option for Monitoring DNS Association to Prevent Exchange, Interception, and Theft"). According to the OPT pseudo-resource record (RR), the extended request according to the EDNS mechanism is identified.

[0114] Figure 2 The general format of the WADE option is shown.

[0115] As Figure 2 shown, the "OPTION-DATA" data field of the OPT RR provides six control indicators, for example, in the form of 6-bit H, N, C, T, E, U:

[0116] - The H bit, also known as "HB_ENABLE" (Heartbeat Enable), set to the value "1" indicates a request to activate the PER ASPERA service, while the value "0" is used to deactivate the PER ASPERA service.

[0117] - The N bit set to the value "1" indicates the presence of the "NONCE" field.

[0118] - The C bit set to the value "1" indicates the presence of the "CHALLENGE" field.

[0119] - The T bit set to the value "1" indicates the presence of the "TARGET_HB_FQDN" field.

[0120] - The E bit set to the value "1" indicates the presence of the "EPOCH" field.

[0121] - The U bit set to the value "1" indicates the presence of the "CONTACT_URI" field.

[0122] These various fields ("NONCE", "CHALLENGE", "TARGET_HB_FQDN", "EPOCH", "CONTACT_URI") are given hereinafter. In particular, the "CHALLENGE", "TARGET_HB_FQDN", and "EPOCH" fields are filled by a trusted server.

[0123] When several of these fields are carried in the same WADE option, these various fields are inserted in the order of the check bits. Before the variable parameters is a field indicating the parameter size.

[0124] As Figure 3 shown, the activation request including the WADE option uses the H bit and optionally the U bit, which is set to the value "1". The other bits (N, C, T, and E) can be set to the value "0".

[0125] Thus, the H bit can take the value "1" to indicate a request to activate the PER ASPERA service. The "U" bit can also take the value "1" to indicate the presence of the "CONTACT_URI" field. A "URI_Length" field can be provided in particular to indicate the size of the parameters present in the "CONTACT_URI" field, as Figure 3 shown.

[0126] Such a "CONTACT_URI" field can be present in a request to activate the PER ASPERA service. This field lists the (multiple) contact identifiers that a trusted server (which receives the activation request) can use to report anomalies observed in the DNS configuration information (e.g., by sending a notification to the DNS client asking it to take action).

[0127] If the U bit is set to the value "1", i.e., if the "CONTACT_URI" field is present, this means that the (multiple) contact addresses for sending the notification are those entered in the "CONTACT_URI" field.

[0128] If the U bit is set to the value "0", i.e., if the "CONTACT_URI" field is absent, this means that the contact address for sending the notification is the address (and port number) used by the DNS client to send this activation request.

[0129] It should be noted that the PER ASPERA service can be deactivated by the device at any time. For this purpose, a request containing the WADE option can be sent from the DNS client to the trusted server using the H bit set to the value "0". In the following, it is assumed that the service is activated.

[0130] It should be noted that such a WADE option is only inserted into DNS requests intended for the trusted server. This verification is based, for example, on the destination IP address of the DNS request or the ADN (Authenticated Domain Name) of the target DNS server.

[0131] Response from the trusted server

[0132] As shown with respect to Figure 1 During step 121, at least one trusted server receives at least one request to activate the PER ASPERA service.

[0133] If the trusted server does not support the WADE option, it can respond with an error message. The DNS client can possibly select another trusted server configured in its list, send an activation request to the same server without the WADE option, terminate the communication, and generate a local notification (application, user, etc.), etc.

[0134] If the trusted server supports the WADE option, it can process the received activation request. In particular, the trusted server can extract the information transmitted in the WADE option, especially the information transmitted in the "CONTACT_URI" field when applicable. For example, the trusted server can extract the source IP address and port number from the activation request. This information can be stored for later use. Thus, the trusted server can maintain one or more source addresses for each DNS client.

[0135] During Figure 1 step 122, the trusted server can in particular prepare at least one response and send it to the DNS client. Such a response can in particular take the form of a DNS request that includes the WADE option as Figure 2 shown.

[0136] In particular, such a response including the WADE option uses the H and T bits and may use the C and E bits (set to the value "1"). The other bits (U, N) can be set to the value "0". Thus, the H bit can be set to "1" to indicate acceptance of the request to activate the PERASPERA service.

[0137] The "U" bit can also be set to "1" to indicate the presence of the "TARGET_HB_FQDN" field. The "TARGET_HB_FQDN_Length" field can be provided in particular to indicate the size of the parameters present in the "TARGET_HB_FQDN" field.

[0138] Such a "TARGET_HB_FQDN" field includes one or more specific domain names generated by the trusted server for the considered DNS client. The trusted server is authorized for these domain names. Thus, they are considered unique and are known only to the DNS client and the trusted server. For this purpose, they are randomly generated, for example.

[0139] Possibly, the C bit can take the value "1" to indicate the presence of the "CHALLENGE" field. The "CHALLENGE_Length" field can be provided in particular to indicate the size of the parameters present in the "CHALLENGE" field.

[0140] Such a "CHALLENGE" field includes verification data that can be used by the DNS client to determine the integrity proof. For example, such verification data can be randomly generated and used by the DNS client to calculate an integrity proof such as a hash. Such an integrity proof can then be inserted by the DNS client into subsequent DNS requests intended for the trusted server.

[0141] Possibly, the E bit can take the value "1" to indicate the presence of the "EPOCH" field. The "EPOCH_Length" field can be provided specifically to indicate the size of the parameter present in the "EPOCH" field.

[0142] Such an "EPOCH" field includes repetitive information, which is used by the DNS client to send "HB" requests for resolving domain names. For example, such a field indicates the periodicity of the HB requests from the DNS client.

[0143] If the "EPOCH" and "CHALLENGE" fields are activated, the C, T, and E bits are set to the value "1", and the U and N bits are set to the value "0".

[0144] Specifically, the trusted server can store the information transmitted to each DNS client.

[0145] In a particular embodiment, the trusted server can control the TTL ("Time To Live") field of the response to force the DNS client to update the activation of the PER ASPERA service by returning an activation request.

[0146] Request to resolve the domain name of the TARGET_HB_FQDN field

[0147] As regarding Figure 1 indicated, the DNS client receives a response from the trusted server during step 112.

[0148] The DNS client can extract the information contained in the WADE option, particularly in the "TARGET_HB_FQDN" field. If the information is present in the "EPOCH" and / or "CHALLENGE" fields, that information can also be extracted. The DNS client can store this information in association with at least one trusted server and at least one interface. Several responses containing the WADE option can be sent by the trusted server to the DNS client. All this information can be stored by the DNS client in an appropriate registry, the access to which can be protected.

[0149] As Figure 1 shown, the DNS client can then send a request to resolve the domain name present in the "TARGET_HB_FQDN" field during step 113. Such a request can particularly take the form of a DNS request with a WADE option as Figure 2 shown. Specifically, such a request containing the WADE option can use the H and N bits set to the value "1". The other bits (C, T, E, and U) can be set to the value "0".

[0150] The N bit can be set to "1" to indicate the presence of the "NONCE" field. The "NONCE_Length" field can be provided in particular to indicate the size of the parameter present in the "NONCE" field.

[0151] Such a "NONCE" field includes, for example, an integrity proof generated from the authentication data sent in the "CHALLENGE" field.

[0152] Figure 4 An example of messages exchanged between the DNS client 41 and the trusted DNS server 42 is shown.

[0153] As an example, consider that the DNS client 41 sends an activation request using its address @1 as the source address, and the trusted server 42 constructs a response including the "TARGET_HB_FQDN", "EPOCH", and "CHALLENGE" fields. At the end of these steps of receiving at least one activation request and constructing at least one response (denoted as Activ. PER APSERA 411), the trusted server 42 has the information contained in the "TARGET_HB_FQDN", "EPOCH", and "CHALLENGE" fields, as well as the source address (@1) of the activation request.

[0154] According to the example considered, taking into account the value indicated in the "EPOCH" field of the received response, the DNS client 41 can in particular send one or more DNS requests to resolve the domain name indicated in the "TARGET_HB_FQDN" field (labeled HB). For example, the "EPOCH" includes repetitive information indicating the transmission period T1 of the HB request. Thus, a first HB request to resolve the domain name indicated in the "TARGET_HB_FQDN" field can be sent at time T0 + T1, a second HB request to resolve the domain name indicated in the "TARGET_HB_FQDN" field can be sent at time T0 + 2*T1, a third HB request to resolve the domain name indicated in the "TARGET_HB_FQDN" field can be sent at time T0 + 3*T1, and so on.

[0155] Such HB ("heartbeat") requests signal the presence of an activity associated with the DNS client 41 to the trusted server 42.

[0156] According to the example considered, the DNS client 41 can in particular calculate the hash of the authentication data transmitted in the "CHALLENGE" field of the response received during the PER ASPERA activation phase. Such a hash can in particular be inserted into the "NONCE" field of the HB request containing the WADE option.

[0157] According toFigure 4 In the example shown, the DNS client 41 sends a first HB request (412) to resolve the domain name indicated in the "TARGET_HB_FQDN" field at time T0+T1, including a proof of integrity in the "NONCE" field. Once the first HB request (412) is received, the trusted server 42 can in particular check whether the source address (@1) of the activation request and the source address (src@) of the first HB request are the same, i.e., identify the same device (src@=@1). If this is not the case, an anomaly is detected. The trusted server 42 can also check that the proof of integrity included in the "NONCE" field of the HB request is consistent with the proof of integrity locally determined from the verification data stored in the trusted server 42 (as recorded in the "CHALLENGE" field in the response sent by the trusted server). In particular, the trusted server 42 can calculate the hash of the verification data (e.g., perform a "Hash(CHALLENGE)" calculation, where Hash represents the hash function corresponding to the hash function applied by the DNS client 41 to generate the hash of the verification data (e.g., the May 2011 document RFC 6234 "US Secure Hash Algorithms (SHA and SHA based HMAC and HKDF)"), and check whether it is equal to the hash sent in the "NONCE" field. If this is not the case, an anomaly is detected by the trusted server 42. The trusted server 42 can also check whether the repetition information specified in the "EPOCH" field is respected. If this is not the case, an anomaly is detected. As a variant, the WADE option can be used to convey an indication of the "hash" function to be used by the DNS client. For this purpose, the "I" bit is defined in the "unassigned" bit described in Figure 2 is described in.

[0158] When the "I" bit is set to "1", the identity of the "hash" function (e.g., SHA2-256) is entered in the body of the WADE option.

[0159] The DNS client 41 can then send a second HB request (413) to resolve the domain name indicated in the TARGET_HB_FQDN field at time T0+2T1, including a proof of integrity in the NONCE field. The trusted server 42 can in particular check whether the source address (@1) of the activation request and the source address (src@) of the second HB request are the same (src@=@1), whether the verification data hash (Hash (CHALLENGE)) is equal to the hash sent in the NONCE field, and whether the repetition information included in the "EPOCH" field is respected.

[0160] The DNS client 41 may send a third HB request (414), etc.

[0161] In Figure 4 In the example shown, no anomaly is detected.

[0162] In a particular embodiment, the information transmitted when activating the PERASPERA service may be modified at the initiative of the trusted server 42 or the DNS client 41.

[0163] Figure 5 An example of the messages exchanged between the DNS client 41 and the trusted server 42 is shown, where a request is made to modify the authentication data at the initiative of the DNS client 41.

[0164] For example, consider that the DNS client 41 sends an activation request using its address @1, and the trusted server 42 constructs a response (Activ. PER APSERA 511) including the fields "TARGET_HB_FQDN", "EPOCH", and "CHALLENGE1".

[0165] According to Figure 5 In the example shown, the DNS client 41 sends a first HB request (512) to resolve the domain name indicated in the "TARGET_HB_FQDN" field at time T0+T1, including an integrity proof in the "NONCE1" field. When receiving the first HB request (512), the trusted server 42 may in particular check whether the source address (@1) of the activation request and the source address (src@) of the first HB request are identical. The trusted server 42 may also check that the integrity proof included in the "NONCE1" field of the HB request is consistent with the integrity proof locally determined from the authentication data carried by the "CHALLENGE1" field. In particular, the trusted server 42 may calculate the hash of the authentication data (Hash (CHALLENGE1)) and check whether it is equal to the hash sent in the "NONCE1" field. The trusted server 42 may also check whether the repetition information specified in the "EPOCH" field is respected.

[0166] The DNS client 41 may at any time request a modification of the authentication data ("CHALLENGE1"). To this end, the DNS client may send a second HB request (513) to resolve the domain name indicated in the "TARGET_HB_FQDN" field, including an integrity proof in the "NONCE1" field, which is calculated based on the authentication data of the "CHALLENGE1" field. To inform the trusted server 42 that the DNS client 41 is requesting new authentication data, the C and N bits are set to "1".

[0167] Upon receiving the message, the trusted server 42 may accept the request and generate new verification data, which is sent to the DNS client 41 (514) in the response of the WADE option included in the "CHALLENGE2" field.

[0168] The DNS client 41 sends a third HB request (515) at time T0 + 2T1 to resolve the domain name indicated in the "TARGET_HB_FQDN" field, including the integrity proof in the "NONCE2" field. Such an integrity proof is obtained from the new "CHALLENGE2" verification data. Once the third HB request (515) is received, the trusted server 42 may in particular check whether the source address (@1) of the activation request and the source address (src@) of the third HB request are the same, i.e., identify the same device (src@ = @1). The trusted server 42 may also check that the integrity proof included in the "NONCE2" field of the HB request is consistent with the integrity proof locally determined from the verification data stored in the trusted server 42 (such as included in the "CHALLENGE2" field of the response sent by the trusted server). In particular, the trusted server 42 may calculate the hash of the verification data (Hash(CHALLENGE2)) and check whether it is equal to the hash included in the "NONCE2" field. The trusted server 42 may also check whether the duplicate information included in the "EPOCH" field is observed.

[0169] The DNS client 41 may send a fourth HB request (516) and so on.

[0170] Figure 6 An example of messages exchanged between the DNS client 41 and the trusted server 42 is shown, where the request modifies the verification data at the initiative of the trusted server 42.

[0171] For example, consider that the DNS client 41 sends an activation request using its address @1, and the trusted server 42 constructs a response (Activ. PER APSERA 611) including the "TARGET_HB_FQDN", "EPOCH", and "CHALLENGE1" fields.

[0172] According to Figure 6In the example shown, the DNS client 41 sends a first HB request (612) to resolve the domain name indicated in the "TARGET_HB_FQDN" field at time T0+T1, including a proof of integrity in the "NONCE1" field. When receiving the first HB request (612), the trusted server 42 can in particular check whether the source address (@1) of the activation request and the source address (src@) of the first HB request are identical. The trusted server 42 can also check that the proof of integrity specified in the "NONCE1" field of the HB request is consistent with the proof of integrity determined from the verification data recorded in the "CHALLENGE1" field. In particular, the trusted server 42 can compute the hash of the verification data (Hash (CHALLENGE1)) and check whether it is equal to the hash recorded in the "NONCE1" field. The trusted server 42 can also check whether the duplicate information contained in the "EPOCH" field is respected.

[0173] The trusted server 42 can decide at any time to modify the verification data ("CHALLENGE1").

[0174] For example, when receiving a second HB request (613) to resolve the domain name indicated in the "TARGET_HB_FQDN" field (including a proof of integrity recorded in the "NONCE1" field, which is computed based on the verification data in the "CHALLENGE1" field), the trusted server 42 can generate new verification data. The trusted server 42 can send the new verification data to the DNS client 41 in the response including the WADE option recorded in the "CHALLENGE2" field (614). To notify the DNS client 41 that the trusted server 42 has generated the new verification data sent in the "CHALLENGE2" field, the C bit is set to "1".

[0175] The DNS client 41 may send a third HB request (615) for resolving the domain name indicated in the "TARGET_HB_FQDN" field at time T0 + 2T1, including the integrity proof contained in the "NONCE2" field. Such an integrity proof is obtained from the new "CHALLENGE2" verification data. Once the third HB request (615) is received, the trusted server 42 may in particular check whether the source address (@1) of the activation request and the source address (src@) of the third HB request are the same, i.e., identify the same device (src@ = @1). The trusted server 42 may also check that the integrity proof recorded in the "NONCE2" field of the HB request is consistent with the integrity proof locally determined from the verification data stored in the trusted server 42 (as contained in the "CHALLENGE2" field in the response sent by the trusted server). In particular, the trusted server 42 may compute the hash of the verification data (Hash(CHALLENGE2)) and check whether it is equal to the hash sent in the "NONCE2" field. The trusted server 42 may also check whether the repetition information contained in the "EPOCH" field is complied with.

[0176] The DNS client 41 may send a fourth HB request (616), etc.

[0177] For example, for security purposes, the trusted server 42 may modify the verification data regularly.

[0178] Regarding Figure 7 , the detection of an exception when the repetition information contained in the "EPOCH" field is not complied with is now given.

[0179] Figure 7 An example of the messages exchanged between the DNS client 41 and the trusted server 42 is shown. For example, consider that the DNS client 41 sends an activation request using its address @1, and the trusted server 42 constructs a response (Activ. PER APSERA 711) including the "TARGET_HB_FQDN", "EPOCH", and "CHALLENGE" fields.

[0180] According to Figure 7In the example shown, the DNS client 41 sends a first HB request (712) to resolve the domain name indicated in the "TARGET_HB_FQDN" field, including a proof of integrity recorded in the "NONCE" field. Once the first HB request (712) is received, the trusted server 42 can in particular check whether the source address (@1) of the activation request and the source address (src@) of the first HB request are the same. The trusted server 42 can also check that the proof of integrity included in the "NONCE" field of the HB request is consistent with the proof of integrity locally determined from the verification data included in the "CHALLENGE" field. The trusted server 42 can also check whether the repetition information recorded in the "EPOCH" field is complied with.

[0181] The trusted server 42 notes, for example, that it does not receive any HB requests at times T0+T1, T0+2T1, and T0+3T1. Thus, it detects that the repetition information (repetition of requests with period T1) included in the "EPOCH" field is not complied with, and sends at least one notification asking the DNS client 41 to take action.

[0182] For example, one or more notification messages 713 are sent to the address entered in the "CONTACT_URI" field of the DNS client 41, or to the address used by the DNS client 41 to send the activation request.

[0183] For example, the notification message can be of types such as Push HTTPS, Update DNS, etc. Such a message can in particular include an index corresponding to a given action, for example pre-configured. For example, if the notification message includes an index equal to 0 (Notif. (Action = 0)), the DNS client takes actions such as replacing the active domain name resolution configuration with the configuration of one of the trusted servers. If the notification message includes an index equal to 1 (Notif. (Action = 1)), the DNS client takes actions such as "disabling the outgoing communications of the considered interface except for the communication with one of the trusted servers" and the like.

[0184] When a malicious DNS server 73 has been configured in the device embedding the DNS client 41, the exchange shown can in particular be observed Figure 7 and this malicious server 73 blocks all or some of the DNS requests sent by the DNS client 41. The DNS client 41 can take one or more actions when receiving the (multiple) notification messages, such as reinstalling the trusted DNS configuration, blocking certain communications, etc.

[0185] Once the trusted DNS configuration has been reinstalled, e.g., (reinstallation of information describing the trusted DNS server), the trusted server 42 can receive HB requests again.

[0186] Regarding Figure 8 , the detection of anomalies when the source address of the HB request is different from the source address of the activation request is now presented. Similar steps can be implemented when the integrity proof transmitted by the HB request is inconsistent with the integrity proof locally determined by the trusted server based on the verification data known to the trusted server. Depending on one and / or other of these cases, this generally means that the HB request has been relayed by another potentially malicious DNS server. Thus, the trusted server can detect that the HB request (or any other DNS request) sent by the DNS client has been intercepted by another DNS server before being routed to the trusted server.

[0187] Figure 8 An example of messages exchanged between the DNS client 41 and the trusted server 42 is shown. For example, consider that the DNS client 41 sends an activation request using its address @1, and the trusted server 42 constructs a response (Activ. PER APSERA 811) including fields "TARGET_HB_FQDN", "EPOCH", and "CHALLENGE".

[0188] According to Figure 8 the example shown, the DNS client 41 sends a first HB request (812) to resolve the domain name indicated in the "TARGET_HB_FQDN" field, including the integrity proof recorded in the "NONCE" field. Once the first HB request (812) is received, the trusted server 42 can in particular check whether the source address of the activation request (@1) and the source address of the first HB request (src@) are the same. The trusted server 42 can also check whether the integrity proof contained in the "NONCE" field of the HB request is consistent with the integrity proof determined from the verification data recorded in the "CHALLENGE" field. The trusted server 42 can also check whether the repetition information specified in the "EPOCH" field is complied with.

[0189] The DNS client 41 then sends a second HB request (813) to resolve the domain name indicated in the "TARGET_HB_FQDN" field, including the integrity proof in the "NONCE" field. However, as Figure 8As shown, the second HB request (813) is intercepted by server F83 and relayed to the trusted server 42. When receiving the second HB request (813), the trusted server 42 notices that the source address (@1) of the activation request and the source address (src@) of the second HB request are inconsistent (src@!= @1). Therefore, it detects an anomaly and detects that the second HB request may have been relayed by another potentially malicious DNS server (F83). The trusted server 42 sends at least one notification 814 requesting the DNS client 41 to take action. For example, one or more notification messages are sent to the address entered in the CONTACT_URI field of the DNS client 41, or to the address used by the DNS client 41 to send the activation request. For example, such a message can be of the DNS response type relayed by the malicious server 83, including an index corresponding to a given action, e.g., pre-configured, to be executed by the DNS client. For example, if the DNS response includes an index equal to 3 (Rep.(Action = 3)), the DNS client takes an action such as "request the identity of the active DNS server to be sent". If the DNS response includes an index equal to 0 (Rep. (Action = 0)), the DNS client takes an action such as replacing the active domain name resolution configuration with the configuration of one of the trusted servers. It should be noted that the trusted server 42 can use an IP address different from the IP address used when activating the PER ASPERA service to trigger the execution of several actions for HB exchange.

[0190] The exchange shown can be particularly observed when the malicious DNS server 83 has been configured in the device embedding the DNS client 41, and the malicious server 83 acts like an intermediate DNS relay ("proxy") that relays messages between the DNS client 41 and the trusted server 42. Figure 8 The exchange shown can be particularly observed when the malicious DNS server 83 has been configured in the device embedding the DNS client 41, and the malicious server 83 acts like an intermediate DNS relay ("proxy") that relays messages between the DNS client 41 and the trusted server 42.

[0191] Once the trusted DNS configuration has been reinstalled, e.g., (reinstallation of the information describing the trusted DNS server), the trusted server 42 can receive the HB request again.

[0192] In a particular embodiment, the trusted server 42 can also include the EDE option, as described in the October 2020 document RFC8914 "Extended DNS Errors", to notify the DNS client that the trusted server has observed a DNS error. When receiving this response, the DNS client can execute the action indicated in the response. As a variant, the WADE option can be used to indicate the action to be executed by the DNS client.

[0193] For this purpose, in Figure 2The "A" bit is defined in the "unassigned" bits shown. When the "A" bit is set to "1", the action index is input into the body of the WADE option.

[0194] Finally, regarding Figure 9 , an example of the deactivation of the PER ASPERA service for at least one interface of the device is presented. For example, consider that the DNS client 41 sends an activation request using its address @1, and the trusted server 42 constructs a response (Activ. PER APSERA 911) including the fields "TARGET_HB_FQDN", "EPOCH", and "CHALLENGE".

[0195] According to Figure 9 the example shown, when the DNS client 41 wants to deactivate the PER ASPERA service, it sends an HB request (912) to resolve the domain name indicated in the "TARGET_HB_FQDN" field, including a proof of integrity in the "NONCE" field, which is calculated based on the verification data recorded in the "CHALLENGE" field. To notify the trusted server 42 that the DNS client 41 wants to deactivate the PER ASPERA service, the H bit "HB_ENABLE" is set to "0".

[0196] Upon receiving such a request, the trusted server 42 checks for no anomalies. For example, if the proof of integrity included in the NONCE field of the HB request 912 does not match the proof of integrity locally calculated by the trusted server 42 for the verification data recorded in the CHALLENGE field and locally stored for this DNS client, the trusted server 42 may reject the HB request 912 and return an error message.

[0197] If it detects no anomalies, the trusted server 42 verifies the deactivation of the PER ASPERA service.

[0198] Simplified structure of a device and a trusted server according to an embodiment

[0199] Finally, regarding Figure 10 , a simplified structure of a device (correspondingly, a trusted server) implementing a method for detecting a malicious server according to one of the above embodiments is presented.

[0200] As Figure 10As shown, such a device (correspondingly, a trusted server) includes a memory 101E (correspondingly, 101S) (including, for example, a buffer memory), and a processing unit 102E (correspondingly, 102S). The processing unit 102E (correspondingly, 102S) is equipped with, for example, a processor P and is controlled by a computer program Pg 103E (correspondingly, 103S), implementing the method for detecting a malicious server according to one of the above embodiments.

[0201] At initialization, the code instructions of the computer program 103E are loaded into the RAM memory, for example, before being executed by the processor of the processing unit 102E. The processor of the processing unit 102E implements the steps of the method for detecting a malicious server according to one of the above embodiments according to the instructions of the computer program 103E, to:

[0202] - Send at least one request to activate the domain name resolution verification service to at least one of the trusted servers,

[0203] - Receive at least one response, the at least one response including at least one domain name generated by the trusted server for the at least one interface,

[0204] - Send at least one request to resolve the at least one domain name,

[0205] - If the trusted server does not receive a request to resolve the at least one domain name, or if the trusted server receives at least one request to resolve the at least one domain name but includes an anomaly, receive at least one notification requiring the device to take an action.

[0206] At initialization, the code instructions of the computer program 103S are loaded into the RAM memory, for example, before being executed by the processor of the processing unit 102S. The processor of the processing unit 102S implements the steps of the method for detecting a malicious server according to one of the above embodiments according to the instructions of the computer program 103S, to:

[0207] - Receive at least one request to activate the domain name resolution verification service from the device,

[0208] - Send at least one response, the at least one response including at least one domain name generated by the trusted server for the at least one interface,

[0209] - If the trusted server does not receive a request to resolve the at least one domain name, or if the trusted server receives at least one request to resolve the at least one domain name but includes an anomaly, send at least one notification to the device requiring the device to perform an action.

Claims

1. A method for detecting malicious domain name servers, the method being implemented in a device configured with at least one trusted domain name server associated with at least one network interface, the device being capable of communicating via the at least one network interface, the method implementing: - Sending (111) at least one request to activate the domain name resolution verification service to at least one of the trusted servers, - Receiving (112) at least one response, the at least one response including at least one domain name generated by the trusted server for the at least one interface, - Sending (113) at least one request to resolve the at least one domain name, - If the trusted server does not receive a request to resolve the at least one domain name, or if the trusted server receives at least one request to resolve the at least one domain name but includes an anomaly, receiving (114) at least one notification requesting the device to take an action.

2. The method according to claim 1, wherein The at least one response further includes verification data generated by the trusted server for the at least one activation request, and the at least one request to resolve the at least one domain name includes a proof of integrity obtained from the verification data.

3. The method according to claim 2, wherein The at least one request to resolve the at least one domain name includes an indicator requesting the trusted server to generate new verification data.

4. The method according to any one of claims 1 to 3, characterized in that The at least one response and / or the request to resolve the at least one domain name is encrypted.

5. The method according to any one of the preceding claims, characterized in that, The at least one response further includes duplicate information, and the at least one request to resolve the at least one domain name is sent taking into account the duplicate information.

6. The method according to any one of the preceding claims, characterized in that, The at least one activation request includes at least one contact address of the device.

7. The method according to any one of the preceding claims, characterized in that, Information describing the at least one trusted server is stored in a registry maintained by the device and whose access is protected.

8. The method according to any one of the preceding claims, characterized in that The device performs at least one action when receiving a notification requesting it to perform at least one given action, the at least one action belonging to the group including the following: - Replacing the active domain name resolution configuration with the configuration of one of the trusted servers, - Disabling outgoing communications other than communications with one of the trusted servers, - Generating a local notification for notifying the user of the modification to the domain name resolution configuration, - Requesting the transmission of the active domain name resolution configuration.

9. A method for detecting malicious domain name servers, the method being implemented in a trusted domain name server configured in a device and associated with at least one network interface, the device being capable of communicating via the at least one network interface, the method implementing: - Receiving (121) at least one request to activate the domain name resolution verification service from the device, - Sending (122) at least one response, the at least one response including at least one domain name generated by the trusted server for the at least one interface, - If the trusted server does not receive a request to resolve the at least one domain name, or if the trusted server receives at least one request to resolve the at least one domain name but includes an anomaly, send (124) at least one notification to the device requesting the device to perform an action.

10. The method according to claim 9, wherein An anomaly is detected if the at least one request to resolve the at least one domain name and the at least one activation request are not from the same device.

11. The method according to any one of claims 9 and 10, characterized in that The at least one response further includes verification data generated by the trusted server for the at least one activation request, characterized in that the at least one request to resolve the at least one domain name includes a proof of integrity obtained from the verification data, and an anomaly is detected if the proof of integrity carried by the at least one request to resolve the at least one domain name is inconsistent with the proof of integrity locally obtained from the verification data known to the trusted server.

12. The method according to any one of claims 9 to 11, characterized in that, The at least one response further includes duplicate information of the at least one request to resolve the at least one domain name, and an anomaly is detected if the trusted server does not receive a request to resolve the at least one domain name, or if the at least one request to resolve the at least one domain name is inconsistent with the duplicate information.

13. The method according to any one of claims 9 to 12, characterized in that The at least one action notification is sent to at least one contact address of the device carried by the activation request, or the address used by the device to send the activation request.

14. The method according to any one of claims 1 to 13, characterized in that, The activation and / or resolution request uses options according to the EDNS mechanism ("Extended Mechanism for DNS") to exchange information between the device and the trusted server.

15. An apparatus configured with at least one trusted domain name server associated with at least one network interface, the apparatus being capable of communicating via the at least one network interface, characterized in that, The device is configured to: - Send at least one request to activate the domain name resolution verification service to at least one of the trusted servers, - Receive at least one response, the at least one response including at least one domain name generated by the trusted server for the at least one interface, - Send at least one request to resolve the at least one domain name, - Receive at least one notification requesting the device to take an action if the trusted server does not receive a request to resolve the at least one domain name, or if the trusted server receives at least one request to resolve the at least one domain name but includes an anomaly.

16. A trusted domain name server, configured in a device and associated with at least one network interface, the device being capable of communicating via the at least one network interface, characterized in that, The trusted domain name server is configured to: - Receive at least one request to activate the domain name resolution verification service from the device, - Send at least one response, the at least one response including at least one domain name generated by the trusted server for the at least one interface, - Send at least one notification to the device requesting the device to perform an action if the trusted server does not receive a request to resolve the at least one domain name, or if the trusted server receives at least one request to resolve the at least one domain name but includes an anomaly.

Images