Methods for detecting a malicious domain name server, corresponding equipment, trusted server and computer program

Abstract

The invention relates to a method for detecting a malicious DNS server, which method is implemented in equipment configured with at least one trusted DNS server, implementing: − transmission (111), to at least one of said trusted servers, of at least one request to activate a DNS verification service, − reception (112) of at least one response containing at least one domain name generated by said trusted server, − transmission (113) of at least one request to resolve said at least one domain name, − if no request to resolve said at least one domain name is received by said trusted server, or if at least one request is received but contains an anomaly, reception (114) of at least one notification inviting said equipment to take an action.

Description

[0001] DESCRIPTION

[0002] TITLE: Methods for detecting a malicious domain name resolution server, corresponding equipment, trusted server and computer program.

[0003] 1. Field of the invention

[0004] The field of the invention is that of communications within a communications network, for example a computer network implementing the IP protocol.

[0005] More specifically, the invention relates to name resolution services, for example DNS (Domain Name System), and proposes a solution helping to detect the presence of a malicious server involved in name resolution.

[0006] 2. Prior art

[0007] The development of the Internet is based on a set of service offerings for the consumer and business markets. Among these, so-called multi-service offers, including "Triple Play" offers (because they simultaneously offer access to the Internet, video content (including the broadcasting of television programs) and conversational services (IP telephony)), have captured a significant share of the market.

[0008] One of the common factors in operators' offers is the systematic presence of a home or business gateway, often called CPE ("Customer Premises Equipment"), HG ("Home Gateway") or "box". Such a CPE typically serves as an interface between a user's local network ("Local Area Network" (LAN)) and the network of an operator with which the user has subscribed to a service offer ("Internet Service Provider" (ISP). It is therefore an access device to an operator's network through which the traffic characteristic of the various services subscribed to by the user passes.

[0009] Since the CPE is a gateway for traffic to or from a user via an operator network, attacks can be carried out on this equipment, for example to intercept sensitive user data, such as banking data.

[0010] For example, an attack consists of modifying the configuration of DNS information stored in a CPE, descriptive of at least one trusted server associated with at least one network interface through which the CPE is able to communicate.

[0011] As a reminder, a DNS service allows you to associate a resource (for example, a domain name, URI (Uniform Resource Identifier), etc.) with one or more IP addresses to access this resource. For example, the DNS service allows a terminal connected to the CPE to obtain the IPv4 and / or IPv6 addresses associated with a domain name. Thus, when a terminal connected to the CPE wants to reach an application server identified by a domain name, a DNS resolution request is relayed by the CPE to at least one of the trusted DNS servers configured in the CPE. A connection is then established between the terminal and the application server using the IP address(es) returned by the DNS server to the CPE.

[0012] If an attacker wants to capture a user's traffic and intercept some of their data, they can, as a first example, provide the user with an IP address of a malicious application server used by the attacker, instead of an 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 queries issued by the terminal to a malicious DNS server managed by the attacker, instead of the initially configured trusted DNS server. All communications that require DNS exchanges can thus be intercepted by the malicious DNS server. The attacker can then redirect the traffic of the user who is the victim of the attack to fraudulent servers that will emulate certain sites (for example, servers used to carry out a financial transaction).

[0013] In a second example, the attacker may also decide to redirect 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 directs the user's requests to a "fraudulent" application server by manipulating the DNS requests, and then to the "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, instead of the initially configured trusted DNS server.However, in the second example, the fraudulent application server does not "emulate" the requested service but behaves as a relay ("proxy") that terminates the security association with the user's terminal and relays messages between this terminal and the legitimate application server. In doing so, the fraudulent application server accesses the content of the encrypted messages.

[0014] Password protection of access to the CPE administration interface (which allows, among other things, the configuration of DNS information in the CPE) is not sufficient to protect the CPE from the attacks described above. Indeed, since most users do not use (or even suspect the existence of) a CPE administration interface, protection of access to this administration interface is often weak. Similarly, protection of access to the CPE administration interface by MAC address ("Medium Access Control") can be ineffective because an attacker can change the MAC address of their terminal to be identical to the one(s) authorized by the CPE. These MAC addresses can indeed be acquired maliciously by eavesdropping on Wi-Fi exchanges, for example.

[0015] There is therefore a need for a new solution to detect fraudulent modification of DNS configuration information, and which can in particular preserve the security of users' personal data.

[0016] 3. Statement of the invention

[0017] The invention proposes a solution for detecting a malicious domain name resolution server, implemented in equipment configured with at least one trusted domain name resolution server associated with at least one network interface via which said equipment is capable of communicating.

[0018] Such equipment implements: the transmission, to at least one of said trusted servers, of at least one request for activation of a domain name resolution verification service, the reception of at least one response comprising at least one domain name generated by said trusted server for said at least one interface, the transmission of at least one request for resolution of said at least one domain name, if no request for resolution of said at least one domain name is received by said trusted server, or if at least one request for resolution of said at least one domain name is received by said trusted server but includes an anomaly, the reception of at least one notification inviting said equipment to take action.

[0019] The proposed solution thus allows a device (e.g. a terminal, a CPE, etc.) to take action if a trusted domain name resolution server, configured for at least one network interface (e.g. Ethernet, Wireless LAN, etc.) of the device, detects an anomaly in a specific domain resolution request sent via an interface of the device.

[0020] 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 equipment. For example, such a domain name, noted for example “TARGET_HB_FQDN”, can be generated randomly by the trusted server. It is therefore considered that such a domain name is unique and that the trusted server is identified as an authoritative server for the domain name thus generated. The trusted server can transmit to the equipment the domain name(s) generated for at least one of its interfaces. Such domain names are therefore known only to the trusted server and the equipment.The trusted server can then detect the presence of a malicious server if no resolution request for this or these domain names is received by it, or if one or more resolution requests for this or these domain names (called for example in the following “HB”) are received but contain an anomaly (for example, the source address of the domain name resolution request is not an address of the equipment).

[0021] In this case, a notification is sent by the trusted server to the device, so that the device can initiate at least one action, for example to correct the active domain name resolution configuration. Such an action can thus be executed automatically by the device, without user intervention. As a result, even if the user has no technical knowledge of computer systems, the device's DNS configuration information can be reset, or traffic to or from a malicious application server can be stopped.

[0022] The proposed solution thus contributes to improving the robustness of value-added IP services (including DNS services) and to protecting the user from attacks that would rely on a name resolution service such as the DNS service.

[0023] Furthermore, the proposed solution does not require traffic inspection in the network (e.g. in the access network) or communications profiling for anomaly detection. The solution can therefore be implemented independently of the underlying connectivity offering.

[0024] It is noted that a device according to the invention can embed one or more “DNS clients”. In other words, a DNS client can be supported by the operating system (or OS) of a device, or be specific to an application. In the latter case, several DNS clients can be activated on the same device, each of these clients being uniquely identified. The method according to the invention can be implemented by one of these DNS clients or be supported by a dedicated application. In particular, each DNS client of a device can implement the steps described above. The invention makes no assumptions as to the internal interface used between an application and a name resolution function (a DNS client, typically).

[0025] According to a particular embodiment, said at least one response also includes verification data (denoted for example “CHALLENGE”) generated by said trusted server for said at least one activation request. Said at least one resolution request for said at least one domain name generated by the equipment then includes proof of integrity obtained from said verification data.

[0026] Upon receipt of a resolution request by the trusted server, the latter can thus verify the integrity of the resolution request using the integrity proof, which contributes to improving the security of the proposed solution. For example, the integrity proof is a digest (also called a "hash") of said verification data.

[0027] In a particular embodiment, said at least one resolution request for said at least one domain name comprises an indicator requesting the generation, by said trusted server, of new verification data.

[0028] Such a change in verification data helps to strengthen the security of the proposed solution.

[0029] The equipment can then initiate a change in the verification data. As described below with the description of a particular embodiment, the equipment sends, for example, a resolution request noted “HB (C, NONCE1)”.

[0030] Alternatively, it is the server that may initiate a change to the verification data.

[0031] Such a change of verification data may notably be implemented on a regular basis or according to other policies local to the name resolution server.

[0032] In particular, said at least one response and / or said resolution request may be encrypted. Such encryption makes it possible to preserve the verification data transmitted in the response to the activation request (i.e. response from the trusted server to the equipment) or the proof of integrity transmitted in the “HB” resolution request.

[0033] In a particular embodiment, said at least one response also includes recurrence information (denoted for example “EPOCH”). Said at least one request for resolution of said at least one domain name is transmitted taking into account said recurrence information.

[0034] For example, the recurrence information provides the periodicity of sending resolution requests ("HB") by the equipment, sending a resolution request when the equipment restarts, when connecting to a new network, etc.

[0035] In a particular embodiment, said at least one activation request comprises at least one contact address of said equipment (noted for example “CONTACT_URI”).

[0036] In this way, the trusted server can send the equipment a notification to this contact address to inform the equipment of anomaly(ies) observed in the resolution of domain names. It is assumed that the equipment implements the appropriate procedures to be able to receive these messages (for example configuration of a firewall, NAT). These procedures are known per se and are therefore not repeated here. An example is notably described in the document RFC6887 "Port Control Protocol (PCP)" of April 2013. According to a particular embodiment, the descriptive information of said at least one trusted server is stored in a register maintained by said equipment and access to which is protected. It is recalled that it is conventional to configure at least one list of at least one trusted server associated with at least one interface of a piece of equipment. According to the invention, such configuration information (i.e.descriptive information of said at least one trusted server) are stored in a specific registry, access to which is protected, for example by a password or verification keys. In this way, an attacker does not have direct access to this configuration information, which contributes to strengthening the security of the proposed solution.

[0037] In particular, the registry to which access is protected is separate from any other registry used for the storage of other information relating to domain name resolution.

[0038] In particular, the location of this protected registry is not predefined and may be different for different devices. In particular, the registry location may be randomly chosen when activating the domain name resolution verification service.

[0039] According to a particular embodiment, the equipment being configured to execute at least one action, said equipment executes at least one given action (for example, preconfigured) upon receipt of a notification inviting it to execute said at least one action. For example, said at least one action belongs to the group comprising: replacing the active domain name resolution configuration with the configuration of one of said trusted servers, disabling outgoing communications except for communications to one of said trusted servers, generating a local notification to inform a user of a modification of the domain name resolution configuration, requesting the sending of the active domain name resolution configuration.

[0040] In particular, such actions may have been previously configured for the equipment. Thus, upon receipt of a notification, the equipment knows the action it must perform. The proposed solution therefore does not require the user to intervene in resolving anomalies. The user is therefore not expected to have any particular technical knowledge for implementing the invention.

[0041] The invention also relates to such a method for detecting a malicious domain name resolution server, implemented in the trusted server.

[0042] Such a trusted server implements the following steps: receiving at least one request for activation of a domain name resolution verification service, from said equipment, transmitting at least one response comprising at least one domain name generated by said trusted server for said at least one interface, if no request for resolution of said at least one domain name is received by said trusted server, or if at least one request for resolution of said at least one domain name is received by said trusted server but includes an anomaly, transmitting to said equipment at least one notification inviting it to perform an action.

[0043] As already indicated, the trusted server can generate one or more specific domain names for at least one interface of the equipment and detect a problem in the domain name resolution verification service if no request for resolution of the specific domain name is received, or if a request for resolution of the 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 said equipment carried by said activation request or to the address used by said equipment to transmit said activation request. These checks are made possible by the fact that the trusted server is authoritative for the domain names generated for at least one interface of a piece of equipment.

[0044] According to a particular embodiment, an anomaly is detected if said at least one resolution request for said at least one domain name and if said at least one activation request do not come from the same equipment.

[0045] For example, the trusted server compares the addresses used to send the activation request and to send the resolution request for said at least one domain name. If they differ or are not associated with the same device, the trusted server detects an anomaly.

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

[0047] For example, the trusted server randomly generates verification data and transmits it in its response. The device calculates a digest of this verification data and transmits it in the resolution request for the specific domain name. Upon receipt, the trusted server can locally calculate a digest of the verification data it knows and compare it with the digest received in the resolution request.

[0048] According to a particular embodiment, said at least one response comprises new verification data generated by said trusted server for said equipment, at the initiative of said trusted server or upon receipt of a request from said equipment.

[0049] As previously stated, the verification data can actually be renewed at the initiative of the equipment or the trusted server, for example regularly, in order to improve the security of the proposed solution.

[0050] According to a particular embodiment, said at least one response also comprises recurrence information (noted for example “EPOCH”) of said at least one request for resolution of said at least one domain name, and an anomaly is detected if no request for resolution of said at least one domain name is received by said trusted server or if said at least one request for resolution of said at least one domain name is not consistent with said recurrence information.

[0051] Again, the use of such recurrence information helps to strengthen the security of the proposed solution.

[0052] According to a particular embodiment, said activation and / or resolution requests for said at least one domain name use an option according to the DNS mechanism as described in the document RFC 6891 (“Extension Mechanisms for DNS” (EDNS) of April 2013) to transmit different information between the equipment and the trusted server (for example a domain name (“TARGET_HB_FQDN”), verification data (“CHALLENGE”), recurrence information (“EPOCH”), a contact address (“CONTACT_URI”), etc.).

[0053] In another embodiment, the invention relates to corresponding equipment. Such equipment is particularly suitable for implementing a method for detecting a malicious domain name resolution server according to at least one embodiment of the invention. Thus, such equipment may include the various characteristics relating to the method according to the invention, which may be combined or taken in isolation. For example, the equipment is of the CPE, terminal, etc. type. The equipment may be connected to a fixed network, a mobile network, a network of connected objects (for example a mesh network according to the “Thread” protocol), etc.

[0054] In another embodiment, the invention relates to a corresponding trusted server. Such a trusted server is in particular suitable for implementing a method for detecting a malicious domain name resolution server according to at least one embodiment of the invention. Thus, such a server may comprise the various characteristics relating to the method according to the invention, which may be combined or taken in isolation.

[0055] In yet another embodiment, the invention relates to one or more computer programs comprising instructions for implementing a method for detecting a malicious domain name resolution server according to at least one embodiment of the invention, when this or these programs is / are executed by a processor.

[0056] The methods according to the invention can therefore be implemented in various ways, in particular in wired form and / or in software form.

[0057] In particular, the method according to the invention can be implemented by a generic module, an application, etc.

[0058] 4. List of figures

[0059] Other characteristics and advantages of the invention will appear more clearly on reading the following description of a particular embodiment, given as a simple illustrative and non-limiting example, and the appended drawings, among which: Figure 1 illustrates the main steps of a method for detecting a malicious domain name resolution server according to one embodiment, Figure 2 presents the generic format of a WADE option according to one embodiment, Figure 3 presents an example of a WADE option according to one embodiment, Figure 4 illustrates an example of messages exchanged between a DNS client and a trusted server without anomaly detection, Figure 5 illustrates an example of messages exchanged between a DNS client and a trusted server with modification of the verification data at the initiative of the DNS client,Figure 6 illustrates an example of messages exchanged between a DNS client and a trusted server with modification of the verification data at the initiative of the trusted server, Figure 7 illustrates an example of messages exchanged between a DNS client and a trusted server with detection of an anomaly of the type non-compliance with the recurrence information, Figure 8 illustrates an example of messages exchanged between a DNS client and a trusted server with detection of an anomaly linked to the source address, Figure 9 illustrates an example of messages exchanged between a DNS client and a trusted server for the deactivation of a domain name resolution verification service, and Figure 10 presents the simplified structure of a device, respectively of a trusted server, according to one embodiment.,

[0060] 5. Description of an embodiment of the invention 5.1 General principle

[0061] We place ourselves in the context of a device (for example a terminal, a CPE) configured with descriptive information of at least one trusted domain name resolution server associated with a network interface via which the device is able to communicate.

[0062] The general principle of the invention is based on the generation, by the trusted server, of at least one specific domain name for at least one interface of the equipment and the implementation of a procedure for issuing resolution requests linked to this specific domain name. The trusted server can thus detect a problem in a domain name resolution service if it does not receive any resolution request for the specific domain name, or if a resolution request for the specific domain name that it receives contains an anomaly. The trusted server can then inform the equipment, which can then take appropriate action.

[0063] We present, in relation to figure 1, the main steps implemented for the detection of a malicious domain name resolution server according to the invention.

[0064] We consider an H 11 device configured with at least one trusted DNS domain name resolution server 12 associated with at least one network interface via which the device is able to communicate.

[0065] During a first step 111, the equipment 11 transmits to the trusted server 12, via at least one network interface, at least one activation request ACTIV of a domain name resolution verification service. The trusted server 12 receives said at least one activation request ACTIV during a step 121.

[0066] The activation request may in particular be a dedicated request, such as a DNS query reserved for activating the domain name resolution verification service. An example of such a dedicated query is a query to resolve a dedicated domain name, capable of triggering activation of the verification service. This dedicated domain name may be a name configured when subscribing to the service (for example “peraspera. example”) or a domain name reserved for this purpose and which may be used by all operators (for example “peraspera. arpa”).

[0067] Alternatively, the activation request may be a “non-dedicated” request. In this case, the equipment does not generate a DNS query relating to a domain name dedicated to the activation of the domain name resolution verification service, but uses a conventional DNS query, for example a DNS query issued for the needs of an application embedded in the equipment, and inserts information therein for the activation of the domain name resolution service. A conventional DNS query is thus diverted by inserting particular information therein, for example in the form of a new option according to a DNS extension mechanism as described below. The trusted server 12 can generate at least one specific domain name for the network interface used, and transmit to the equipment 11 at least one response comprising the specific domain name(s), during a step 122.Such a domain name is considered to be unique and the trusted server is authoritative for the domain name thus generated. According to the example illustrated in Figure 1, the trusted server transmits a single REP response bearing a unique domain name. The equipment 11 receives the REP response during a step 112.

[0068] The equipment 11 can then transmit to the trusted server 12 at least one resolution request for the unique domain name REQ DNS during a step 113. Such a resolution request relating to the unique domain name is subsequently also called HB (“Heartbeat” in English).

[0069] If the trusted server 12 receives a DNS REQ request during a step 123, but this DNS REQ request contains an anomaly, the trusted server 12 sends a NOTIF notification to the equipment 11 during a step 124, inviting it to execute an action.

[0070] If the trusted server 12 does not receive any DNS REQ request relating to the unique domain name communicated to the equipment 11 during the activation of the procedure (steps 122 / 112), the trusted server 12 sends a NOTIF notification to the equipment 11 inviting it to perform an action, for example after a waiting period. The waiting period may in particular be predefined, configured in the trusted server, known to the equipment or transmitted to the equipment, etc.

[0071] The equipment 11 can thus receive, during a step 114, a NOTIF notification inviting it to execute an action, for example a predefined action. The equipment can then execute such an action, without requiring interaction with a user of the equipment or an administrator of a local network (for example administrator of a home network, administrator of a CPE).

[0072] As described below, various information may be used by the trusted server to detect an anomaly when processing a domain name resolution request. In particular, verification data and / or recurrence information may be transmitted in the REP response from the trusted server to the equipment, and used by the equipment to manage the transmission of the unique domain name resolution request REQ DNS to the trusted server.An anomaly may in particular be detected if the activation request ACTIV and the unique domain name resolution request REQ DNS do not come from the same equipment, or if a proof of integrity, obtained from the verification data and conveyed by the REQ DNS request, is not consistent with a proof of integrity obtained from the verification data known to and maintained locally by the trusted server, or if the transmission of the REQ DNS request(s) does not comply with the recurrence information, or if the REQ DNS request includes information from a DNS relay, for example.

[0073] 5.2 Detailed description of a particular embodiment

[0074] 5.2.1 Initial Configuration

[0075] A detailed example of implementation of the invention is described below. It is considered that a user of the equipment (for example a terminal) wishes to activate a domain name resolution verification service. Subsequently, such a service is called “PER ASPERA” (“PER-DNS client guards Against malicious DNS Server swapping, traffic intERception, and datA theft”, or “DNS configuration change detection and mitigation procedure”).

[0076] For example, the user can subscribe to the PER ASPERA service using a dedicated interface. The PER ASPERA service can in particular be provided to terminals directly connected to a service provider's network or reserved for offers based on the provision of a CPE. As already indicated, "equipment" denotes a terminal or a CPE used by a user wishing to benefit from the PER ASPERA service. It should be noted that the PER ASPERA service can be offered by a connectivity service provider, a DNS service provider, etc. In particular, a user can request a DNS service provider separate from the provider that provides connectivity. The user's equipment can connect to several networks using the same access equipment or different equipment. The user's equipment can use the same DNS service for all the access networks (fixed and mobile) to which it can connect.The PER ASPERA service may be offered independently of the nature of the access network(s) used by the user's equipment. In addition, the PER ASPERA server may only be used for some of the interfaces.

[0077] Typically, the equipment, or at least one network interface of the equipment, is configured with at least one list of at least one trusted DNS server. In order to improve the security of the proposed solution, the connections between the equipment and the trusted server(s) are, in the embodiment described here, secured. Thus, the trusted server(s) can support at least one encryption scheme based for example on the use of one or other of the following protocols: DNS over TLS (DoT), DNS over DTLS (DoD), DNS over HTTPS (DoH), DNS over QUIC (DoQ), DNS over CoAP (DoC), etc.

[0078] The configuration of the list(s) of at least one trusted server may be carried out using a mechanism based on a discovery of resolvers designated by their neighbors (DNR, “Discovery of Neighbor-designated Resolvers”, as described in the document “DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)” of August 2022, a mechanism based on a key exchange (IKE, “Internet Key Exchange”, as described in the document “Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS” of September 2022), etc. If the equipment has several network interfaces, at least one list of at least one trusted server may be configured per network interface (wired, wireless, 5G, etc.). In this case, a list of at least one trusted server may be associated with an identifier of the network interface concerned.

[0079] According to a particular embodiment, the equipment may also be configured with at least one action. For example, the equipment is configured with an indexed list of predefined actions. Such a list may contain the following actions (non-exhaustive): policy / action index “0”: replace the active domain name resolution configuration with the configuration of one of the trusted servers, policy / action index “1”: disable outgoing communications except for communications to one of the trusted servers for a given interface, policy / action index “2”: generate a local notification to inform the user of a change in the domain name resolution configuration, policy / action index “3”: request sending of the active domain name resolution configuration, etc.

[0080] According to a particular embodiment, the descriptive information of the trusted server(s) (i.e. the configuration of the list(s) of at least one trusted server) is stored in a register maintained by the equipment and access to which is protected. Access to this register may in particular implement strong authentication mechanisms (for example, by the use of a dedicated password or multi-level verification keys). The location of such a register may in particular be decided upon activation of the PER ASPERA service. The register may correspond to dedicated entries in a Windows© registry, a file, a database, etc.

[0081] In particular, such a registry is separate from any other registry used for storing other information relating to domain name resolution. The registry where the list(s) of at least one trusted server are stored is therefore isolated from other registries used for storing information used for DNS management.

[0082] Optionally, the descriptive information of the trusted server(s) may be duplicated to be stored on the one hand in the registry whose access is protected, and on the other hand in a registry conventionally used for storing information relating to the resolution of domain names. This isolation aims to prevent the list of trusted DNS servers from being modified by a malicious application or following fraudulent access to the equipment.

[0083] Concretely, an application that accesses the local DNS configuration without user consent can potentially modify the active DNS configuration, but cannot modify the configuration of trusted servers stored in the registry whose access is protected.

[0084] 5.2.2 Activation of the PER ASPERA service

[0085] Subsequently, the term "DNS client" is used to designate the equipment or at least one network interface of the equipment implementing the proposed solution.

[0086] As described in Figure 1, during a first step 111, a DNS client transmits to at least one of its trusted servers at least one DNS request for activation of the PER ASPERA service.

[0087] As already indicated, this activation request may be dedicated to activating the domain name resolution verification service. In this case, the activation request is a DNS query reserved for the PER ASPERA service. Alternatively, the activation request may be non-dedicated, in particular when conventional queries are used for the needs of usage applications. In this case, the DNS client uses a query issued for example by an application embedded in the equipment by inserting the information required for activating the PER ASPERA service.

[0088] Note that if the same trusted server is associated with several interfaces of the equipment, an activation request per interface can be sent; each of these requests is routed to the trusted server via the interface concerned. Indeed, sending these different requests per interface makes it possible to communicate to a trusted server the external address of the equipment (DNS client) which makes it reachable via this interface.

[0089] If multiple trusted server lists are configured, then an activation request is sent to each of these lists, i.e. to at least one trusted server from each of the lists. This makes it possible in particular to control DNS activity for all the interfaces of a device when they are associated with different trusted servers.

[0090] According to one embodiment of the invention, the activation request(s) use a new option according to the EDNS mechanism. Such an option is hereinafter called WADE (“An EDNS Option for WAtching DNS associations to prevent swapping, interception, and theft”). The identification of an extended request according to the EDNS mechanism is carried out using a pseudo “resource-record” (RR) OPT.

[0091] The generic format of the WADE option is illustrated in Figure 2. As illustrated in Figure 2, the “OPTION-DATA” data field of the OPT RR provides six control indicators, for example in the form of 6 bits H, N, C, T, E, U: the H bit, also called “HB_ENABLE” (for “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, the N bit set to the value “1” indicates the presence of the “NONCE” field, the C bit set to the value “1” indicates the presence of the “CHALLENGE” field, the T bit set to the value “1” indicates the presence of the “TARGET_HB_FQDN” field, the E bit set to the value “1” indicates the presence of the “EPOCH” field, the U bit set to the value “1” indicates the presence of the “ CONTACT_URI ».

[0092] These different fields ("NONCE", "CHALLENGE", "TARGET_HB_FQDN", "EPOCH", "CONTACTJJRI") are presented below. In particular, the fields "CHALLENGE", "TARGET_HB_FQDN", and "EPOCH" are filled in by a trusted server.

[0093] When multiple such fields are carried in a single WADE option, then these different fields are inserted according to the order of the control bits. Variable parameters are preceded by a field that provides the parameter size.

[0094] An activation request including the WADE option, as illustrated in Figure 3, uses the H bit and possibly the U bit, set to the value "1". The other bits (N, C, T, and E) can be set to the value "0".

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

[0096] Such a "CONTACTJJRI" field may be present in a PER ASPERA service activation request. This field lists the contact identifier(s) that the trusted server (which receives the activation request) can use to report anomalies found in the DNS configuration information (for example by sending the DNS client a notification inviting it to take action).

[0097] If the U bit is set to "1", i.e. if the "CONTACT_URI" field is present, this means that the contact address(es) for sending notifications are those entered in the "CONTACTJJRI" field. If the U bit is set to "0", i.e. if the "CONTACT_URI" field is not present, this means that the contact address for sending notifications is the address (and port number) used by the DNS client to send this activation request.

[0098] Note that the PER ASPERA service can be disabled at any time by a device. To do this, a query containing the WADE option can be sent from the DNS client to a trusted server, using the H bit set to "0". In the following, it is assumed that the service is enabled.

[0099] Note that such a WADE option is only inserted in a DNS query intended for a trusted server. This verification is based, for example, on the destination IP address of the DNS query or the ADN ("Authentication Domain Name") of the target DNS server.

[0100] 5.2.3 Trusted Server Response

[0101] As indicated in relation to Figure 1, at least one trusted server receives at least one request for activation of the PER ASPERA service during a step 121.

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

[0103] If a trusted server supports the WADE option, then it can process the received activation request. In particular, the trusted server can extract the information communicated in the WADE option, especially in the "CONTACT_URI" field if applicable. For example, the trusted server can extract a source IP address and port number from the activation request. This information can be stored for later reuse. A trusted server can thus maintain one or more source addresses per DNS client.

[0104] The trusted server may in particular prepare at least one response and transmit it to the DNS client during step 122 of Figure 1. Such a response may in particular take the form of a DNS query which includes the WADE option as illustrated in Figure 2.

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

[0106] The T bit can also be set to "1" to indicate the presence of the "TARGET_HB_FQDN" field. A "TARGET_HB_FQDN_Length" field can be provided to indicate the size of the parameter present in the "TARGET_HB_FQDN" field. Such a "TARGET_HB_FQDN" field contains one or more specific domain names generated by the trusted server for the DNS client in question. The trusted server is authoritative for these domain names. They are therefore considered unique, and known only to the DNS client and the trusted server. To do this, they are generated randomly, for example.

[0107] Optionally, bit C can take a value of "1" to indicate the presence of a "CHALLENGE" field. A "CHALLENGE_Length" field can be provided to indicate the size of the parameter present in the "CHALLENGE" field.

[0108] Such a "CHALLENGE" field includes challenge data that can be used by the DNS client to determine a proof of integrity. For example, such challenge data can be randomly generated and used by the DNS client to calculate a proof of integrity, such as a hash. Such a proof of integrity can then be inserted by the DNS client into subsequent DNS queries to the trusted server.

[0109] Optionally, bit E can take a value of "1" to indicate the presence of an "EPOCH" field. An "EPOCHJength" field can be provided to provide the size of the parameter present in the "EPOCH" field.

[0110] Such an "EPOCH" field contains recurrence information, used by the DNS client to transmit "HB" domain name resolution queries. For example, such a field indicates the periodicity of HB queries by the DNS client.

[0111] If the “EPOCH” and “CHALLENGE” fields are enabled, bits C, T, E are set to “1” and bits U and N are set to “0”.

[0112] In particular, the trusted server can store the information communicated to each DNS client.

[0113] In a particular embodiment, the trusted server can control the TTL (“Time To Live”) field of the responses to force the DNS client to renew the activation of the PER ASPERA service by returning an activation request.

[0114] 5.2.4 TARGET_HB_FQDN field domain name resolution query

[0115] As shown in connection with Figure 1, the DNS client receives a response from the trusted server during a step 112.

[0116] The DNS client can extract the information contained in the WADE option, particularly in the "TARGET_HB_FQDN" field. If information is present in the "EPOCH" and / or "CHALLENGE" fields, this 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. Multiple responses that contain the WADE option can be sent to the DNS client by a trusted server. All this information can be stored by the DNS client in an appropriate registry, to which access can be protected.

[0117] As illustrated in Figure 1, the DNS client can then issue a request to resolve the domain name present in the “TARGET_HB_FQDN” field during a step 113. Such a request can in particular take the form of a DNS request with WADE option as illustrated in Figure 2. In particular, such a request which contains 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”.

[0118] Bit N can be set to “1” to indicate the presence of the “NONCE” field. A “NONCE_Length” field can be provided to indicate the size of the parameter present in the “NONCE” field.

[0119] Such a “NONCE” field includes, for example, a proof of integrity generated from the verification data transmitted in the “CHALLENGE” field.

[0120] Figure 4 illustrates an example of messages exchanged between a DNS client 41 and a trusted DNS server 42.

[0121] For example, it is considered that the DNS client 41 issues an activation request using its address @1 as the source address, and that the trusted server 42 constructs a response comprising the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGE”. At the end of these steps of receiving at least one activation request and constructing at least one response (denoted Activ. PER APSERA 411), the trusted server 42 has the information contained in the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGE”, and the source address of the activation request (@1).

[0122] According to the example considered, the DNS client 41 can in particular send one or more DNS requests for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, noted HB, taking into account the value indicated in the “EPOCH” field of the response received. For example, the “EPOCH” field includes recurrence information indicating a periodicity T1 for sending the HB requests. Thus, a first HB request for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field can be sent at time T0+T1, a second HB request for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field can be sent at time TO+2*T1, a third HB request for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field can be sent at time TO+3*T1, etc.

[0123] Such HB (“HeartBeat”) requests make it possible to signal to the trusted server 42 the presence of an active association with a DNS client 41. According to the example considered, the DNS client 41 can in particular calculate a digest of the verification data conveyed in the “CHALLENGE” field of the response received during the PER ASPERA activation phase. Such a digest can in particular be inserted in the “NONCE” field of the HB request which contains the WADE option.

[0124] According to the example illustrated by Figure 4, the DNS client 41 issues a first HB request (412) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity in the “NONCE” field, at time T0+T1. Upon receipt of the first HB request (412), the trusted server 42 can in particular verify that the source address of the activation request (@1) and the source address of the first HB request (src@) are consistent, i.e. make it possible to identify the same equipment (src@=@1). If this is not the case, an anomaly is detected. The trusted server 42 can also verify that the integrity proof contained in the “NONCE” field of the HB request is consistent with a locally determined integrity proof from the verification data stored by the trusted server 42 (as recorded in the “CHALLENGE” field in the response issued by the trusted server).In particular, the trusted server 42 can calculate a digest of the verification data (for example, perform the “Hash (CHALLENGE)” calculation where Hash designates a hash function corresponding to that applied by the DNS client 41 to generate the digest of the verification data (for example, “Secure Hash Algorithms (SHAs)” described in the document RFC 6234 “US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)” of May 2011) and verify that it is equal to the digest transmitted 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 verify whether the recurrence information specified in the “EPOCH” field is respected. If this is not the case, an anomaly is detected. Alternatively, the indication of the “hash” function to be used by a DNS client can be communicated using the WADE option.To do this, an "I" bit is defined for this purpose among the "unassigned" bits described in figure 2. When the "I" bit is set to "1", the identity of the "hash" function is entered in the body of the WADE option (for example SHA2-256).

[0125] The DNS client 41 can then issue a second HB request (413) for the resolution of the domain name indicated in the TARGET_HB_FQDN field, including a proof of integrity in the NONCE field, at time T0+2T1. The trusted server 42 can in particular verify that the source address of the activation request (@1) and the source address of the second HB request (src@) are consistent (src@=@1), that the digest of the verification data (Hash (CHALLENGE)) is equal to the digest transmitted in the NONCE field and that the recurrence information contained in the “EPOCH” field is respected. The DNS client 41 can issue a third HB request (414) and so on.

[0126] In the example illustrated in Figure 4, no anomaly is detected.

[0127] In a particular embodiment, the information communicated during activation of the PER ASPERA service can be modified at the initiative of the trusted server 42 or the DNS client 41.

[0128] Figure 5 illustrates an example of messages exchanged between the DNS client 41 and the trusted server 42, with a request to modify the verification data at the initiative of the DNS client 41.

[0129] For example, we consider that the DNS client 41 issues an activation request using its address @1, and that the trusted server 42 constructs a response comprising the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGEl” (Activ. PER APSERA 511).

[0130] According to the example illustrated by Figure 5, the DNS client 41 issues a first HB request (512) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, comprising a proof of integrity in the “NONCE1” field, at time T0+T1. Upon receipt of the first HB request (512), the trusted server 42 can in particular verify that the source address of the activation request (@1) and the source address of the first HB request (src@) are consistent. The trusted server 42 can also verify that the proof of integrity contained in the “NONCE1” field of the HB request is consistent with a proof of integrity determined locally from the verification data carried by the “CHALLENGEl” field. In particular, the trusted server 42 can calculate a digest of the verification data (Hash (CHALLENGEl)) and verify that it is equal to the digest transmitted in the “NONCE1” field.The trusted server 42 can also check whether the recurrence information specified in the “EPOCH” field is respected.

[0131] The DNS client 41 can request at any time to modify the verification data (“CHALLENGEl”). To do this, the DNS client can send a second HB request (513) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field including a proof of integrity in the “NONCE1” field, calculated on the basis of the verification data in the “CHALLENGEl” field. To inform the trusted server 42 that the DNS client 41 requests new verification data, the C and N bits are set to “1”.

[0132] Upon receipt of this message, the trusted server 42 can accept the request and generate new verification data, which is transmitted to the DNS client 41 in a response which contains the WADE option, in the “CHALLENGE2” field (514).

[0133] The DNS client 41 can issue a third HB request (515) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, comprising a proof of integrity in the “NONCE2” field, at time T0+2T1. Such a proof of integrity is obtained from the new “CHALLENGE2” verification data. Upon receipt of the third HB request (515), the trusted server 42 can in particular verify that the source address of the activation request (@1) and the source address of the third HB request (src@) are consistent, i.e. make it possible to identify the same equipment (src@=@1). The trusted server 42 can also verify that the integrity proof contained in the “NONCE2” field of the HB request is consistent with a locally determined integrity proof from the new verification data stored by the trusted server 42 (as contained in the “CHALLENGE2” field of the response issued by the trusted server).In particular, the trusted server 42 can calculate a digest of the verification data (Hash (CHALLENGE2)) and verify that it is equal to the digest contained in the “NONCE2” field. The trusted server 42 can also verify whether the recurrence information contained in the “EPOCH” field is respected.

[0134] The DNS client 41 can issue a fourth HB query (516) and so on.

[0135] Figure 6 illustrates an example of messages exchanged between the DNS client 41 and the trusted server 42, with a request to modify the verification data at the initiative of the trusted server 42.

[0136] For example, we consider that the DNS client 41 issues an activation request using its address @1, and that the trusted server 42 constructs a response comprising the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGEl” (Activ. PER APSERA 611).

[0137] According to the example illustrated by Figure 6, the DNS client 41 issues a first HB request (612) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, comprising a proof of integrity in the “NONCE1” field, at time T0+T1. Upon receipt of the first HB request (612), the trusted server 42 can in particular verify that the source address of the activation request (@1) and the source address of the first HB request (src@) are consistent. The trusted server 42 can also verify that the proof of integrity specified in the “NONCE1” field of the HB request is consistent with a proof of integrity determined from the verification data recorded in the “CHALLENGEl” field. In particular, the trusted server 42 can calculate a digest of the verification data (Hash (CHALLENGEl)) and verify that it is equal to the digest recorded in the “NONCE1” field.The trusted server 42 can also check whether the recurrence information contained in the “EPOCH” field is respected.

[0138] The trusted server 42 may decide at any time to modify the verification data (“CHALLENGEl”).

[0139] For example, upon receipt of a second HB request (613) for the resolution of the domain name indicated in the "TARGET_HB_FQDN" field comprising a proof of integrity recorded in the "NONCE1" field, calculated on the basis of the verification data of the "CHALLENGE1" field, the trusted server 42 can generate new verification data. The trusted server 42 can transmit the new verification data to the DNS client 41 in a response which contains the WADE option, recorded in the "CHALLENGE2" field (614). To inform the DNS client 41 that the trusted server 42 has generated new verification data which is transmitted in the "CHALLENGE2" field, the C bit is set to "1".

[0140] The DNS client 41 can issue a third HB request (615) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, comprising a proof of integrity contained in the “NONCE2” field, at time T0+2T1. Such a proof of integrity is obtained from the new “CHALLENGE2” verification data. Upon receipt of the third HB request (615), the trusted server 42 can in particular verify that the source address of the activation request (@1) and the source address of the third HB request (src@) are consistent, i.e. make it possible to identify the same equipment (src@=@1). The trusted server 42 can also verify that the integrity proof recorded in the “NONCE2” field of the HB request is consistent with a locally determined integrity proof from the new verification data stored by the trusted server 42 (as contained by the “CHALLENGE2” field in the response sent by the trusted server).In particular, the trusted server 42 can calculate a digest of the verification data (Hash (CHALLENGE2)) and verify that it is equal to the digest transmitted in the “NONCE2” field. The trusted server 42 can also verify whether the recurrence information contained in the “EPOCH” field is respected.

[0141] DNS client 41 can issue a fourth HB query (616) and so on.

[0142] For example, the trusted server 42 may modify the verification data at regular intervals for security purposes.

[0143] We now present, in relation to figure 7, the detection of an anomaly when the recurrence information contained in the “EPOCH” field is not respected.

[0144] Figure 7 illustrates an example of messages exchanged between the DNS client 41 and the trusted server 42. For example, we consider that the DNS client 41 sends an activation request using its address @1, and that the trusted server 42 constructs a response comprising the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGE” (Activ. PER APSERA 711).

[0145] According to the example illustrated by Figure 7, the DNS client 41 issues a first HB request (712) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, comprising a proof of integrity recorded in the “NONCE” field. Upon receipt of the first HB request (712), the trusted server 42 can in particular verify that the source address of the activation request (@1) and the source address of the first HB request (src@) are consistent. The trusted server 42 can also verify that the proof of integrity contained in the “NONCE” field of the HB request is consistent with a proof of integrity determined locally from the verification data contained in the “CHALLENGE” field. The trusted server 42 can also verify whether the recurrence information recorded in the “EPOCH” field is respected.

[0146] The trusted server 42 notes that it does not receive an HB request at times TO + T1, TO + 2T1 and TO + 3T1 for example. It therefore detects that the recurrence information contained in the “EPOCH” field (recurrence of requests with a periodicity T1) is not respected, and issues at least one notification inviting the DNS client 41 to take action.

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

[0148] For example, a notification message can be of the type Push HTTPS, Update DNS, etc. Such a message can notably include an index corresponding to a given action, for example preconfigured. For example, if a notification message has an index equal to 0 (Notif. (Action = 0)), the DNS client takes an action of the type replacing the active domain name resolution configuration with the configuration of one of the trusted servers. If a notification message has an index equal to 1 (Notif. (Action = 1)), the DNS client takes an action of the type "disable outgoing communications except for communications to one of the trusted servers for the interface in question", etc.

[0149] The exchange illustrated by Figure 7 can in particular be observed when a malicious DNS server 73 has been configured in the equipment embedding the DNS client 41, and this malicious server 73 blocks all or part of the DNS requests sent by the DNS client 41. The DNS client 41 can initiate one or more actions upon receipt of the notification message(s), such as reinstalling the trusted DNS configuration, blocking certain communications, etc.

[0150] Once the trusted DNS configuration is reinstalled for example (reinstalling the descriptive information of the trusted DNS servers), the trusted server 42 can again receive an HB request.

[0151] We now present, in relation to Figure 8, the detection of an anomaly when the source address of an HB query is not consistent with the source address of the activation query. Similar steps can be implemented when the integrity proof conveyed by an HB query is not consistent with the integrity proof determined locally by the trusted server from the verification data known to the trusted server. According to one and / or the other of these cases, this typically means that the HB query has been relayed by another potentially malicious DNS server. The trusted server can thus detect that the HB queries (or any other DNS queries) issued by the DNS client are intercepted by another DNS server before being routed to the trusted server.

[0152] Figure 8 illustrates an example of messages exchanged between the DNS client 41 and the trusted server 42. For example, we consider that the DNS client 41 sends an activation request using its address @1, and that the trusted server 42 constructs a response comprising the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGE” (Activ. PER APSERA 811).

[0153] According to the example illustrated by Figure 8, the DNS client 41 issues a first HB request (812) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, comprising a proof of integrity recorded in the “NONCE” field. Upon receipt of the first HB request (812), the trusted server 42 can in particular verify that the source address of the activation request (@1) and the source address of the first HB request (src@) are consistent. The trusted server 42 can also verify that the proof of integrity contained in the “NONCE” field of the HB request is consistent with a proof of integrity determined from the verification data recorded in the “CHALLENGE” field. The trusted server 42 can also verify whether the recurrence information specified in the “EPOCH” field is respected.

[0154] The DNS client 41 then issues a second HB request (813) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity in the “NONCE” field. However, as illustrated in FIG. 8, this second HB request (813) is intercepted by a server F 83 and relayed to the trusted server 42. Upon receipt of the second HB request (813), the trusted server 42 notes that the source address of the activation request (@1) and the source address of the second HB request (src@) are not consistent (src@ !=@1). It therefore detects an anomaly and that the second HB request has probably been relayed by another potentially malicious DNS server (F 83). The trusted server 42 issues at least one notification 814 inviting the DNS client 41 to take action.For example, one or more notification messages 814 are sent to the address entered in the CONTACT_URI field for the DNS client 41, or to the address used by the DNS client 41 to send the activation request. For example, such a message may be of the DNS response type, relayed by the malicious server 83, comprising an index corresponding to a given action, for example preconfigured, to be executed by the DNS client. For example, if a DNS response has an index equal to 3 (Rep. (Action = 3)), the DNS client initiates an action of the type “request sending the identity of the active DNS server”. If a DNS response has an index equal to 0 (Rep. (Action = 0)), the DNS client initiates an action of the type replacing the active domain name resolution configuration with the configuration of one of the trusted servers, etc.It should be noted that the trusted server 42 can trigger the execution of several actions under HB exchanges using an IP address distinct from that used when activating the PER ASPERA service.

[0155] The exchange illustrated by figure 8 can in particular be observed when a malicious DNS server 83 has been configured in the equipment embedding the DNS client 41, and this malicious server 83 behaves like an intermediate DNS relay (“proxy”) which relays the messages between the DNS client 41 and the trusted server 42.

[0156] Once the trusted DNS configuration is reinstalled for example (reinstalling the descriptive information of the trusted DNS servers), the trusted server 42 can again receive an HB request.

[0157] In a particular embodiment, the trusted server 42 may also include an EDE option, as described in RFC 8914 “Extended DNS Errors” of October 2020, to inform the DNS client that a DNS error has been detected by the trusted server. Upon receipt of this response, the DNS client may proceed to execute the action indicated in this response. Alternatively, the indication of the action to be executed by a DNS client may be provided using the WADE option. To do this, an “A” bit is defined for this purpose among the “unassigned” bits shown in Figure 2. When the “A” bit is set to “1”, the index of the action is provided in the body of the WADE option.

[0158] Finally, in relation to Figure 9, we present an example of deactivation of the PER ASPERA service, for at least one interface of the equipment. We consider for example that the DNS client 41 sends an activation request using its address @1, and that the trusted server 42 constructs a response comprising the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGE” (Activ. PER APSERA 911).

[0159] According to the example illustrated by Figure 9, when the DNS client 41 wishes to deactivate the PER ASPERA service, it issues an HB request (912) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field comprising a proof of integrity in the “NONCE” field, calculated on the basis of the verification data recorded in the “CHALLENGE” field. To inform the trusted server 42 that the DNS client 41 wishes to deactivate the PER ASPERA service, the “HB_ENABLE” H bit is set to “0”.

[0160] Upon receipt of such a request, the trusted server 42 verifies that there is no anomaly. For example, the trusted server 42 may reject the HB 912 request and return an error message if the integrity proof contained in the NONCE field of the HB 912 request does not match the integrity proof calculated locally by the trusted server 42 for the verification data recorded in the CHALLENGE field and stored locally for this DNS client.

[0161] If it does not detect any anomaly, the trusted server 42 validates the deactivation of the PER ASPERA service.

[0162] 5.3 Simplified structure of equipment and a trusted server according to one embodiment

[0163] Finally, in relation to Figure 10, we present the simplified structure of a piece of equipment, respectively of a trusted server, implementing a method for detecting a malicious server according to an embodiment described above.

[0164] As illustrated by Figure 10, such equipment, respectively trusted server, comprises a memory 101E, respectively 101S, comprising for example a buffer memory, a processing unit 102E, respectively 102S, equipped for example with a processor P, and controlled by the computer program Pg 103E, respectively 103S, implementing the method for detecting a malicious server according to an embodiment described above.

[0165] At initialization, the code instructions of the computer program 103E are for example loaded into a RAM memory 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 an embodiment described above, according to the instructions of the computer program 103E, to: transmit, to at least one of said trusted servers, at least one request for activation of a domain name resolution verification service, receive at least one response comprising at least one domain name generated by said trusted server for said at least one interface, transmit at least one request for resolution of said at least one domain name, if no request for resolution of said at least one domain name is received by said trusted server, or if at least one request for resolution of said at least one domain name is received by said trusted server but includes an anomaly, receive at least one notification inviting said equipment to take action.

[0166] At initialization, the code instructions of the computer program 103S are for example loaded into a RAM memory 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 an embodiment described above, according to the instructions of the computer program 103S, to: receive at least one request for activating a domain name resolution verification service, from said equipment, transmit at least one response comprising at least one domain name generated by said trusted server for said at least one interface, - if no request for resolving said at least one domain name is received by said trusted server, or if at least one request for resolving said at least one domain name is received by said trusted server but includes an anomaly, transmit to said equipment at least one notification inviting it to execute an action.

Claims

CLAIMS 1. Method for detecting a malicious domain name resolution server, implemented in equipment configured with at least one trusted domain name resolution server associated with at least one network interface via which said equipment is capable of communicating, implementing: - the transmission (111), to at least one of said trusted servers, of at least one request for activation of a domain name resolution verification service, - receiving (112) at least one response comprising at least one domain name generated by said trusted server for said at least one interface, - the transmission (113) of at least one request for resolution of said at least one domain name, - if no request for resolution of said at least one domain name is received by said trusted server, or if at least one request for resolution of said at least one domain name is received by said trusted server but includes an anomaly, the reception (114) of at least one notification inviting said equipment to take action.

2. Method according to claim 1, characterized in that said at least one response also comprises verification data generated by said trusted server for said at least one activation request, and in that said at least one request for resolution of said at least one domain name comprises proof of integrity obtained from said verification data.

3. Method according to claim 2, characterized in that said at least one request for resolution of said at least one domain name comprises an indicator requesting the generation, by said trusted server, of new verification data.

4. Method according to any one of claims 1 to 3, characterized in that said at least one response and / or said request for resolution of said at least one domain name are encrypted.

5. Method according to any one of the preceding claims, characterized in that said at least one response also includes recurrence information and in that said at least one request for resolution of said at least one domain name is transmitted taking into account said recurrence information.

6. Method according to any one of the preceding claims, characterized in that said at least one activation request comprises at least one contact address of said equipment.

7. Method according to any one of the preceding claims, characterized in that the descriptive information of said at least one trusted server is stored in a register maintained by said equipment and access to which is protected.

8. Method according to any one of the preceding claims, characterized in that said equipment executes at least one given action upon receipt of a notification inviting it to execute said at least one action, said at least one action belonging to the group comprising: - replace the active domain name resolution configuration with the configuration of one of said trusted servers, - disable outgoing communications except for communications to one of said trusted servers, - generate a local notification to inform a user of a change in the domain name resolution configuration, - request sending of the active domain name resolution configuration.

9. Method for detecting a malicious domain name resolution server, implemented in a trusted domain name resolution server configured in a device and associated with at least one network interface via which said device is capable of communicating, implementing: - receiving (121) at least one request for activation of a domain name resolution verification service, from said equipment, - the transmission (122) of at least one response comprising at least one domain name generated by said trusted server for said at least one interface, - if no request for resolution of said at least one domain name is received by said trusted server, or if at least one request for resolution of said at least one domain name is received by said trusted server but includes an anomaly, the transmission (124) to said equipment of at least one notification inviting it to execute an action.

10. Method according to claim 9, characterized in that an anomaly is detected if said at least one resolution request for said at least one domain name and if said at least one activation request do not come from the same equipment.

11. Method according to any one of claims 9 and 10, characterized in that said at least one response also comprises verification data generated by said trusted server for said at least one activation request, in that said at least one request for resolution of said at least one domain name comprises proof of integrity obtained from said verification data, and in that an anomaly is detected if said proof of integrity carried by said at least one request for resolution of said at least one domain name is not consistent with proof integrity obtained locally from said verification data known to said trusted server.

12. Method according to any one of claims 9 to 11, characterized in that said at least one response also includes information on the recurrence of said at least one request for resolution of said at least one domain name, and in that an anomaly is detected if no request for resolution of said at least one domain name is received by said trusted server or if said at least one request for resolution of said at least one domain name is not consistent with said recurrence information.

13. Method according to any one of claims 9 to 12, characterized in that said at least one action notification is transmitted to at least one contact address of said equipment carried by said activation request or to the address used by said equipment to transmit said activation request.

14. Method according to any one of claims 1 to 13, characterized in that said activation and / or resolution requests use an option according to the EDNS mechanism (“Extension Mechanisms for DNS”) to exchange information between said equipment and said trusted server.

15. Equipment configured with at least one trusted domain name resolution server associated with at least one network interface via which said equipment is capable of communicating, characterized in that it is configured to: - transmit, to at least one of said trusted servers, at least one request for activation of a domain name resolution verification service, - receive at least one response comprising at least one domain name generated by said trusted server for said at least one interface, - transmit at least one resolution request for said at least one domain name, - if no request for resolution of said at least one domain name is received by said trusted server, or if at least one request for resolution of said at least one domain name is received by said trusted server but contains an anomaly, receive at least one notification inviting said equipment to take action.

16. Trusted domain name resolution server configured in a device and associated with at least one network interface via which said device is capable of communicating, characterized in that it is configured to: - receive at least one request for activation of a domain name resolution verification service, from said equipment, - transmit at least one response comprising at least one domain name generated by said trusted server for said at least one interface, - if no request for resolution of said at least one domain name is received by said trusted server, or if at least one request for resolution of said at least one domain name is received by said trusted server but contains an anomaly, transmit to said equipment at least one notification inviting it to perform an action.

Images