Traffic redirection methods, corresponding terminals, controllers, authorization servers, name resolution servers, and computer programs.

Abstract

Method for traffic redirection, corresponding terminal, controller, authorization server, name resolution server, computer program. The invention relates to a name resolution method implemented in a terminal (51) connected to a communication network, the method comprising a step (511) of sending a name resolution message to a first name resolution server via a secure communication channel between the terminal (51) and a first name resolution server, a step (512) of obtaining at least one identifier of a second name resolution server for said redirection if redirection of the DNS traffic of the terminal is authorized, and a step (513) of performing at least one of the following actions for managing the redirection of the DNS traffic of the terminal to the second name resolution server: verifying the legitimacy of the second name resolution server, sending a notification of failure of connection between the terminal and the second name resolution server, requesting deactivation of the redirection of DNS traffic to the second name resolution server.

Description

[[Technical Field]]

[0001] The field of the present invention is the field of communications in communication networks, for example computer networks implementing the IP protocol. In particular, the present invention relates to value-added IP services.

[0002] More particularly, the present invention relates to name resolution services, such as DNS ("Domain Name System"), and provides a solution for guaranteeing the integrity and availability of DNS services and detecting the presence of malicious devices involved in name resolution. [[Background Art]]

[0003] The DNS system is a key component in the provision of IP services.

[0004] In fact, using the DNS service, a resource (for example, a domain name type of FQDN ("Fully Qualified Domain Name") or URI ("Uniform Resource Identifier")) can be associated with one or more IP addresses to allow access to the resource. For example, by using the DNS service, a terminal can obtain an IPv4 address or IPv6 address associated with a domain name.

[0005] Various solutions may be considered for providing DNS services to terminals.

[0006] An example based on the use of a residential gateway, also called HG, which is an abbreviation for "home gateway", or CPE, which is an abbreviation for "customer premises device", will be described below with reference to FIGS. 1A to 1C.

[0007] It should be noted that such home gateways traditionally function as an interface between the user's local area network ("Local Area Network" (LAN)) and the network of the operator ("Internet Service Provider" (ISP)) from which the user subscribes to service offers. Therefore, it is a device for accessing the operator's network through which all characteristic traffic for the various services the user subscribes to passes, and it also supports a set of services provided locally to the terminal (e.g., FTP service "File Transfer Protocol", NFS service "Network File System", media server).

[0008] When connecting a CPE to a network, the operator typically provides the CPE with the information necessary to access the connection services. Therefore, the operator assigns an IPv4 address and / or IPv6 prefix that can be associated with the CPE in order to establish IPv4 and / or IPv6 communication with terminals connected to it. The operator also provides the CPE with a list of DNS servers to be used for name resolution. To do this, protocols such as DHCP for IPv4 ("Dynamic Host Configuration Protocol" as described in documents RFC2131 ("Dynamic Host Configuration Protocol", R. Droms et al., March 1997) and RFC2132 ("DHCP Options and BOOTP Vendor Extensions", S. Alexander, March 1997)), DHCPv6 for IPv6 ("Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" as described in document RFC8415 ("Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", T. Mrugalski et al., November 2018)), or ND for IPv6 ("Neighbor Discovery Protocol" as described in document RFC4861 ("Neighbor Discovery for IP Version 6 (IPv6)", T. Narten et al., September 2007)) may be used between the CPE and the access network. Other mechanisms such as CWMP ("CPEWAN Management Protocol") may be used for configuring the CPE.

[0009] Therefore, as shown in Figures 1A to 1C, a terminal H1 11 (or application) located within a local area network (LAN) wants to establish communication with a remote server S12 identified by a domain name (e.g., FQDN), e.g., "notreexample.com". The DNS client built into terminal H1 11 may send a DNS request, also called a DNS resolution request, of type A (if the terminal supports IPv4) and / or type AAAA (if the terminal supports IPv6) to one of the DNS servers 13 (e.g.) provided by the operator and hosted on the access network, in order to obtain the IP address associated with the domain name "notreexample.com".

[0010] It should be noted that servers reachable via IPv4 may expose A-type DNS records, while servers reachable via IPv6 may expose AAAA-type records. Servers reachable via both IPv4 and IPv6 can expose A and AAAA-type records. A device wishing to access such a server must specify the record type (A or AAAA) in its DNS request. A device supporting both IPv4 and IPv6 may send two DNS requests: the first request for an A-type record, and the second request for an AAAA-type record.

[0011] A DNS request may be sent directly from terminal H1 11 to DNS server 13, as shown in Figure 1A, or, if a DNS proxy (also called a DNS relay or "DNS forwarder" as defined in document RFC8499 - "DNS Terminology", P. Hoffman et al., January 2019) is embedded, as shown in Figure 1B, it may be sent to CPE 14. In the latter case, if no response is found in the local cache, CPE 14 can relay the DNS request to DNS server 13.

[0012] DNS server 13, for the requested record type (A or AAAA), will respond with a list of IP addresses (e.g., @S) if at least one entry corresponding to the tracked domain name is available in its database, or, if DNS server 13 does not have such an entry, it can relay the request to another DNS server according to the hierarchical structure of the DNS architecture. The response received from another DNS server higher up in the hierarchy (e.g., an authoritative server) is then relayed to terminal H1 11 by the initially requested DNS server 13.

[0013] As shown in Figure 1A, the DNS response can be sent directly from the DNS server 13 to terminal H1 11, or, as shown in Figure 1B, it can be sent to the CPE 14 if a "DNS forwarder" exists. In the latter case, the "DNS forwarder" on the CPE 14 relays the DNS response to terminal H1 11.

[0014] Therefore, as shown in Figure 1C, terminal H1 11 can establish communication with server S12 by extracting the IP address (or multiple addresses) contained in the response (e.g., @S) and sending a connection request to one of the returned addresses (e.g., @S).

[0015] A DNS server is typically a nominal server if it is declared by the operator to connect a communication device to the network via the access network, or to connect using a pre-configured (such as a "factory" configuration) server. During this step, the communication device obtains accessibility information from one or more (nominal) DNS servers provided by the operator. Accessibility information may include lists such as IP addresses, port numbers, and authentication references. The operator may be a service provider, such as a connection or VoIP provider. Therefore, each of these operators may provide its own DNS service, typically by hosting one or more DNS servers within its infrastructure. The service may be provided via fixed infrastructure or mobile infrastructure (e.g., a "Public Land Mobile Network" of type PLMN).

[0016] Furthermore, the number of third-party entities providing public DNS services ("public resolvers") has been increasing recently. For example, such DNS servers are operated by entities such as "Google Public DNS®," "Cloudflare®," or "QUAD9®."

[0017] An increasing number of clients are enabling access to public DNS servers by replacing or adding to the DNS configuration provided by the operator.

[0018] Therefore, communication devices can obtain a new DNS configuration for each valid network interface (such as fixed, mobile, or WLAN ("Wireless Local Area Network")). Other information (e.g., the accessibility of SIP ("Session Initiation Protocol") servers) may also be provided to communication devices.

[0019] A drawback of DNS server discovery mechanisms within a LAN network is that they are insecure.

[0020] For example, as shown in Figure 2, when terminal H1 21 connects to a local area network (LAN), it may receive a message from the malicious device RS23 in response to its request, for example, according to the DHCP or ND protocol. Thus, terminal H1 21 can receive a router advertisement type RA ("router advertisement") message originating from the malicious device RS23 and consider the malicious device RS23 to be its default router.

[0021] Terminal H1 21, which wants to establish communication with a remote server S22 identified by a domain name, can send its DNS request to a malicious device RS23 instead of CPE24. The malicious device RS23 may host a malicious DNS server and respond with the address of the malicious remote server AS25 (e.g., @AS).

[0022] Subsequently, terminal H1 21 extracts the IP address (or multiple addresses) (e.g., @AS) included in the response and establishes communication with the malicious server AS25.

[0023] Therefore, the lack of a secure detection mechanism within the LAN network makes it easier to carry out attacks that allow for the interception of users' sensitive data (such as personal data) or redirection to malicious sites, as shown in Figure 2.

[0024] The first solution to consider is one based on the use of authentication certificates.

[0025] Nevertheless, such solutions are insufficient to detect malicious devices. In fact, malicious devices may present valid certificates obtained from a valid certification authority, potentially misleading devices on the LAN.

[0026] To solve this security problem, some browsers and applications use a list of authorized servers (an "allow list" or "whitelist") managed by an internet service provider or an application to determine whether a detected DNS server is legitimate (i.e., trusted). For example, the list of authorized servers ("Trusted Recursive Resolver") maintained by Firefox® is accessible at the link https: / / wiki.mozilla.org / Trusted_Recursive_Resolver.

[0027] If the detected DNS server is legitimate (i.e., the detected server is included in the list), then the client / terminal can proceed to switch from an insecure connection (DNS based on the UDP / TCP protocol over port 53, also referred to as Do53) to a secure connection, for example, the HTTPS (DoH) protocol described in document RFC 8484 - "DNS Queries over HTTPS (DoH)", P. Hoffman et al., October 2018, or DNS over QUIC (DoQ) described in document "DNS Queries over Dedicated QUIC Connections", C. Huitema et al., October 20, 2020.

[0028] The problem with this procedure of automatically upgrading insecure connections to secure connections ("automatic upgrade") lies in maintaining the list of authorized servers. In fact, the content and / or size of the list can change rapidly, particularly with the addition or removal of servers.

[0029] Restricting such a list of allowed servers to only servers operated by an Internet Service Provider (ISP) or an application provider also affects the provision of services that require the presence of a DNS relay, also commonly referred to as a "DNS forwarder", within a local area network. In fact, some services provided to terminals connected to a local area network require enabling a local "DNS forwarder". Therefore, it is necessary to add the local "DNS forwarder" to this list of allowed servers. Note, however, that these "DNS forwarders" are not accessible from the Internet.

[0030] To solve this problem, a solution for redirecting DNS requests transmitted in HTTPS messages, that is, a solution based on a secure connection, is particularly proposed, as described in the document "Supporting Redirection for DNS Queries over HTTPS (DoH)" by M. Boucadair et al., dated August 27, 2020.

[0031] According to this technique, an operator (such as an Internet service provider) can add its own DNS server to the list of allowed servers. The operator's DNS server, with which a secure connection is established, also referred to as a DoH server or another partner server, is notified by a CPE within the LAN. The operator then generates the domain name and certificate for the CPE incorporating the "DNS forwarder".

[0032] As shown in Figure 3, a DoH client (e.g., incorporated in a terminal 31 connected on a LAN) implements an automatic update procedure for its Do53 connection by connecting to the announced DoH server 32. To do this, the DoH client sends a DoH request 33 to the DoH server 32.

[0033] In response to a client request to establish a DoH connection with CPE35, which hosts the "DNS forwarder," DoH server 32 returns a redirect message 34. DoH server 32 communicates to the client the identifier used for authentication purposes (e.g., PKIX authentication representing "Public Key Infrastructure Using X.509") and the address for joining the "DNS forwarder" on CPE35. Other information may also be returned (such as a port number).

[0034] An example of a JSON ("JavaScriptObjectNotation") object returned by the operator's DoH server 32 is shown in the appendix.

[0035] Upon receiving the redirect message 34, client 31 uses the acquired information to establish a DoH session 36 with CPE 35. CPE 35 maintains a DoH session 37 with the operator's DoH server 32. In particular, this session may be used in this example to handle requests that cannot be processed locally by the local "DNS forwarder" built into CPE 35.

[0036] However, simply maintaining this DoH connection is not enough to minimize the risk of DNS requests sent by clients / terminals being hacked. In fact, this mechanism cannot detect the presence of malicious servers, especially within a LAN. For example, a malicious server could hijack the CPE's IP address and intercept DoH requests sent from LAN terminals. A malicious server may also block messages sent by the CPE.

[0037] Therefore, as shown in Figure 4A, in order to reach a legitimate CPE 45, terminal 41 sends a DoH request 43 to the operator's DoH server 42, receives a redirect message 44 in response, and can communicate to terminal 41 the identifier and address used for PKIX authentication purposes. If a malicious server 46 intercepts the IP address (@CPE) of CPE 45, terminal 41 attempts to establish a session with the malicious server 46 by sending a DoH request 47. Nevertheless, the response 48 sent by the malicious server 46 is rejected by terminal 41 because PKIX authentication fails, and terminal 41 cannot access the service. If terminal 41 ignores the redirect instructions and attempts to connect to the operator's DoH server 42, the DoH server 42 systematically sends redirect messages similar to the message 44 described above, communicating to terminal 41 the identifier used for PKIX authentication purposes and the address to reach a legitimate CPE 45.

[0038] Therefore, a drawback of such technologies using conventional methods is the risk of losing access to connectivity services, including local services (i.e., services provided thanks to the presence of a "DNS forwarder" within the CPE).

[0039] In fact, as shown in Figure 4B, if the malicious server 46 succeeds in obtaining the authentication identifier used by the CPE 45, a secure connection may be established between the terminal 41 and the malicious server 46, and between the malicious server 46 and the remote server 49. Despite the existence of such a secure connection, the malicious server 46 may recover all DNS requests sent by the terminal 41 and, in some cases, recover the personal data of the terminal's user.

[0040] Therefore, simply establishing a secure connection is not sufficient to guarantee the legitimacy of the server to which that connection is established.

[0041] Therefore, enabling protocols such as DoH (Application Layer Protocol) and DoT (a transport layer protocol described in document RFC7858 – “Specification for DNS over Transport Layer Security (TLS)”, Z. Hu et al., May 2016) does not resolve the aforementioned security issues related to the mechanism for discovering legitimate DNS servers within a LAN network.

[0042] Therefore, a new solution is needed that can provide value-added services, guarantee the legitimacy of the DNS servers to which these users send name resolution requests, ensure service continuity based on DNS services, and maintain the security of user communications. [Overview of the project] [Means for solving the problem]

[0043] The present invention proposes different methods for implementing DNS traffic from a DNS client in different entities, enabling secure redirection of traffic from a first name resolution server to a second name resolution server, provided that the redirection procedure is enabled and authorized for that DNS client.

[0044] It should be noted that multiple DNS clients may be enabled on the same device. In this case, the solutions described below can be implemented independently for each DNS client that you wish to enable. Nevertheless, the terms “DNS client” and “device” will be used interchangeably from now on.

[0045] Therefore, the present invention relates to a name resolution method implemented in a terminal connected to a communication network, For example, the steps include sending a name resolution message to the first name resolution server via a secure communication channel between the terminal and the first name resolution server, relying on an application layer protocol (such as HTTPS) or a transport layer protocol (such as QUIC / UDP), If the redirection of DNS traffic for the terminal is authorized (for example, authorized by default for the terminal or authorized by a separate entity such as an authorization server), the steps include obtaining the identifier of at least one second name resolution server for the redirection, For managing the redirection of the DNS traffic of the terminal to the aforementioned second name resolution server, at least, The step of verifying the legitimacy of the second name resolution server, A step of sending a notification of a connection failure between the terminal and the second name resolution server, A step of requesting the invalidation of the redirection of the DNS traffic to the second name resolution server, One of these steps involves performing at least one action, It provides a name resolution method, including the following.

[0046] Therefore, the proposed solution can implement various actions to overcome the authentication problem of the second name resolution server, such as a procedure to verify the legitimacy of the second name resolution server following or simultaneously with obtaining one or more identifiers of the second name resolution server (for example, a procedure to generate at least one new identifier for the second name resolution server), and a procedure to disable redirection.

[0047] Therefore, the proposed solution provides a solution for maintaining the continuity of services that rely on the security of DNS services and / or communications.

[0048] In particular, such administrative actions may be specified in the header or body of the name resolution message sent by the terminal. In this way, upon receiving the name resolution message, the first server can determine the steps to implement.

[0049] For example, a DoH fetch (fwd-check) or DoH POST (fwd-check) type name resolution message may be sent to initiate an action such as verifying the legitimacy of a second name resolution server. A DoH fetch (redirect authorization failed) or DoH POST (redirect authorization failed) type name resolution message may be sent to initiate an action such as sending a notification of connection failure between the terminal and the second name resolution server. A DoH fetch (redirect disabled) or POST (redirect disabled) type name resolution message may be sent to initiate an action such as requesting the disabling of the redirection of DNS traffic to the second name resolution server. In particular, a notification of connection failure between the terminal and the second name resolution server may include an explicit notification of connection failure or a notification to generate a new identifier.

[0050] In particular, the second server may be added to the list of authorized ("accepted") servers for the DNS traffic redirection service. The terminal then proceeds with the transition from an insecure to a secure connection with this second server, redirecting DNS traffic to this second server using a secure communication channel. If the legitimacy verification of the second server fails, it is possible to suppress (or not add) this second server to the list of authorized servers. This redirection to the second server may be disabled by the terminal.

[0051] For example, the at least one identifier of the second name resolution server belongs to a group that includes a domain name that identifies the second server, an address for joining the second server, and so on.

[0052] As previously shown, actions that manage the redirection of DNS traffic from a terminal include, for example, sending a notification of a connection failure between the terminal and the second name resolution server. For example, such an action may then yield a new identifier for the second name resolution server.

[0053] In this way, if the terminal fails to authenticate with the second name resolution server, an action can be triggered that allows it to obtain a new identifier from the second server.

[0054] Another action to manage DNS traffic redirection is to verify the legitimacy of a second name resolution server. For example, such an action could be: The steps include receiving at least one piece of information originating from the first name resolution server for verifying the legitimacy of the second name resolution server, A step of verifying the legitimacy of the entity that initiated the response by comparing a response to a name resolution request initiated by the terminal using at least one identifier of the second server and generated from the at least one piece of verification information with a test response obtained from the at least one piece of verification information, It includes.

[0055] Another action to manage the redirection of DNS traffic from a device is a request to disable the redirection of DNS traffic to the second name resolution server. In particular, such an action may be performed after another action, for example, if the validity verification of the second server fails despite at least one new identifier being generated for the second server, or after the device's connection to the second server has failed one or more times.

[0056] The present invention also relates to a method for controlling the redirection of authorized DNS traffic to a terminal in a communication network, wherein the terminal sends a name resolution message via a secure communication channel between the terminal and a first name resolution server.

[0057] This type of control method is implemented in a network controller, also known as an orchestrator. A step of exchanging information with a second name resolution server identified for the terminal for the authorized redirection of the terminal's DNS traffic, including at least one piece of information provided by the controller to the second name resolution server by the terminal to verify the legitimacy of the second name resolution server, and / or at least one piece of information provided by the second name resolution server to the controller for resolving connection failures between the terminal and the second name resolution server. Includes.

[0058] In particular, such control methods may be implemented to assist the terminal in performing actions to manage the redirection of DNS traffic, especially actions such as sending notifications of connection failures between the terminal and the second name resolution server, or actions such as verifying the legitimacy of the second name resolution server.

[0059] The first name resolution server and network controller may form the same entity or belong to separate entities. In this second case, the first name resolution server and network controller may exchange messages to communicate.

[0060] In particular, if the second server is the default router (such as a CPE) defined for the communication network, such a controller may have at least one identifier for the second name resolution server. Alternatively, the controller implements obtaining at least one identifier for the second name resolution server from the network's authorization server.

[0061] According to a particular embodiment, at least one of the pieces of information provided by the second name resolution server to resolve a connection failure between the terminal and the second name resolution server includes at least one new identifier of the second name resolution server.

[0062] Alternatively, a method implemented by the controller includes the step of obtaining at least one new identifier for the second name resolution server from the default router defined for the communication network.

[0063] In either case, the controller can send the at least one new identifier to the network's authorization server.

[0064] In particular, such actions may be implemented when the terminal performs actions to manage terminal redirection, such as sending an instruction that the connection to the second name resolution server has failed.

[0065] According to a particular embodiment, the method performed by the controller includes, during information exchange, sending to the second name resolution server at least one identifier of the terminal that has the authority to verify the legitimacy of the second name resolution server, or at least one identifier of the network to which the terminal belongs.

[0066] In particular, such actions may be implemented when a terminal performs actions such as verifying the legitimacy of a second server.

[0067] In this way, the controller can notify the second name resolution server of terminals that have the authority to verify the legitimacy of the second name resolution server.

[0068] For example, at least one identifier of a terminal belongs to a group that includes an IPv4 / IPv6 address, an IPv4 / IPv6 prefix, the DNS-ID identifier of the terminal's certificate, or other identifiers entered in the "Subject Alternative Name" field of the certificate (as described in the document "Internet X.509 Public Key Infrastructure Certificates and Certificate Revocation List (CRL) Profiles," D. Cooper et al., May 2008).

[0069] The present invention also relates to a method for managing permitted DNS traffic redirection for a terminal in a communication network, wherein the terminal sends a name resolution message via a secure communication channel between the terminal and a first name resolution server.

[0070] Such a management method is implemented in the second name resolution server of the network, which is identified for the redirect terminal. The process includes exchanging information with the network controller, which includes at least one piece of information provided from the controller to the second name resolution server for the terminal to verify the legitimacy of the second name resolution server, and / or at least one piece of information provided from the second name resolution server to the controller for resolving connection failures between the terminal and the second name resolution server.

[0071] In particular, such management methods may be implemented to assist devices in performing actions to manage the redirection of DNS traffic.

[0072] In particular, the management method includes the step of sending a response to a name resolution request to the terminal, wherein the response carries a test response obtained from at least one identifier of the terminal, and the at least one piece of information for verifying the legitimacy of the second name resolution server is obtained during exchange with the controller.

[0073] In particular, the name resolution request may be a test request generated from the at least one piece of verification information.

[0074] In particular, such actions may be implemented when a terminal performs actions such as verifying the legitimacy of a second server.

[0075] According to another embodiment, the control method is: The steps include generating at least one new identifier for the second name resolution server, The steps include: transmitting the at least one new identifier to the network controller during the exchange with the controller; Includes.

[0076] In particular, such actions may be implemented when a terminal performs actions to manage terminal redirection, such as sending notifications of connection failures between the terminal and the second name resolution server.

[0077] The present invention also relates to a method for handling the redirection of authorized DNS traffic for a terminal within a communication network, wherein the method is implemented on a first name resolution server of the network. The steps include receiving a name resolution message from the terminal via a secure communication channel between the terminal and the first name resolution server, Steps include obtaining from the authorization server the redirect authorization for the terminal and at least one identifier of a second name resolution server identified for the terminal for the redirect, The steps include sending a redirect message to the terminal having at least one identifier of the second name resolution server, Includes.

[0078] The first name resolution server communicates with terminals via a secure communication channel, communicates with an authorization server that can communicate with the network controller, and can itself communicate with a second name resolution server. The first name resolution server and the authorization server may form the same entity or belong to different entities. In this second case, the first name resolution server and the authorization server can communicate by exchanging messages.

[0079] For example, if the first name resolution server and the authorization server belong to different entities, the steps of obtaining redirect authorization for the terminal and at least one identifier of the second name resolution server name identified for the terminal are: The steps include sending a redirect authorization confirmation request to the authorization server having at least one identifier of the terminal, The steps include receiving a redirect authorization for the terminal from the authorization server and at least one identifier of the second name resolution server identified for the redirect terminal, Execute this.

[0080] According to the first embodiment, the first name resolution server is A step of obtaining at least one piece of information (originating from the authorization server or generated by the first name resolution server) to verify the legitimacy of the second name resolution server, The steps include transmitting the at least one piece of verification information to the terminal, Execute this.

[0081] In particular, such steps may be implemented when a terminal performs actions such as verifying the legitimacy of a second server, ensuring that the first server can obtain at least one piece of verification information.

[0082] According to the first modification, the step of obtaining at least one piece of verification information includes generating at least one verification test by a first name resolution server and sending the at least one verification test to the authorization server.

[0083] Therefore, the first server generates at least one validation test (e.g., generates a domain name and associated DNS entry) and sends the test to the authorization server on the one hand (e.g., a redirect authorization confirmation request or "accounting request" message) and to the terminal on the other hand (e.g., a "DoH3xx" redirect message).

[0084] According to the second modification, the reception of at least one verification test originating from the authorization server is performed by obtaining at least one piece of verification information.

[0085] In this case, the first server only sends the test to the terminal (for example, a "DoH3xx" redirect message). Since it generated the test itself, there is no need to send the test to the authorization server.

[0086] According to the second embodiment, the first name resolution server, The steps include obtaining at least one new identifier of the second name resolution server from the authorization server, The steps include sending the at least one new identifier of the second name resolution server to the terminal, Execute this.

[0087] In particular, such a step may be implemented when the terminal performs an action such as sending a notification of a failure in the connection between the terminal and the second name resolution server so that the first server can obtain at least one new identifier of the second name resolution server.

[0088] For example, if the first name resolution server and the authorization server belong to separate entities, the step of obtaining at least one new identifier of the second name resolution server is: The steps include sending a request to the authorization server above for generating at least one new identifier for the second name resolution server, The authorization server performs the step of receiving at least one new identifier of the second name resolution server mentioned above from the authorization server.

[0089] If the configuration procedure involves generating at least one new identifier for a second name resolution server, the first server can obtain the at least one new identifier for the second name resolution server by contacting the authorization server by sending a request to generate at least one new identifier. For example, such a request may be sent in a redirect authorization confirmation request or an "account request" message.

[0090] Therefore, the first server may receive at least one new identifier from the second server and send it to the terminal (for example, a "DoH3xx" redirect message).

[0091] According to another embodiment, the first name resolution server may, following at least one failure of the connection between the terminal and the second name resolution described above, proceed to disable DNS traffic redirection to the second name resolution server, or to disable DNS traffic redirection to a third name resolution server designated by default at the request of the terminal.

[0092] In particular, such a step may be performed if the terminal performs an action such as requesting the disabling of redirection to the second name resolution server for DNS traffic.

[0093] Redirection disabling can also be implemented upon terminal request. In particular, redirection disabling may be determined after N authentication failures (e.g., by the terminal or the first server), where N is an integer greater than or equal to 1, for example, 3.

[0094] In particular, the first name resolution server may disable DNS traffic redirection to the default name resolution server (the third name resolution server), and therefore may not be specified by the authorization server.

[0095] According to the first variation, the first server requests authorization from the authorization server before proceeding with disabling the redirect. For example, the first name resolution server, The steps include sending a request to the authorization server to disable the redirection to the second name resolution server, The steps include receiving an invalidation authorization sent from the authorization server, Execute this.

[0096] According to the second modification, the first server decides to disable the redirection to the second server and notifies the authorization server. For example, the first name resolution server, The step of sending information to the authorization server that redirection is disabled for the second name resolution server, Execute this.

[0097] The present invention also relates to a method for authorizing the redirection of DNS traffic of a terminal in a communication network, the method being implemented on an authorization server of the network, the terminal sending a name resolution message over a secure communication channel between the terminal and a first name resolution server.

[0098] This authorization method is permitted when redirection of the device's DNS traffic is authorized. The steps include obtaining at least one identifier of a second name resolution server identified for the terminal for the purpose of the redirect, The steps include sending a redirect authorization to the first name resolution server for at least one identifier of the terminal and the second name resolution server, Includes.

[0099] In particular, using such authorization servers can improve the reliability of various procedures / actions, especially for verifying the legitimacy of a second server or for resolving authentication issues.

[0100] In particular, such a step is performed following the receipt of a redirect authorization confirmation request originating from the first name resolution server.

[0101] According to a particular embodiment, such authorization method involves the network controller, At least one identifier of the aforementioned terminal, At least one identifier of the network to which the terminal belongs, The at least one identifier of the preceding second name resolution server, At least one piece of information to verify the legitimacy of the second name resolution server, The process includes the step of sending at least one element belonging to a group that includes [the specified element].

[0102] In particular, the authorization method may implement the acquisition of at least one piece of information to verify the legitimacy of the second name resolution server before transmitting the aforementioned information in order to verify the legitimacy of the controller.

[0103] In particular, this step can be implemented when a terminal performs an action such as verifying the legitimacy of a second name resolution server. This allows the authorization server to obtain at least one piece of information to verify the legitimacy of the said second name resolution server.

[0104] For example, the step of obtaining at least one piece of verification information involves performing the step of receiving at least one verification test (generation of a test request by the first name resolution server) from the first name resolution server. Alternatively, the step of obtaining at least one piece of verification information involves the generation of at least one verification test by the authorization server and the sending of at least one verification test (generation of a test request by the authorization server) to the first name resolution server.

[0105] According to another embodiment, the authorization method is: The steps include obtaining at least one new identifier of the second name resolution server from the network controller, The steps include sending the first name resolution server the at least one new identifier of the second name resolution server, Includes.

[0106] In particular, such a step may be performed if the terminal takes action such as sending a notification of connection failure between the terminal and the second name resolution server, so that the authorization server can obtain at least one new identifier of the second name resolution server.

[0107] In other embodiments, the present invention also relates to a corresponding terminal, a network controller, a name resolution server, a second name resolution server, and a corresponding authorization server.

[0108] Some of these entities may form the same entity (for example, the first name resolution server and / or authorization server and / or controller may be jointly installed). In this case, various modules (for example, a module associated with the first name resolution server, a module associated with the authorization server, and a module associated with the network controller) may communicate within the same entity, for example, by exchanging messages.

[0109] Furthermore, the present invention relates to a system for redirecting DNS traffic in a communication network including a terminal, a network controller, a first name resolution server, a second name resolution server, and a corresponding authorization server.

[0110] In another embodiment, the present invention relates to one or more computer programs that, when executed by a processor, include instructions for implementing at least one method according to at least one embodiment of the present invention.

[0111] Therefore, the method according to the present invention may be implemented in various forms, particularly in wired and / or software form.

[0112] In particular, some steps may be implemented by common modules, applications, and DNS resolvers ("resolvers" or "stub resolvers"). These various modules may be embedded in CPEs, terminals ("user devices"), keys equipped with, for example, USB ports ("(USB) dongles").

[0113] Other features and advantages of the present invention will become clearer from reading the following description of specific embodiments given as simple, illustrative, and non-limiting examples, and from the accompanying figures. [Brief explanation of the drawing]

[0114] [Figure 1A] This figure shows an example of deploying a DNS service without a relay ("DNS forwarder") embedded in the CPE, as explained in relation to conventional technologies. [Figure 1B] This figure shows an example of deploying a DNS service using a DNS relay embedded in a CPE, as described in relation to the conventional technology. [Figure 1C] This figure shows an example of establishing a connection with a remote server, as explained in relation to conventional technology. [Figure 2] This figure shows an example of DNS request interception by a malicious device, as explained in relation to conventional technology. [Figure 3] This diagram shows the procedure for automatically updating DNS connections using conventional technology. [Figure 4A] This figure illustrates, in relation to prior art, an example of a problem encountered during the procedure to automatically update a Do53 connection to an encrypted DNS connection according to prior art. [Figure 4B] This figure illustrates, in relation to prior art, an example of a problem encountered during the procedure to automatically update a Do53 connection to an encrypted DNS connection according to prior art. [Figure 5A] This figure shows the main steps implemented for managing DNS traffic redirection according to at least one embodiment of the present invention. [Figure 5B] This figure shows the main steps implemented for managing DNS traffic redirection according to at least one embodiment of the present invention. [Figure 5C] This figure shows the main steps implemented for managing DNS traffic redirection according to at least one embodiment of the present invention. [Figure 5D]This figure shows the main steps implemented for managing DNS traffic redirection according to at least one embodiment of the present invention. [Figure 5E] This figure shows the main steps implemented for managing DNS traffic redirection according to at least one embodiment of the present invention. [Figure 6] This diagram shows examples of messages exchanged between a terminal, a name resolution server, and an authorization server. [Figure 7A] This figure shows an example of messages exchanged between a terminal, a name resolution server, and an authorization server according to the first embodiment. [Figure 7B] This figure shows an example of messages exchanged between a terminal, a name resolution server, and an authorization server according to the first embodiment. [Figure 8] This figure shows various entities involved in traffic redirection according to at least one embodiment of the present invention. [Figure 9A] This figure shows an example of messages exchanged between a terminal, a first name resolution server, and an authorization server according to the second embodiment. [Figure 9B] This figure shows an example of messages exchanged between a terminal, a first name resolution server, and an authorization server according to the second embodiment. [Figure 10A] This figure shows an example of messages exchanged between a terminal, a name resolution server, and an authorization server to invalidate a traffic redirection procedure, according to at least one embodiment of the present invention. [Figure 10B] This figure shows an example of messages exchanged between a terminal, a first name resolution server, and an authorization server for disabling a traffic redirection procedure according to at least one embodiment of the present invention. [Figure 11] This figure shows a simplified structure of different entities according to a specific embodiment. [Modes for carrying out the invention]

[0115] general principles This invention proposes a secure solution for managing the redirection of a terminal's DNS traffic from a first name resolution server to a second name resolution server identified for the terminal for redirection purposes.

[0116] To accomplish this, it is assumed that the device can use a secure channel to send a name resolution request to a first name resolution server, and that the first name resolution server would like to set up a procedure to redirect the DNS traffic to a second name resolution server identified for the device for redirection.

[0117] The general principle of the present invention is based on the performance of at least one action by a terminal to manage the redirection of the terminal's DNS traffic to a second server identified for the terminal for redirection purposes. For example, such an action may consist of verifying the legitimacy of the second name resolution server, sending a notification of connection failure between the terminal and the second name resolution server, and requesting the invalidation of DNS traffic redirection to the second name resolution server.

[0118] Therefore, the proposed solution can detect, circumvent, and / or correct the identity usurpation or authentication issues described with reference to Figures 4A and 4B. This could prevent the device from accessing services that rely on DNS services (specifically encrypted DNS services ("encrypted DNS")).

[0119] Referring to Figures 5A to 5F, the main steps implemented according to the present invention are shown in a system including a terminal 51, a first name resolution server 52, an authorization server 53, a network 54, and a second name resolution server 55.

[0120] For example, the local area network is thought to be connected to the operator's network by a router, such as a CPE, the first name resolution server 52 belongs to the operator's network, and the terminal 51 belongs to the local area network.

[0121] Of course, other scenarios may also be considered. For example, the first name resolution server is a legitimate server within the operator's network and redirects DNS traffic to at least one second name resolution server within the operator's network or to another network closer to the terminal.

[0122] Therefore, the terminal and the second name resolution server do not necessarily need to be connected to the same network, and redirection is not necessarily implemented on a server in the local area network. Similarly, the first name resolution server may be connected to a different network than the access network.

[0123] Therefore, the “communication network” should next be understood as a set of one or more networks to which the terminal 51, the first name resolution server 52, and the second name resolution server 55 are connected. Other entities that may intervene in the management of DNS traffic redirection may also be connected to this network or these networks, in particular to authorization servers 53, which in particular can verify whether a redirection is authorized for the terminal, and possibly to network controllers 54. Each of these entities may be connected to a network other than the communication network. Nevertheless, different entities may communicate with each other in pairs or more.

[0124] As shown in Figure 5A, during step 511, terminal 51 sends at least one name resolution message to the first name resolution server 52 via a secure communication channel between terminal 51 and the first name resolution server 52.

[0125] If redirection of DNS traffic is permitted for the terminal, terminal 51 obtains, for redirection purposes, the identifier of at least one legitimate second name resolution server 55 (e.g., authorization server 53 or network controller 54) originating from the first name resolution server 52 or an entity that communicates directly or indirectly with the first name resolution server 52 (512).

[0126] Next, terminal 51, at least - Verify the legitimacy of the second name resolution server. - Send a notification of connection failure between the terminal and the second name resolution server. - Request to disable the redirection of DNS traffic to the second name resolution server. From among these, at least one action can be performed (513) to manage the redirection of the terminal's DNS traffic to the second name resolution server 55.

[0127] In particular, in order to verify the legitimacy of the second name resolution server, terminal 51 may, as described later, send a name resolution request (i.e., name resolution of the second server if its ID has not been intercepted by another entity) to the entity identified by the at least one identifier contained in the redirect message.

[0128] As shown in Figure 5B, if redirection of the terminal's DNS traffic is authorized, the network controller 54 can exchange information (541) with a second name resolution server 55 identified for the terminal for authorized redirection of the terminal's DNS traffic, in particular to assist in performing DNS traffic redirection management operations for the terminal 51.

[0129] For example, the control unit 54 may provide the second name resolution server 55 with at least one piece of information for the terminal 51 to verify the legitimacy of the second name resolution server 55. Furthermore, the controller 54 may obtain from the second name resolution server at least one piece of information for resolving connection failures between the terminal and the second name resolution server, such as a new identifier for the second name resolution server.

[0130] Similarly, if redirection of DNS traffic from the terminal is authorized, the second name resolution server 55 shown in Figure 5C can exchange information with the network controller 54 (551) to assist the terminal 51 in performing DNS traffic redirection management actions.

[0131] For example, the second name resolution server 55 may obtain at least one piece of information from the control unit 54 for the terminal 51 to verify the legitimacy of the second name resolution server 55. The second name resolution server 55 may also provide the network controller 54 with at least one piece of information to resolve connection failures between the terminal and the second name resolution server.

[0132] Figure 5D shows the main steps implemented in the first name resolution server 52.

[0133] As shown in Figure 5D, when the first name resolution server 52 receives a name resolution message from terminal 51, it can verify whether the redirection of the terminal's DNS traffic is authorized, for example, by querying the authorization server 53. The authorization server 53 can also communicate with the network controller 54.

[0134] For example, the first name resolution server 52 may send a redirect-type service authorization verification request to the authorization server 53 that includes at least the identifier of the terminal 51 or the identifier of the network to which the terminal 51 is connected.

[0135] This section describes the case where the service is redirect-based. In other embodiments, the authorization server can verify whether the terminal is authorized to use the DNS profile identified in the name resolution message. In fact, multiple DoH profiles (identified in the “URI template”) may be supported by the same name resolution server. Each of these profiles may be configured to provide different DNS services (with or without filtering and anti-spam enabled, etc.).

[0136] Therefore, the first name resolution server 52 can obtain permission for redirection to the terminal and at least one identifier of a second legitimate name resolution server identified for the terminal 51 for redirection (522), and send a redirection message to the terminal 51 containing the said at least one identifier of the second legitimate name resolution server (523).

[0137] As shown in Figure 5E, the authorization server 53 can obtain at least one identifier (531) from a legitimate second name resolution server 55 that identifies the terminal 51 for redirection, in particular when it receives a redirection-type service authorization verification request from, for example, the first resolution server 52.

[0138] In particular, after verification based on the terminal identifier and local instructions (i.e., instructions from the authorization server operator, such as a default redirect or a specific identifier), the authorization server 53 obtains, if applicable, at least one identifier of a second name resolution server 55 associated with terminal 51, identified from the terminal identifier (531).

[0139] Subsequently, the authorization server 53 can send a redirect authorization for terminal 51 and at least one identifier of the second name resolution server 55 to the first name resolution server 52 (532).

[0140] As shown above, these different entities can assist terminal 51 in performing at least one action to manage the redirection of terminal DNS traffic to the second name resolution server 55.

[0141] The first embodiment is described below. According to this embodiment, the DNS traffic redirection management action consists of verifying the legitimacy of the second name resolution server.

[0142] According to this first embodiment, the present invention proposes a solution that can detect whether an entity indicating to be a second name resolution server 55 is malicious. In particular, if the presence of a malicious entity is confirmed, traffic redirection may be interrupted. For this purpose, a test procedure may be implemented.

[0143] For example, according to this first embodiment, performing an action to verify the legitimacy of the second name resolution server includes sending a notification from terminal 51 to the first name resolution server 52 requesting verification of the legitimacy of the second name resolution server. For example, such a notification may be inserted into the body or header of a name resolution message sent from terminal 51 to the first name resolution server 52 during step 511, or it may be inserted into a separate message.

[0144] Upon receiving a notification requesting verification of the legitimacy of the second name resolution server, the first name resolution server 52 generates at least one piece of information to verify the legitimacy of the second name resolution server, or requests the authorization server 53 to obtain such information.

[0145] Therefore, the first name resolution server 52 can, for example, send information to the terminal 51 in a redirect message to verify the legitimacy of the second name resolution server.

[0146] Furthermore, if the first name resolution server 52 is generating information to verify the legitimacy of the second name resolution server, this information may be sent to the authorization server 53, then from the authorization server 53 to the network controller 54, and then from the network controller 54 to the legitimate second name resolution server 55.

[0147] When the first name resolution server 52 receives information from the authorization server 53 to verify the legitimacy of the second name resolution server, this information is sent directly from the authorization server 53 to the network controller 54, and then from the network controller 54 to the legitimate second name resolution server 55.

[0148] Alternatively, the first name resolution server can also communicate directly with the legitimate second name resolution server 55.

[0149] Therefore, terminal 51 and the legitimate second name resolution server 55 will have the same information for verifying the legitimacy of the second name resolution server. For example, such information may include one or more verification tests formed by at least one DNS request and its corresponding response.

[0150] Therefore, terminal 51 can send a test request to the entity identified from the redirect message, which is constructed from the validation tests included in the redirect message.

[0151] Next, terminal 51 can verify the legitimacy of the entity identified from the redirect message by comparing the response received from this entity with the test response obtained by terminal 51 from the validation test included in the redirect message.

[0152] In particular, if no response is received by terminal 51, or if a response is provided but the verification information does not correspond to the response communicated by the first name resolution server 52, terminal 51 can conclude that the entity identified from the redirect message and claiming to be the second name resolution server 55 is malicious.

[0153] Furthermore, the network controller 54 may obtain the identifier of the terminal 51 from the authorization server 53 in advance and send it to the legitimate second name resolution server 55.

[0154] Therefore, upon receiving a name resolution request, the legitimate second name resolution server 55 can verify whether at least one identifier of the entity that issued the name resolution request is identical to or correlated with the identifier of the terminal that sent the name resolution message.

[0155] In this specification, correlated identifiers should be understood as identifiers that are related by a dependency (e.g., an identifier and its encoded version). For example, a second name resolution server would determine that an identifier is correlated if the identifier of the entity making the request is an address formed from a prefix assigned to the terminal (e.g., an IPv6 / 64 prefix).

[0156] Therefore, the legitimate second name resolution server 55 can specifically verify whether the name resolution request used for verification originates from the terminal 51 identified by the network controller 54, and only if the name resolution request originates from the terminal 51 identified by the network controller 54 can it decide not to process the name resolution request (by constructing a response from the verification test).

[0157] The second embodiment is described below. According to this embodiment, the DNS traffic redirection management action consists of sending an instruction that the connection between the terminal and the second name resolution server has failed.

[0158] According to this second embodiment, the present invention proposes a solution that can establish a connection with a second name resolution server 55 after an authentication failure. To do this, a new address may be generated for joining the second name resolution server.

[0159] For example, according to this second embodiment, performing an action such as "sending an instruction that the connection between the terminal and the second name resolution server has failed" includes sending a notification from terminal 51 to the first name resolution server 52 requesting the generation of at least one new identifier from the second name resolution server 55. For example, such a notification may be inserted into the body or header of a name resolution message sent from terminal 51 to the first name resolution server 52 during step 511, or it may be inserted into a separate message. For example, if terminal 51 fails to authenticate with the second name resolution server 55 (authentication failure), such a notification may be sent to the first name resolution server 52.

[0160] In this case, upon receiving a notification from the second name resolution server 55 requesting the generation of at least one new identifier, the first name resolution server 52 can send a request to the authorization server 53 for the second name resolution server to generate at least one new identifier. The authorization server 53 can send the request to the network controller 54, which can then send it to the legitimate second name resolution server 55. Alternatively, the first name resolution server can also communicate directly with the legitimate second name resolution server 55.

[0161] Upon receiving this request, the legitimate second name resolution server 55 can generate at least one new identifier and send that new identifier to the network controller 44. The network controller 54 can forward the new identifiers from the second name resolution server 55 to the authorization server 53, and the authorization server 53 can forward them to the first name resolution server 52. Alternatively, the legitimate second name resolution server 55 can also communicate directly with the first name resolution server.

[0162] The new identifier could be an IP address, but other identifiers (such as a domain name, port number, or certificate) could also be considered.

[0163] The first name resolution server 52 can, for example, send the new identifier of the second name resolution server 55 to the terminal 51 in a redirect message.

[0164] The two embodiments described above can be implemented simultaneously or sequentially.

[0165] Furthermore, it should be noted that the first domain name resolution server, authorization server, and / or network controller may be the same entity or separate entities. Therefore, the functions associated with the first domain name resolution server, authorization server, and / or network controller may be embedded in the same node or separate nodes.

[0166] For example, the DoH protocol is used for communication between terminal 51 and the first name resolution server 52 or the second name resolution server 55. Therefore, terminal 51 is a DoH client.

[0167] In particular, the name resolution message may be a DoH retrieval type message, and the redirection message may be a DoH "3xx" type message (hereinafter referred to as DoH REDIRECT).

[0168] Of course, other protocols can also be used. For example, DNS exchange may rely on protocols such as DoQ.

[0169] In particular, the disclosed traffic redirection method is applied independently of the transport protocol used by the name resolution service. Especially considering IP networks, the transport protocol used for DNS communication can be either IPv4 or IPv6 (depending on the network access conditions in particular).

[0170] Therefore, the proposed solution, depending on the embodiment under consideration, has the following advantages, namely, - To ensure the availability of services provided to clients (especially DNS-based services) and to avoid a decline in the quality of the experience perceived by clients. - To provide a reliable and robust set of name resolution services, while minimizing the changes to existing infrastructure and protocols required to provide such services. - Detect attacks and data interception by malicious devices acting as relays for such attacks within computer networks (domestic or corporate networks). - To enable operators to continue providing value-added services to clients, including enabling a second name resolution server such as a CPE-hosted "DNS forwarder," particularly based on name resolution. - To improve user trust in operators who subscribe to such name resolution services. - Having a limited list of "trusted" authorized servers, It provides at least one of the following.

[0171] Description of a specific embodiment Various implementations of the present invention for managing the redirection of DNS traffic on a terminal are described below. For example, the DoH protocol may be used to encrypt DNS messages so that the terminal and the name resolution server can communicate over a secure channel.

[0172] Next, a "legitimate DNS server" should be understood as a name resolution server declared or configured by an operator and hosted, for example, within an access network, but other servers (e.g., DNS servers operated by third parties) should also be considered.

[0173] Next, it is necessary to understand machines on a communications network that, by "malicious" devices or entities, intercept or publish information that allows for the interception of DNS traffic (for example, a machine that intercepts the identity of a legitimate DNS server, or a machine that intercepts the identity of the default router through which DNS traffic passes).

[0174] Please note that the nature of malicious devices is not considered. These may include, for example, devices installed by users, devices belonging to visitors (such as guests), devices within the coverage area of ​​a WLAN network, or devices used to access the operator's network (CPE).

[0175] For example, a communication network can be a home computer network or a corporate network, also known as a local area network or LAN.

[0176] For example, some services provided to devices connected to a local area network require the activation of a name resolution server ("forwarder DNS") within the local area network. Therefore, access network operators may want to configure DNS traffic redirection procedures. This is the case, for example, with devices such as connected objects or printers.

[0177] For example, this name resolution server, also known as the second name resolution server, is hosted by a CPE associated with at least one network interface between the local area network and the access network, and can be defined as the default router for terminals on the local area network. Other routers can also be introduced into the local area network. For example, a home router different from the CPE can be installed to split LAN traffic into private and professional traffic. Nevertheless, traffic between the local area network and the access network passes through the CPE, and the CPE is considered the default router. Alternatively, the second name resolution server may be another entity connected to the local area network.

[0178] As shown in Figure 6, in order to configure the DNS traffic redirection procedure, terminal 61 sends a name resolution message to the first DoH server 62. For example, such a DoH request is of type DoH GET or DoH POST.

[0179] Upon receiving a DoH request, the first DoH server 62 can interface with the authorization server 63 to obtain instructions that apply when a new connection needs to be established.

[0180] To do so, the first DoH server 62 sends a redirect authorization verification request of type "Access-Request" to the authorization server 63.

[0181] The authorization server 63 can identify a second DoH server in the local area network (e.g., embedded in the CPE) used to redirect traffic from at least one identifier of the terminal, such as its IPv4 address and / or the IPv6 prefix used by the DoH client to initiate the DoH request and / or the DNS identifier (DNS-ID) of the terminal 61's certificate.

[0182] For example, a database of valid clients is used to identify a second DoH server. In particular, operators may keep the list of services and related information up to date.

[0183] Therefore, according to this implementation example, it is assumed that authorization server 63 maintains a list of DoH terminals / clients that are eligible for DNS traffic redirection.

[0184] For example, such an authorization server 63 is a RADIUS server (as described in RFC 2865, “Remote Authentication Dial-In User Service (RADIUS)”, C. Rigney et al., June 2000), and a new RADIUS attribute is defined to identify the second DoH server associated with the DoH client. For example, such an attribute may include the domain name configured for the second DoH server (ADN or “Authentication Domain Name”), at least one address used to reach the second DoH server (such as an internal address) (“Locator”), and possibly an alternate port number for the DoH service (“Port”).

[0185] Therefore, in response to a redirect authorization verification request, authorization server 63 can communicate this different information (domain name, address, alternative port number, etc.) to the first DoH server 62, for example, in an "Access-Accept" type message. In particular, to prevent the DoH client from requesting resolution of this domain name from another server (which may be a malicious server), the address / port number may be conveyed in addition to the domain name in the response.

[0186] In particular, the first DoH server 62 can relay this information to the terminal 61 using the "DoH REDIRECT" message.

[0187] Therefore, terminal 61 can proceed with redirecting DNS requests to a second DoH server (for example, a "DNS forwarder" built into the CPE) and establishing a DoH session with the second DoH server.

[0188] In particular, terminal 61 can take at least one action to manage the redirection of terminal DNS traffic to a second name resolution server, especially if it detects an authentication problem or if it has doubts about the legitimacy of the second DoH server.

[0189] According to the first embodiment described above, the terminal can perform actions such as verifying the legitimacy of the second name resolution server.

[0190] Therefore, during the initialization of traffic redirection, or after configuring the redirection of DNS traffic to a second DoH server, the terminal can continue to verify the legitimacy of the second DoH server. In fact, the terminal may suspect that the entity pretending to be a second DoH server is malicious, and if it is found to be malicious, it may prevent its outgoing DNS requests from being redirected to such an entity.

[0191] In this case, as shown in Figure 7A, terminal 71 may send a notification to the first DoH server 72 requesting verification of the legitimacy of the second DoH server.

[0192] For example, terminal 71 inserts a new object ("fwd-check") into the header of the DoH retrieval resolution message (or the body of the DoH POST message) to indicate to the first DoH server 72 that it wants to set up a procedure to verify the legitimacy of the second DoH server.

[0193] Upon receiving this DoH retrieval (fw-check) request containing the "fwd-check" object, the first DoH server 72 requests the authorization server 73 to verify whether redirection is enabled for this client, for example by sending a redirect authorization verification request of type "Access-Request" as described above. The authorization server 73 may respond by sending an "Access-Accept" type response as described above.

[0194] Furthermore, the first DoH server 72 notifies the authorization server 73 that it will set up a verification procedure in cooperation with the terminal 72. For example, the first DoH server 72 may send at least one piece of information to the authorization server 73 to verify the legitimacy of the second DoH server, for example, in a message of type "Accounting-Request". Thus, the first DoH server 72 may communicate to the authorization server 73 the description of at least one test ("CHECK"), and possibly the deadline ("T") for the terminal 71 to perform the test.

[0195] For example, each test is a unique DNS entry known only to the operator, and therefore only to the first DoH server 72. A test can be defined using its type, DNS request ("check query"), and associated response ("check reply").

[0196] Next, the authorization server 73 sends at least one identifier of terminal 71 and information to verify the legitimacy of the second DoH server (descriptive information for at least one test ("CHECK"), and possibly a deadline ("T") for terminal 71 to perform the test) to the network controller. For example, such a network controller is an Auto-Configuration Server (ACS) for the CWMP protocol.

[0197] For example, information used to verify the legitimacy of the second DoH server is initialized according to YANG semantics.

[0198] An example of the tree structure of the YANG module used by authorization server 73 and network controller is shown in the appendix.

[0199] If the second DoH server is not hosted by a CPE, authorization server 73 also transmits at least one identifier of the second DoH server. Note that if the second DoH server is hosted by a CPE, the network controller can directly obtain the identifier of the second DoH server from readily available information.

[0200] The network controller, also known as the orchestrator, sends information to a legitimate second DoH server to verify the legitimacy of the second DoH server (description of at least one test ("CHECK"), and possibly a deadline ("T") for performing the test).

[0201] The network controller also sends at least one identifier of terminal 71 involved in the verification procedure to a valid second DoH server.

[0202] As shown in Figure 8, the exchange between the authorization server 73 and the network controller 74 may be implemented over a secure communication channel, for example, according to the NETCONF or RESTCONF protocol. The exchange between the network controller 74 and the second DoH server 75 may also be implemented over a secure communication channel, for example, according to the NETCONF or RESTCONF protocol (as described in document RFC8071 ("NETCONF Call Home and RESTCONF Call Home", K. Wasten, February 2017) or TR-069 (CWMP stands for "CPE WAN Management Protocol").

[0203] Similarly, the first DoH server 72 can communicate information to the terminal 71 to verify the legitimacy of the second DoH server, for example, in a DoH REDIRECT redirect message (CHECK, T).

[0204] An example of a JSON object used by the first DoH server 72 to communicate verification information to the terminal 71 is shown in the appendix.

[0205] Compared to the example given in the prior art, such a JSON object therefore describes the tests implemented to verify the legitimacy of the second DoH server, specifically the test type ("check-rrtype"), the test request ("check query"), and the response to the test request ("check reply"). "check-rrtype" indicates the DNS resource type ("resource record type").

[0206] According to the example above, upon receiving this redirect message, after 5 seconds (the deadline defined by "Timer"), terminal 71 sends a test request of type "txt" for the domain name "test47fsgugsdf4zjou.defhiyef.isp" ("check query") using the identifier of the second DoH server received from the first DoH server 72.

[0207] The entity that receives this test request will continue processing the request.

[0208] Once the entity that receives this request constructs a response, it sends it to terminal 71, and this response corresponds to the response ("check response") that was communicated directly by the first DoH server 72, and terminal 71 concludes that this entity is indeed a legitimate second DoH server.

[0209] If the entity receiving this request is malicious (for example, by hijacking the identity of a second DoH server), it may employ several strategies. - Emulate the response and send it to terminal 71. The probability that this response corresponds to one communicated directly by the first DoH server 72 ("check response") is approximately zero. Terminal 71 then detects the mismatch in the received response and assumes that the entity has received a name resolution request. - The request is forwarded to a normal server (i.e., a server configured by the local area network). A negative response is sent because only a legitimate second DoH server has a response. - The request is forwarded to a legitimate second DoH server. The second DoH server verifies whether the name resolution request actually originated from the terminal by sending a denial response based on the terminal identifier received from the network controller (for example, by applying a filter based on at least one terminal identifier). - The request is relayed to another malicious server. A negative response is sent.

[0210] If no response to a test request ("check query") is received by terminal 71, or if a response is provided but does not correspond to one directly communicated by a legitimate first DoH server ("check response"), terminal 71 may then conclude that any entity reachable using the identifier of the second DoH server received from the first DoH server 72 is malicious, and subsequently configure a procedure that enables the local redirection of traffic to be disabled.

[0211] As shown in the modified example in Figure 7B, by default, it is also possible to verify the legitimacy of the second DoH server, for example, when traffic redirection is initialized or when the second DoH server is started.

[0212] In this case, as shown in Figure 7B, upon receiving a name resolution message sent by terminal 71, the first DoH server 72 requests the authorization server 73 to verify whether redirection is enabled for this client, for example by sending a redirect authorization verification request of the "Access Request" type described above. As previously explained, the authorization server 73 may respond by sending an "Access-Accept" type response that includes, for example, at least one piece of information to verify the legitimacy of the second DoH server, such as a description of at least one test ("CHECK").

[0213] The first DoH server 72 can communicate redirect information (such as ADN, LOCATORS, and PORT) and information to verify the legitimacy of the second DoH server to the terminal 71, for example, in a redirect message "DoH REDIRECT (CHECK)".

[0214] If terminal 71 detects an anomaly while executing the verification procedure (or during authentication of the second server described later), terminal 71 can configure a procedure to disable local redirection of traffic.

[0215] According to the second embodiment described above, the terminal can also perform actions such as sending an instruction indicating that the terminal's connection to the second name resolution server has failed.

[0216] For example, during the initialization of traffic redirection, the terminal might detect that the authentication procedure for the second DoH server failed. In this case, a connection cannot be established between the terminal and the second DoH server. Therefore, there are no services available locally on the terminal.

[0217] This second embodiment may be implemented following the first embodiment, for example, after the terminal issues a name resolution request. In particular, authentication failure may be caused by the presence of a malicious server that intercepts the identity (such as an IP address) of the second DoH server.

[0218] In this case, as shown in Figures 9A and 9B, terminal 91 can send a notification to the first DoH server 92 requesting the generation of at least one new identifier for the second name resolution server.

[0219] For example, terminal 91 inserts a new object ("Redirect authorization failed") into the header of the DoH retrieval resolution message (or the body of the DoH POST message) to indicate to the first DoH server 92 that authentication for the second DoH server failed and that it wants to set up a procedure to verify the identity of the second DoH server.

[0220] After receiving this DoH GET (Redirect Authentication Authorization Failure) request containing a "Redirect Authorization Failure" object, the first DoH server 92 sends a request to the authorization server 93 to generate at least one new identifier for the second name resolution server and notify it that it wants to set up a procedure to add a new address to join the second name resolution server. For example, such a request is an "Accounting-Request" message containing a new "AddressAdd" attribute.

[0221] The authorization server 93 sends a request to the network controller to generate at least one new identifier for a second name resolution server. If the second DoH server is hosted on the default router defined for the network (e.g., CPE), the network controller sends it to the legitimate second DoH server; otherwise, it sends it to the default router. Upon receiving this request, the default router (which may be the legitimate second DoH server) may generate at least one new address (particularly one used locally for DNS services).

[0222] In particular, the network controller informs the default router (which may be a legitimate second DoH server) that this address should only be advertised to identified terminals.

[0223] For example, an exchange between authorization server 93 and network controller for providing a new identifier for a second DoH server used by the DNS service and not announced on the LAN may be initialized according to YANG semantics.

[0224] An example of the structure of a YANG module used for this purpose is disclosed in the appendix.

[0225] As described in this module, one or more new identifiers ("new addresses") may be generated by the default router. The type of action is indicated by the "type" attribute.

[0226] Subsequently, the new identifiers are sent to the network controller, which then sends them to the authorization server 93. For example, as shown in Figure 8, the exchange between the authorization server 93 and the network controller can be implemented over a secure communication channel, for example, according to the NETCONF or RESTCONF protocol. Similarly, the exchange between the controller network and the second DoH server or default router can be implemented over a secure communication channel, for example, according to the NETCONF, RESTCONF, or TR-069 protocol.

[0227] The new domain name AND' may be configured by authorization server 93 for the second DoH server, associated with a new identifier (LOC') used to join the second DoH server. Authentication certificates may be created. Other information (such as the "URI template") may also be changed.

[0228] According to the first modified example shown in Figure 9A, the first DoH server 92, following the receipt of the DoH Acquisition (Redirect Authorization Failure) request, sends an "Accounting-Request" request to the authorization server 93 requesting the generation of at least one new identifier for the second name resolution server.

[0229] Furthermore, as mentioned above, the first DoH server 92 sends a redirect authorization verification request of type "Access-Request" to the authorization server 93.

[0230] The authorization server 93 may send new information (such as a new domain name ADN', a new identifier LOC' for the second DoH server, etc.) to the first DoH server 92 in the aforementioned "Access-Accept" type response.

[0231] According to the second modified example shown in Figure 9B, when the first DoH server 92 receives a DoH acquisition (redirect authentication authorization failure) request, it sends the aforementioned "Access-Request" type redirect authorization verification request to the authorization server 93.

[0232] The authorization server 93 can respond by sending an "Access-Accept" type response, as previously described with reference to Figures 6 and 7.

[0233] Next, the first DoH server 92 can send an "account request" request to the authorization server 93, which requests the second name resolution server to generate at least one new identifier.

[0234] The authorization server 93 can respond, for example, to an authorization change request (CoA, "authorization change") by sending new information (ADN', LOC', etc.) to the first DoH server 92.

[0235] Once these exchanges are complete (according to the first or second variation, or other variations that allow the first DoH server 92 to obtain new information (ADN', LOC', etc.)), the new redirect information (AND', LOC', etc.) is transmitted to terminal 91, for example, in a redirect message DoH REDIRECT.

[0236] An example of a JSON object used by the first DoH server 92 to communicate new redirect information to terminal 91 is shown in the appendix.

[0237] Therefore, compared to the example given in the prior art, such a JSON object describes a new address used to communicate with the second DoH server.

[0238] As in the example above, upon receiving this redirect message, terminal 91 can use the new domain name ADN' to initiate a name resolution request using the new identifier of the second DoH server received from the first DoH server 92, i.e., the new address "192.0.2.5" or "2001:db8::5".

[0239] If no connection problems occurred on terminal 91 when establishing the connection, no further action is required.

[0240] Otherwise, terminal 91 can re-establish a connection with the operator's DNS server (first DoH server 92) and indicate to the first DoH server 92 that the transition (to redirect DNS traffic to the second DoH server) has failed.

[0241] In particular, terminal 91 can configure a procedure to disable local redirection of traffic.

[0242] Therefore, regardless of the embodiment, the terminal can configure a procedure to disable local redirection of traffic if, for example, it detects the presence of a malicious server and / or detects an authentication / connection problem with a second DoH server.

[0243] In this case, as shown in Figures 10A and 10B, terminal 101 may send a notification to the first DoH server 102 requesting the disabling of traffic redirection to the second DoH server.

[0244] For example, terminal 101 inserts a new object ("rd-disable") into the DoH retrieval resolution message to indicate that it wants to configure the first DoH server 102 to disable traffic redirection. Note that such DoH retrieval requests are not processed locally but by the first DoH server provided by the network. Therefore, these exchanges cannot be intercepted by a malicious local server.

[0245] Upon receiving this DoH acquisition (rd-disable) request, the first DoH server 102 contacts the authorization server 103 to request authorization before proceeding with the redirection disablement, or to notify the terminal 101 of the redirection disablement.

[0246] According to the first modified example shown in Figure 10A, the first DoH server 102 requests authorization from the authorization server 103, for example, with an "Access-Request" message, before proceeding with the deactivation.

[0247] The authorization server 103 can respond by sending a message of type "Access-Accept" that includes the new STATUS attribute.

[0248] According to the second variation shown in Figure 10B, the first DoH server 102 notifies the authorization server 103, for example in an "Accounting-Request" message, of the invalidation of traffic redirection to terminal 101.

[0249] In the various embodiments / modifications described above, authorization servers 53, 63, 73, 93, and 103 may be RADIUS servers.

[0250] For example, the format of the new RADIUS attribute is as follows:

[0251] [Table 1]

[0252] An example implementation described above is one where the legitimate second name resolution server is the default router (such as a CPE) defined for the local area network.

[0253] Of course, this is just one example, but a second name resolution server could be embedded in a terminal, key, etc., of the local area network, potentially enabling connection sharing to access a user-configured local area network using the default router's ID and a list of legitimate DNS servers (especially the first name resolution server).

[0254] Furthermore, please note that the above procedures may be enabled / disabled by users or administrators of the local area network entity. In particular, the mechanism for requesting enable or disable may be performed during CPE configuration, while connecting to the CPE management interface, or through notifications sent by the operator.

[0255] Simplified structure of various entities Finally, referring to Figure 11, a simplified structure of an entity, such as a terminal, a first name resolution server, a second name resolution server, an authorization server, or a network controller, according to at least one embodiment described above.

[0256] As shown in Figure 11, such an entity comprises at least one memory 111 including a buffer memory, and at least one processing unit 112, for example, a programmable computer or dedicated computer, for example, a processor P, controlled by a computer program 113, and performs a step of at least one method according to at least one embodiment of the present invention.

[0257] During initialization, the code instructions of the computer program 113 are loaded into RAM memory, for example, before being executed by the processor of the processing unit 112.

[0258] When the entity is a terminal, the processor of the processing unit 112 executes the steps of the aforementioned name resolution method in accordance with the instructions of the computer program 113 to transmit a name resolution message to a first name resolution server via a secure communication channel between said terminal and said first name resolution server; obtain at least one identifier of a redirected second name resolution server; to manage the redirection of the DNS traffic of the terminal to the second name resolution server, at least: verifying the validity of the second name resolution server, transmitting a notification of connection failure between the terminal and the second name resolution server, requesting the invalidation of the redirection of the DNS traffic to the second name resolution server, executing at least one action among: .

[0259] When the entity is a first name resolution server, the processor of the processing unit 112 implements the steps of the aforementioned method for processing authorized DNS traffic redirection for terminals in accordance with the instructions of the computer program 113, to: receive a name resolution message from the terminal via a secure communication channel between said terminal and said first name resolution server; obtain, from an authorization server, the redirection authorization for the terminal and at least one identifier of a second name resolution server identified for the terminal for the redirection; transmit a redirection message comprising at least one identifier of the second name resolution server to the terminal; .

[0260] If the entity is a second name resolution server, the processor of the processing unit 112 performs the steps of the aforementioned method for managing the redirection of authorized DNS traffic to the terminal, in accordance with the instructions of the computer program 113. A step of exchanging information with the network controller, including at least one piece of information provided from the controller to the second name resolution server for the terminal to verify the legitimacy of the second name resolution server, and / or at least one piece of information provided from the second name resolution server to the controller for resolving connection failures between the terminal and the second name resolution server. Execute this.

[0261] If the entity is an authorization server, the processor of the processing unit 112 performs the steps of the aforementioned method for authorizing the redirection of DNS traffic for the terminal, in accordance with the instructions of the computer program 113. The steps include obtaining at least one identifier of a second name resolution server identified for the terminal for the purpose of the redirect, The steps include sending a redirect authorization for the terminal and at least one identifier of the second name resolution server to the first name resolution server, Execute this.

[0262] If the entity is a network controller, the processor of the processing unit 112 performs the steps of the aforementioned method for controlling the redirection of authorized DNS traffic to a terminal, in accordance with the instructions of the computer program 113. Steps to exchange information with a second name resolution server identified for the terminal for the authorized redirection of the terminal's DNS traffic, including at least one piece of information provided by the controller to the second name resolution server by the terminal to verify the legitimacy of the second name resolution server, and / or at least one piece of information provided by the second name resolution server to the controller for resolving connection failures between the terminal and the second name resolution server. Execute this.

[0263] appendix An example of a JSON object returned by the operator's DOH server 32 is as follows:

[0264] [Table 2]

[0265] The following is an example of the tree structure of the Yang module used by authorization server 73 and the network controller.

[0266] [Table 3]

[0267] The following are 27 examples of JSON objects used by the first DOH server 72 to notify terminal 71 of verification information.

[0268] [Table 4]

[0269] The following is an example of the structure of a Yang module not published on the LAN, used for exchange between authorization server 93 and network controller to supply a new identifier for the second DOH server used in the DNS service:

[0270] [Table 5]

[0271] An example of a JSON object used by the first DoH server 92 to notify the terminal 91 of new redirection information is as follows.

[0272] [Table 6] [Description of Reference Numerals]

[0273] 11, 21, 31, 41, 51, 61, 71, 91, 101 Terminal 13 DNS server 14, 35, 45 CPE 23 Malicious device R 31 Client 32, 42 DoH server 33 DoH request 34, 44 Redirection message 36, 37 DoH session 46 Malicious server 52 First name resolution server 53, 63, 93, 103 Authorization server 54, 74 Network (controller) 55 Second name resolution server 62, 72, 73, 92, 102 First DoH server 75 Second DoH server 111 Memory 112 Processing unit 113 Computer program

Claims

1. A name resolution method implemented in a terminal (51) connected to a communication network, Step (511) of sending a name resolution message to the first name resolution server (52) via a secure communication channel between the terminal (51) and the first name resolution server (52), If the redirection of DNS traffic of the terminal is authorized by the authorization server, the steps (512) include obtaining at least one identifier of a second name resolution server (55) identified for the terminal of the redirection, A step of managing the redirection of the DNS traffic of the terminal to the second name resolution server (55) by verifying the legitimacy of the second name resolution server, wherein verifying the legitimacy of the second name resolution server is A step of receiving at least one piece of information to verify the legitimacy of the second name resolution server, The steps include sending a name resolution request generated from at least one piece of information, The steps include verifying the legitimacy of the entity that issued the response by comparing the response to the name resolution request with a test response obtained from the at least one piece of information, and A step characterized by including, A name resolution method characterized by including the following.

2. The name resolution method according to claim 1, wherein the step of managing the redirection of the terminal's DNS traffic to the second name resolution server (55) further comprises the steps of sending a notification of connection failure between the terminal and the second name resolution server, and generating a new identifier retrieval from the second name resolution server.

3. A terminal configured for redirecting DNS traffic within a communication network, A name resolution message is sent to the first name resolution server via a secure communication channel between the terminal and the first name resolution server. Obtain at least one identifier of a second name resolution server identified for the terminal for the redirect, and the redirection of the terminal's DNS traffic is authorized by the authorization server. By verifying the legitimacy of the second name resolution server, the redirection of DNS traffic from the terminal to the second name resolution server is managed, and verifying the legitimacy of the second name resolution server is, A step of receiving at least one piece of information to verify the legitimacy of the second name resolution server, The steps include sending a name resolution request generated from at least one piece of information, The steps include verifying the legitimacy of the entity that issued the response by comparing the response to the name resolution request with a test response obtained from the at least one piece of information, and Features including, A terminal characterized by being configured in such a way.

4. A network controller for controlling the redirection of DNS traffic authorized by an authorization server to terminals in a communication network, The system transmits to the terminal (51) at least one identifier of the second name resolution server (55) identified for the terminal of the redirect. Information is exchanged between the terminal and a second name resolution server identified for the terminal for the authorized redirection of the terminal's DNS traffic, including at least one piece of information provided to the second name resolution server by the network controller for the terminal to verify the legitimacy of the second name resolution server. A network controller characterized by being configured in such a way.

5. A system for redirecting DNS traffic within a communication network, The terminal according to claim 3, The network controller according to claim 4, A second name resolution server identified for the terminal for authorized redirection of the terminal's DNS traffic, The first name resolution server, Authorization server and Includes, The preceding second name resolution server, The network controller provides the second name resolution server with the terminal, and the terminal exchanges information with the network controller of the communication network, which includes at least one piece of information for verifying the legitimacy of the second name resolution server. A response is sent to a name resolution request originating from the terminal, and the name resolution request is generated by the at least one piece of information. It is configured in such a way, The name resolution server for the first name resolution server is: The name resolution message is received from the terminal via a secure communication channel between the terminal and the first name resolution server. From the authorization server, obtain authorization for redirecting DNS traffic for the terminal and at least one identifier of a second name resolution server identified for the terminal for the redirection. Send a redirect message having the at least one identifier of the second name resolution server to the terminal. It is configured in such a way, The authorization server, Obtain at least one identifier of the second name resolution server identified for the terminal for the redirection, The first name resolution server is sent a redirect authorization for the terminal and the at least one identifier of the second name resolution server. A system characterized by being configured in such a way.

6. The system according to claim 5, characterized in that, for the purpose of resolving a failure in connection between the terminal and the second name resolution server, the information is provided to the network controller by the second name resolution server, the information includes at least one new identifier of the second name resolution server, and the network controller is further configured to transmit the at least one new identifier to a network authorization server.

7. The system according to claim 5, characterized in that the network controller is configured to obtain at least one new identifier of the second name resolution server from a default router designated for the communication network, and to transmit the at least one new identifier to the authorization server of the communication network.

8. The system according to any one of claims 5 to 7, further configured to transmit to the second name resolution server during the information exchange the legitimacy of the second name resolution server or at least one identifier of the terminal authorized to verify at least one identifier of the network to which the terminal belongs.

9. The system according to claim 5, wherein the second name resolution server is configured to send a response to a name resolution request to the terminal, the response including a test response obtained from at least one identifier of the terminal, and the at least one piece of information for verifying the legitimacy of the second name resolution server is obtained during exchange with the network controller.

10. The second name resolution server, Generate at least one new identifier for the aforementioned second name resolution server, During communication with the network controller to resolve a connection failure between the terminal and the second name resolution server, the network controller is sent the at least one new identifier. The system according to claim 5 or 9, characterized in that it is configured in such a way.

11. The first name resolution server, in accordance with the notification from the terminal of a failure to connect to the second name resolution server, From the authorization server, obtain at least one new identifier of the second name resolution server. The terminal is sent the at least one new identifier of the aforementioned second name resolution server. The system according to claim 5, characterized in that it is configured in such a way.

12. The first name resolution server, After the connection between the terminal and the second name resolution server fails at least once, the DNS traffic redirection to the second name resolution server is disabled, or In response to a request from the terminal, the DNS traffic redirection to the third name resolution server specified by default for the terminal is disabled. The system according to claim 5 or 11, characterized in that it is configured in such a way.

13. The authorization server provides the network controller of the communication network, At least one identifier of the aforementioned terminal, At least one identifier of the network to which the terminal belongs, The at least one identifier of the preceding second name resolution server, At least one piece of information to verify the legitimacy of the second name resolution server, Send at least one element belonging to the group, The system according to claim 5, characterized in that it is configured in such a way.

14. The authorization server is From the network controller, obtain at least one new identifier of the second name resolution server. The first name resolution server transmits the at least one new identifier of the second name resolution server. The system according to claim 5 or 13, characterized in that it is configured in such a way.

Images