FR3142817A1 - Methods for detecting a malicious domain name resolution server, equipment, trusted server and corresponding computer program. - Google Patents

Abstract

Methods for detecting a malicious domain name resolution server, equipment, trusted server and corresponding computer program. The invention relates to a method for detecting a malicious DNS server, implemented in equipment configured with at least one trusted DNS server, implementing: transmission (111), to at least one of said servers of trust, of at least one request for activation of a DNS verification service, the reception (112) of at least one response comprising at least one domain name generated by said trusted server, 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 is received but includes an anomaly , the reception (114) of at least one notification inviting said equipment to initiate an action. Figure for abstract: Figure 1

Description

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

1. Field of the invention

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

More specifically, the invention concerns name resolution services, for example DNS (in English “Domain Name System”), and proposes a solution helping to detect the presence of a malicious server involved in name resolution.

2. Prior art

The development of the Internet is based on a set of service offerings for the general public and business markets. Among these, so-called multi-service offers, including “Triple Play” offers (since they simultaneously offer access to the Internet, video content (including the broadcast of television programs) and conversational services (IP telephony) ), have captured a significant share of the market.

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

Since the CPE is a crossing point for traffic coming from or going to a user via an operator network, attacks can be carried out on this equipment, for example to intercept sensitive user data, such as Bank data.

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 via which the CPE is able to communicate.

As a reminder, a DNS service makes it possible to associate a resource (for example of the domain name type, URI (in English “Uniform Resource Identifier”, in French “unique 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 join 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.

If an attacker wishes to capture a user's traffic and intercept some of his data, he can, according to 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 to which the user initially 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, instead of the trusted DNS server initially configured. . 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 victim of the attack to fraudulent servers which will emulate certain sites (for example, servers used to carry out a financial transaction).

According to a second example, the attacker can also decide to redirect application requests sent by the user to a “legitimate” application server, to prevent the user from realizing that he is the target of an attack. In this case, the attacker first directs the user's requests to a "fraudulent" application server by manipulating DNS requests, 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 like a relay ("proxy") which completes 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.

Password protection of access to the CPE administration interface (which notably allows DNS information to be configured in the CPE) is not sufficient to protect the CPE from the attacks described above. Indeed, as most users do not use (or do not even suspect the existence of) a CPE administration interface, the protection of access to this administration interface is often weak. Likewise, protecting access to the CPE administration interface by MAC address (“Medium Access Control”) may prove ineffective because an attacker can change the MAC address of his terminal to be identical to that (s) authorized by the CPE. These MAC addresses can in fact be acquired maliciously by listening to Wi-Fi exchanges, for example.

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.

3. Presentation of the invention

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.

• la transmission, à destination d’au moins un desdits serveurs de confiance, d’au moins une requête d’activation d’un service de vérification de résolution de noms de domaine,
• la réception d’au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface,
• la transmission d’au moins une requête de résolution dudit au moins un nom de domaine,
• si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, la réception d’au moins une notification invitant ledit équipement à engager une action.

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,
• receiving 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 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 includes an anomaly, the receipt of at least one notification inviting said equipment to take action.

The proposed solution thus allows equipment (for example a terminal, a CPE, etc.) to initiate an action if a trusted domain name resolution server, configured for at least one network interface (for example Ethernet, Wireless LAN, etc.) of the equipment, detects an anomaly in a specific domain resolution request issued via an interface of the equipment.

More precisely, depending on 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, denoted for example “TARGET_HB_FQDN”, can be generated randomly by the trusted server. We therefore consider 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 request for resolution of this or these domain names is received by it, or if one or more requests for resolution of this or these domain names (called for example in the “HB” suite) are received but contain an anomaly (for example, the source address of the domain name resolution request is not an address of the equipment).

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

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

In addition, the proposed solution does not require traffic inspection in the network (for example in the access network) or communications profiling for anomaly detection. The solution can thus be implemented independently of the underlying connectivity offer.

Note that equipment 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 equipment, 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 about the internal interface used between an application and a name resolution function (a DNS client, typically).

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.

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

In a particular embodiment, said at least one request for resolution of said at least one domain name includes an indicator requiring the generation, by said trusted server, of new verification data.

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

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 denoted “HB (C, NONCE1)”.

Alternatively, it is the server which can initiate a change in the verification data.

Such a change in verification data may in particular be implemented on a regular basis or according to other policies local to the name resolution server.

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.

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

For example, the recurrence information provides the frequency of sending resolution requests (“HB”) by the equipment, the sending of a resolution request when the equipment is restarted, during a connection to a new network, etc.

In a particular embodiment, said at least one activation request includes at least one contact address of said equipment (denoted for example “CONTACT_URI”).

In this way, the trusted server can send the equipment a notification to this contact address to inform the equipment of anomaly(s) 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 described in particular 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.

Remember that it is classic to configure at least one list of at least one trusted server associated with at least one interface of equipment. According to the invention, such configuration information (i.e. descriptive information of said at least one trusted server) is stored in a specific register, access to which is protected, for example by a password or verification keys. This way, an attacker does not have direct access to this configuration information, which helps to strengthen the security of the proposed solution.

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

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

• remplacer la configuration de résolution de noms de domaine active par la configuration d’un desdits serveurs de confiance,
• désactiver les communications sortantes à l’exception des communications vers l’un desdits serveurs de confiance,
• générer une notification locale pour informer un utilisateur d’une modification de la configuration de résolution de noms de domaine,
• demander l’envoi de la configuration de résolution de noms de domaine active.

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:

• replace the active domain name resolution configuration with the configuration of one of said trusted servers,
• disable outgoing communications with the exception of communications to one of said trusted servers,
• generate a local notification to inform a user of a modification of the domain name resolution configuration,
• request sending of the active domain name resolution configuration.

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 involve the user in resolving anomalies. The user is therefore not expected to have any particular technical knowledge for the implementation of the invention.

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

• la réception d’au moins une requête d’activation d’un service de vérification de résolution de noms de domaine, en provenance dudit équipement,
• la transmission d’au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface,
• si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, la transmission audit équipement d’au moins une notification l’invitant à exécuter une action.

Such a trusted server implements the following steps:

• receiving at least one request for activation of a domain name resolution verification service, coming from said equipment,
• the transmission 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 to said equipment of at least one notification inviting it to execute an action.

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 check service if no domain name resolution request specific domain name is not received, or if a request to resolve the specific domain name is received but contains 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 because the trusted server is authoritative for the domain names generated for at least one interface of a piece of equipment.

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 does not come from the same equipment.

For example, the trusted server compares the addresses used for issuing the activation request and for sending the resolution request for said at least one domain name. If they differ or are not associated with the same equipment, the trusted server detects an anomaly.

According to a particular embodiment, said at least one response also includes verification data generated by said trusted server for said at least one activation request. In this case, said at least one resolution request for said at least one domain name includes 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 resolution of said at least one domain name is not consistent with a proof of integrity obtained from verification data known to the trusted server.

For example, the trusted server randomly generates verification data and transmits it in its response. The equipment 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 that it knows, and compare it with the digest received in the resolution request.

According to a particular embodiment, said at least one response includes 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.

As indicated previously, 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.

According to a particular embodiment, said at least one response also includes recurrence information (denoted 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 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.

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

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 document RFC 6891 (“Extension Mechanisms for DNS” (EDNS) d 'April 2013) to transmit various 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.).

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 can include the different characteristics relating to the process according to the invention, which can be combined or taken separately. For example, the equipment is of the CPE, terminal, etc. type. The equipment can be connected to a fixed network, a mobile network, a network of connected objects (for example a mesh network using the “Thread” protocol), etc.

In another embodiment, the invention relates to a corresponding trusted server. Such a trusted server 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 a server can include the different characteristics relating to the method according to the invention, which can be combined or taken in isolation.

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 mode of embodiment of the invention, when this or these programs is/are executed by a processor.

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

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

4. List of figures

• la illustre les principales étapes d’un procédé de détection d’un serveur de résolution de noms de domaine malveillant selon un mode de réalisation,
• la présente le format générique d’une option WADE selon un mode de réalisation,
• la présente un exemple d’option WADE selon un mode de réalisation,
• la illustre un exemple de messages échangés entre un client DNS et un serveur de confiance sans détection d’anomalie,
• la illustre un exemple de messages échangés entre un client DNS et un serveur de confiance avec modification des données de vérification à l’initiative du client DNS,
• la illustre un exemple de messages échangés entre un client DNS et un serveur de confiance avec modification des données de vérification à l’initiative du serveur de confiance,
• la illustre un exemple de messages échangés entre un client DNS et un serveur de confiance avec détection d’une anomalie de type non-respect de l’information de récurrence,
• la illustre un exemple de messages échangés entre un client DNS et un serveur de confiance avec détection d’une anomalie liée à l’adresse source,
• la illustre un exemple de messages échangés entre un client DNS et un serveur de confiance pour la désactivation d’un service de vérification de résolution de noms de domaine, et
• la présente la structure simplifiée d’un équipement, respectivement d’un serveur de confiance, selon un mode de réalisation.

Other characteristics and advantages of the invention will appear more clearly on reading the following description of a particular embodiment, given by way of a simple illustrative and non-limiting example, and the appended drawings, among which:

• there illustrates the main steps of a method for detecting a malicious domain name resolution server according to one embodiment,
• there presents the generic format of a WADE option according to one embodiment,
• there presents an example of a WADE option according to one embodiment,
• there illustrates an example of messages exchanged between a DNS client and a trusted server without anomaly detection,
• there 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,
• there 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,
• there illustrates an example of messages exchanged between a DNS client and a trusted server with detection of an anomaly such as non-compliance with recurrence information,
• there illustrates an example of messages exchanged between a DNS client and a trusted server with detection of an anomaly linked to the source address,
• there 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
• there presents the simplified structure of equipment, respectively of a trusted server, according to one embodiment.

5. Description of an embodiment of the invention

5.1 General principle

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

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 establishment of a procedure for issuing requests resolutions related 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 request for resolution of the specific domain name that it receives includes a anomaly. The trusted server can then inform the equipment, which can then take appropriate actions.

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

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

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

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

Alternatively, the activation request may be a “non-dedicated” request. In this case, the equipment does not generate a DNS request relating to a domain name dedicated to the activation of the domain name resolution verification service, but uses a classic DNS request, for example a DNS request issued for needs of an application embedded in the equipment, and inserts information for the activation of the domain name resolution service. A classic DNS query is thus diverted by inserting specific information, 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. considers that such a domain name is unique and that the trusted server is authoritative for the domain name thus generated. According to the example illustrated by , the trusted server transmits a single REP response bearing a unique domain name. The equipment 11 receives the REP response during a step 112.

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

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

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

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).

As described below, different information can 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 can be transmitted in the REP response from the trusted server to the equipment, and used by the equipment to manage the transmission of the domain name resolution request. unique DNS REQ to the trusted server. An anomaly may in particular be detected if the ACTIV activation request and the REQ DNS unique domain name resolution request do not come from the same equipment, or if proof of integrity, obtained from the verification data and conveyed by the DNS REQ query, is not consistent with a proof of integrity obtained from verification data known to and maintained locally by the trusted server, or if the issuance of the DNS REQ query(ies) is not conforms to the recurrence information, or if the DNS REQ query includes information from a DNS relay, for example.

5.2 Detailed description of a particular embodiment

5.2.1 Initial setup

A detailed example of implementation of the invention is described below. We consider that a user of the equipment (for example a terminal) wishes to activate a domain name resolution verification service. Subsequently, we call such a service “PER ASPERA” (“PER-DNS client guards against malicious DNS Server swaPping, traffic intERception, and datA theft”, or “procedure for detection and mitigation of DNS configuration changes”).

For example, the user can subscribe to the PER ASPERA service using a dedicated interface. The PER ASPERA service may in particular be provided to terminals directly connected to the network of a service provider or reserved for offers which are 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. Note that the PER ASPERA service may be offered by a connectivity service provider, a DNS service provider, etc. In particular, a user may request a DNS service provider distinct from the provider providing connectivity. The user 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 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 can only be used for some of the interfaces.

Conventionally, the equipment, or at least one network interface of the equipment, is configured with at least a 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, secure. 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.

The configuration of the list or lists of at least one trusted server can 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 can be configured per network interface (wired, wireless). wire, 5G, etc.). In this case, a list of at least one trusted server can be associated with an identifier of the network interface concerned.

• index de politique / d’action « 0 » : remplacer la configuration de résolution de noms de domaine active par la configuration d’un des serveurs de confiance,
• index de politique / d’action « 1 » : désactiver les communications sortantes à l’exception des communications vers l’un des serveurs de confiance pour une interface donnée,
• index de politique / d’action « 2 » : générer une notification locale pour informer l’utilisateur d’une modification de la configuration de résolution de noms de domaine,
• index de politique / d’action « 3 » : demander l’envoi de la configuration de résolution de noms de domaine active,
• etc.

According to a particular embodiment, the equipment can 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 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 active domain name resolution configuration,
• etc.

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 notably implement strong authentication mechanisms (for example, through the use of a dedicated password or multi-level verification keys). The location of such a register can in particular be decided when activating the PER ASPERA service. The registry can correspond to dedicated entries in a Windows© registry, a file, a database, etc.

In particular, such a register is distinct from any other register used for the storage of other information relating to domain name resolution. The register where the list(s) of at least one trusted server are stored is therefore isolated from other registers used for storing information used for DNS management.

Optionally, the descriptive information of the trusted server(s) may be duplicated to be stored on the one hand in the register to which access is protected, and on the other hand in a register conventionally used for storing information relating to resolution. of domain names.

This isolation aims to prevent modification of the list of trusted DNS servers by a malicious application or following fraudulent access to the equipment.

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

5.2.2 Activation of the PER ASPERA service

Subsequently, we use the term “DNS client” to designate the equipment or at least one network interface of the equipment implementing the proposed solution.

As described in the , 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.

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. Alternatively, the activation request may be non-dedicated, particularly when conventional requests are used for the needs of common applications. In this case, the DNS client uses a request issued for example by an application embedded in the equipment by inserting the information required for activation of the PER ASPERA service.

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 concerned interface. Indeed, sending these different requests via 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.

If several lists of trusted servers 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 of the interfaces of a piece of equipment when they are associated with different trusted servers.

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 named 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.

The generic format of the WADE option is shown in the .

• le bit H, aussi appelé « HB_ENABLE » (pour « Heartbeat Enable » en anglais), positionné à la valeur « 1 » indique une demande d’activation du service PER ASPERA, alors que la valeur « 0 » est utilisée pour désactiver le service PER ASPERA,
• le bit N positionné à la valeur « 1 » indique la présence du champ « NONCE »,
• le bit C positionné à la valeur « 1 » indique la présence du champ « CHALLENGE »,
• le bit T positionné à la valeur « 1 » indique la présence du champ « TARGET_HB_FQDN »,
• le bit E positionné à la valeur « 1 » indique la présence du champ « EPOCH »,
• le bit U positionné à la valeur « 1 » indique la présence du champ « CONTACT_URI ».

As illustrated by the , 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” in English), set to the value “1” indicates a request for activation of the PER ASPERA service, while the value “0” is used to deactivate the service PER ASPERA,
• the N bit set to the value “1” indicates the presence of the “NUNCE” 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” field.

These different fields (“NUNCE”, “CHALLENGE”, “TARGET_HB_FQDN”, “EPOCH”, “CONTACT_URI”) are presented below. In particular, the “CHALLENGE”, “TARGET_HB_FQDN”, and “EPOCH” fields are populated by a trusted server.

When several of these fields are transported in the same WADE option, then these different fields are inserted according to the order of the control bits. Variable parameters are preceded by a field which indicates the size of the parameter.

An activation request including the WADE option, as illustrated by , 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”.

Thus, the H bit can take a value “1” to indicate a request for activation of the PER ASPERA service. The “U” bit can also take a value “1” to indicate the presence of the “CONTACT_URI” field. A “URI_Length” field can in particular be provided to indicate the size of the parameter present in the “CONTACT_URI” field, as illustrated by the .

Such a “CONTACT_URI” 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 observed in the DNS configuration information (for example by sending the DNS client a notification accordingly). inviting action).

If the U bit is set to the value “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 “CONTACT_URI” field.

If the U bit is set to the value “0”, i.e. if the “CONTACT_URI” field is not present, this means that the contact address for sending notifications is the address (as well as the number of port) used by the DNS client to send this activation request.

Please note that the PER ASPERA service can be deactivated at any time by equipment. To do this, a request that contains the WADE option can be sent from the DNS client to a trusted server, using the H bit set to the value "0". In the following, we assume that the service is activated.

Note that such a WADE option is only inserted in a DNS request intended for a trusted server. This verification is based, for example, on the destination IP address of the DNS request or the DNA (“Authentication Domain Name”) of the target DNS server.

5.2.3 Response from the trusted server

As indicated in connection with the , at least one trusted server receives at least one activation request for the PER ASPERA service during a step 121.

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

If a trusted server supports the WADE option, then it can process the activation request received. In particular, the trusted server can extract the information communicated in the WADE option, in particular 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 re-use. A trusted server can thus maintain one or more source addresses per DNS client.

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

In particular, such a response including the WADE option uses bits H and T, and possibly bits C and E, positioned at 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 a request for activation of the PER ASPERA service.

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 in particular be provided to indicate the size of the parameter present in the “TARGET_HB_FQDN” field.

Such a “TARGET_HB_FQDN” field includes one or more specific domain names generated by the trusted server for the DNS client considered. 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.

Optionally, bit C can take a value “1” to indicate the presence of a “CHALLENGE” field. A “CHALLENGE_Length” field can in particular be provided to indicate the size of the parameter present in the “CHALLENGE” field.

Such a “CHALLENGE” field contains verification data that can be used by the DNS client to determine proof of integrity. For example, such verification data may be randomly generated and used by the DNS client to calculate a proof of integrity, such as a hash. Such integrity proof can then be inserted by the DNS client in subsequent DNS requests intended for the trusted server.

Optionally, bit E can take a value “1” to indicate the presence of an “EPOCH” field. An “EPOCH_length” field can in particular be provided to indicate the size of the parameter present in the “EPOCH” field.

Such an “EPOCH” field includes recurrence information, used by the DNS client to transmit “HB” domain name resolution requests. For example, such a field indicates the periodicity of HB queries by the DNS client.

If the “EPOCH” and “CHALLENGE” fields are activated, bits C, T, E are set to the value “1” and bits U and N are set to the value “0”.

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

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.

5.2.4 Request for resolution of the domain name of the TARGET_HB_FQDN field

As indicated in connection with the , the DNS client receives a response from the trusted server during a step 112.

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 may be sent to the DNS client by a trusted server. All this information can be stored by the DNS client in an appropriate registry, access to which can be protected.

As illustrated by the , 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 the WADE option as illustrated over there . 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”.

The N bit can be set to “1” to indicate the presence of the “NUNCE” field. A “NONCE_Length” field can in particular be provided to indicate the size of the parameter present in the “NONCE” field.

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

There illustrates an example of messages exchanged between a DNS client 41 and a trusted DNS server 42.

For example, we consider that the DNS client 41 sends an activation request using its address @1 as a source address, and that the trusted server 42 constructs a response including 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 trust server 42 has the information contained in the fields “TARGET_HB_FQDN », “EPOCH” and “CHALLENGE”, and the source address of the activation request (@1).

According to the example considered, the DNS client 41 can in particular issue one or more DNS queries for the resolution of the domain name indicated in the "TARGET_HB_FQDN" field, denoted 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 T1 sending frequency of HB requests. Thus, a first HB request for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field can be issued at time T0+T1, a second HB request for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field can be issued at time T0+2*T1, a third HB request for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field can be issued at time T0+3*T1, etc.

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.

Depending on the example considered, the DNS client 41 can in particular calculate a summary of the verification data conveyed in the “CHALLENGE” field of the response received during the PER ASPERA activation phase. Such a summary can in particular be inserted in the “NUNCE” field of the HB request which contains the WADE option.

According to the example illustrated by , 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 “NUNCE” field, at time T0+T1. On receipt of the first HB request (412), the trust 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 , ie allow the same equipment to be identified (src@=@1). If this is not the case, an anomaly is detected. The trust server 42 can also verify that the proof of integrity contained in the “NUNCE” field of the HB request is consistent with a proof of integrity determined locally from the verification data stored by the trust server 42 (such as recorded in the “CHALLENGE” field in the response sent by the trusted server). In particular, the trusted server 42 can calculate a digest of the verification data (for example carry out 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. verification (for example “Secure Hash Algorithms (SHAs)” described in the RFC 6234 document “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 trust server 42. The trust server 42 can also check whether the recurrence information specified in the “EPOCH” field is respected. 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, a bit. “I” is defined for this purpose among the “unassigned” bits described in the . 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).

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 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.

In the example illustrated by , no anomaly is detected.

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.

There 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.

We consider for example that the DNS client 41 issues an activation request using its address @1, and that the trusted server 42 constructs a response including the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGE1” (Activ. PER APSERA 511).

According to the example illustrated by , the DNS client 41 issues a first HB request (512) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity in the “NONCE1” field, at time T0+T1. On receipt of the first HB request (512), the trust 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 trust 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 “CHALLENGE1” field. In particular, the trusted server 42 can calculate a digest of the verification data (Hash (CHALLENGE1)) 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.

The DNS client 41 may request to modify the verification data (“CHALLENGE1”) at any time. 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 data from checking the “CHALLENGE1” field. To inform the trusted server 42 that the DNS client 41 requests new verification data, bits C and N are set to “1”.

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).

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, including a proof of integrity in the “NONCE2” field, at time T0+2T1. Such proof of integrity is obtained from the new “CHALLENGE2” verification data. On receipt of the third HB request (515), the trust 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. allow the same equipment to be identified (src@=@1). The trust server 42 can also verify that the proof of integrity contained in the “NONCE2” field of the HB request is consistent with a proof of integrity determined locally from the new verification data stored by the trust server 42 ( as contained in the “CHALLENGE2” field of 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 contained in the “NONCE2” field. The trusted server 42 can also check whether the recurrence information contained in the “EPOCH” field is respected.

The DNS client 41 can issue a fourth HB request (516) and so on.

There 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.

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 including the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGE1” (Activ. PER APSERA 611).

According to the example illustrated by , the DNS client 41 issues a first HB request (612) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity in the “NONCE1” field, at time T0+T1. On receipt of the first HB request (612), the trust 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 trust 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 “CHALLENGE1” field. In particular, the trusted server 42 can calculate a digest of the verification data (Hash (CHALLENGE1)) 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.

The trusted server 42 can decide at any time to modify the verification data (“CHALLENGE1”).

For example, upon receipt of a second HB request (613) for the resolution of the domain name indicated in the "TARGET_HB_FQDN" field including 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, bit C is set to “1”.

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, including a proof of integrity contained in the “NONCE2” field, at time T0+2T1. Such proof of integrity is obtained from the new “CHALLENGE2” verification data. On receipt of the third HB request (615), the trust 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. allow the same equipment to be identified (src@=@1). The trust server 42 can also verify that the proof of integrity recorded in the “NONCE2” field of the HB request is consistent with a proof of integrity determined locally from the new verification data stored by the trust 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 check whether the recurrence information contained in the “EPOCH” field is respected.

The DNS client 41 can issue a fourth HB request (616) and so on.

For example, the trusted server 42 can modify the verification data at regular intervals for security purposes.

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

There illustrates an example of messages exchanged between the DNS client 41 and the trusted server 42. We consider for example that the DNS client 41 issues an activation request using its address @1, and that the trusted server 42 constructs a response containing the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGE” (Activ. PER APSERA 711).

According to the example illustrated by , the DNS client 41 issues a first HB request (712) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity recorded in the “NONCE” field. On receipt of the first HB request (712), the trust 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 trust server 42 can also verify that the proof of integrity contained in the “NUNCE” 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 check whether the recurrence information recorded in the “EPOCH” field is respected.

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

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.

For example, a notification message can be Push HTTPS, Update DNS, etc. Such a message may in particular 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 initiates an action such as 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 initiates an action such as "disable outgoing communications with the exception of communications to one of the trusted servers for the 'interface considered', etc.

The exchange illustrated by 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 a or several actions upon receipt of the notification message(s), such as reinstalling the trusted DNS configuration, blocking certain communications, etc.

Once the trusted DNS configuration has been reinstalled for example (reinstallation of the descriptive information of the trusted DNS servers), the trusted server 42 can again receive an HB request.

We now present, in relation to the , the detection of an anomaly when the source address of an HB request is not consistent with the source address of the activation request. Similar steps can be implemented when the proof of integrity conveyed by an HB request is not consistent with the proof of integrity determined locally by the trusted server from verification data known to the trusted server. Depending on one or both of these cases, this typically means that the HB request was relayed by another potentially malicious DNS server. The trusted server can thus detect that the HB requests (or any other DNS request) issued by the DNS client are intercepted by another DNS server before being routed to the trusted server.

There illustrates an example of messages exchanged between the DNS client 41 and the trusted server 42. We consider for example that the DNS client 41 issues an activation request using its address @1, and that the trusted server 42 constructs a response containing the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGE” (Activ. PER APSERA 811).

According to the example illustrated by , the DNS client 41 issues a first HB request (812) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity recorded in the “NONCE” field. On receipt of the first HB request (812), the trust 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 trust server 42 can also verify that the proof of integrity contained in the “NUNCE” 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 check whether the recurrence information specified in the “EPOCH” field is respected.

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. But as illustrated by the , this second HB request (813) is intercepted by a server F 83 and relayed to the trusted server 42. On receipt of the second HB request (813), the trusted server 42 notes that the source address of the request activation (@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 was probably 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 such as “request the sending of 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 such as replacing the active domain name resolution configuration with the configuration of one of the trusted servers, etc. Note that the trusted server 42 can trigger the execution of several actions for HB exchanges using an IP address distinct from that used during activation of the PER ASPERA service.

The exchange illustrated by 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 messages between the DNS client 41 and the trusted server 42.

Once the trusted DNS configuration has been reinstalled for example (reinstallation of the descriptive information of the trusted DNS servers), the trusted server 42 can again receive an HB request.

In a particular embodiment, the trusted server 42 can also include an EDE option, as described in document RFC 8914 “Extended DNS Errors” of October 2020, to inform the DNS client that a DNS error has been observed by the trusted server. Upon receipt of this response, the DNS client can proceed to perform the action indicated in this response. Alternatively, the indication of the action to be performed by a DNS client can be provided using the WADE option. To do this, an “A” bit is defined for this purpose among the “unassigned” bits presented in the . When the “A” bit is set to “1”, the action index is entered in the body of the WADE option.

Finally, we present, in relation to the , 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 including the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGE” (Activ. PER APSERA 911).

According to the example illustrated by , 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 including 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 H bit “HB_ENABLE” is set to “0”.

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

If it does not detect an anomaly, the trust server 42 validates the deactivation of the PER ASPERA service.

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

We finally present, in relation to the , the simplified structure of equipment, respectively of a trusted server, implementing a method for detecting a malicious server according to an embodiment described above.

As illustrated by the , 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 program computer Pg 103E, respectively 103S, implementing the method of detecting a malicious server according to an embodiment described above.

• transmettre, à destination d’au moins un desdits serveurs de confiance, au moins une requête d’activation d’un service de vérification de résolution de noms de domaine,
• recevoir au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface,
• transmettre au moins une requête de résolution dudit au moins un nom de domaine,
• si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, recevoir au moins une notification invitant ledit équipement à engager une action.

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, for:

• 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 includes an anomaly, receive at least one notification inviting said equipment to take action.

• recevoir au moins une requête d’activation d’un service de vérification de résolution de noms de domaine, en provenance dudit équipement,

• transmettre au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface,
• si aucune requête de résolution dudit au moins un nom de domaine n’est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, transmettre audit équipement au moins une notification l’invitant à exécuter une action.

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, for:

• receive at least one request for activation of a domain name resolution verification service, coming 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 includes an anomaly, transmit said equipment at least one notification inviting it to perform an action.

Claims (16)

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 able to communicate , 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 receipt (114) of at least one notification inviting said equipment to initiate an action.

Method according to claim 1, characterized in that said at least one response also includes 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 least one domain name includes proof of integrity obtained from said verification data. Method according to claim 2, characterized in that said at least one request for resolution of said at least one domain name includes an indicator requiring the generation, by said trusted server, of new verification data. 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. 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. 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. 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. 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 with the exception of communications to one of said trusted servers,
• generate a local notification to inform a user of a modification of the domain name resolution configuration,
• request sending of the active domain name resolution configuration.

Method for detecting a malicious domain name resolution server, implemented in a trusted domain name resolution server configured in equipment and associated with at least one network interface via which said equipment is able to communicate, implementing:

• receiving (121) at least one request for activation of a domain name resolution verification service, coming 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.

Method according to claim 9, characterized in that an anomaly is detected if said at least one request for resolution of said at least one domain name and if said at least one activation request do not come from the same equipment. Method according to any one of claims 9 and 10, characterized in that said at least one response also includes 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 includes a 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 a proof of integrity obtained locally from said verification data known to said trusted server. Method according to any one of claims 9 to 11, characterized in that said at least one response also includes recurrence information for 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. 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 for transmitting said activation request. 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. Equipment configured with at least one trusted domain name resolution server associated with at least one network interface via which said equipment is able to communicate, 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 includes an anomaly, receive at least one notification inviting said equipment to take action.

Trusted domain name resolution server configured in equipment and associated with at least one network interface via which said equipment is able to communicate, characterized in that it is configured to:

• receive at least one request for activation of a domain name resolution verification service, coming 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 includes an anomaly, transmit said equipment at least one notification inviting it to perform an action.