WO2023083772A1 - Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés - Google Patents

Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés Download PDF

Info

Publication number
WO2023083772A1
WO2023083772A1 PCT/EP2022/081048 EP2022081048W WO2023083772A1 WO 2023083772 A1 WO2023083772 A1 WO 2023083772A1 EP 2022081048 W EP2022081048 W EP 2022081048W WO 2023083772 A1 WO2023083772 A1 WO 2023083772A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
dns
client equipment
domain name
trusted entity
Prior art date
Application number
PCT/EP2022/081048
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Priority to CN202280074344.XA priority Critical patent/CN118303013A/zh
Priority to EP22813298.1A priority patent/EP4430814A1/fr
Publication of WO2023083772A1 publication Critical patent/WO2023083772A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Definitions

  • the invention belongs to the general field of telecommunications.
  • DNS Domain Name System
  • a DNS system is a fundamental component in IP (Internet Protocol) communication networks. It makes it possible to associate with a resource such as a domain name, an identifier of the URI type (for "Uniform Resource Identifier" in English) one or more IP addresses allowing access to this resource.
  • a resource such as a domain name, an identifier of the URI type (for "Uniform Resource Identifier" in English) one or more IP addresses allowing access to this resource.
  • a client device such as for example a terminal or an application
  • wishes to establish, to access any service a communication with a server identified by a fully qualified domain name (or FQDN for "Fully Qualified Domain Name in English), such as "www.example.com”
  • the DNS client embedded in the client device in question sends a DNS resolution request to a DNS server to retrieve the IP address or addresses associated with this name of domain.
  • the DNS server can then respond with a list of IP addresses if an entry that corresponds to this domain name is available locally, or relay the request from the communicating entity to another DNS server (recursive DNS server) according to the DNS hierarchy known if it does not have such an entry, etc.
  • the DNS service and more particularly the DNS server to be used for domain name resolution, is generally configured at the client equipment level by the operator who provides it with IP connectivity ( access network operator or IP service). This configuration takes place prior to any communication from the client equipment, typically when it is connected or attached to the network of the operator in question or via a factory configuration.
  • alternate servers are generally public DNS servers, offered by third-party operators, and display faster response times than some nominal DNS servers provided by operators, and/or offering more advanced security features.
  • DNS configuration i.e. nominal server provided by the IP connectivity operator, or alternative public or private server
  • Service providers are therefore dependent on the performance of this DNS configuration for the rendering of the services they offer to users, and therefore do not control the overall quality of experience perceived by the latter. Indeed, if the underlying DNS service offered by the nominal DNS server provided by the operator or the alternative DNS server selected by the user is not optimal, a degradation of the service may follow.
  • the invention improves this situation by proposing, according to a first aspect, a method for controlling client equipment to access a service via a network, this control method being intended to be implemented by a trusted entity to the service and/or the client equipment and comprising a step of controlling a configuration of said client equipment, when it accesses said service, so that it transmits to at least one device designated for the service and authorized by the trusted entity, at least one domain name resolution request sent by the client equipment as part of the service.
  • the invention also relates to a trusted entity for a service and/or client equipment of a network, this trusted entity comprising a control module, configured to control a configuration of the client equipment during an access to the service, so that it transmits to at least one device designated for the service and authorized by the trusted entity, at least one domain name resolution request sent by the client equipment within the framework of the service.
  • This trusted entity is for example a server involved directly or indirectly in the provision of the service, such as for example an authoritative server (or "authoritative server") requested by the client equipment for the provision of the service.
  • an authoritative server or "authoritative server”
  • it may be an intermediate entity placed on a communication path taken during access to the service by the client equipment.
  • Such an intermediate entity can in particular be a proxy (or relay).
  • the invention therefore proposes to dynamically control, by a trusted entity for the service and/or for the client equipment, the DNS configuration of the latter in order to correlate it with the service to which it provides access.
  • the trusted entity replaces the nominal DNS server or the alternative DNS server configured by default in the client equipment by a device that it has designated to resolve the DNS queries sent by the client equipment in the framework of a service.
  • This control makes it possible to personalize the DNS service used when accessing the service (i.e. when the client equipment consumes the service in question), to optimize it for this service, and thus to improve the quality of experience perceived by the user.
  • the DNS service thus controlled is advantageously adapted to the service: it can in particular be adapted to service constraints, offer advanced functions based on the DNS service benefiting the user and the service, or even be configured so that all or part of the connections (service) established from the client equipment are subject to special processing. It can also be adapted to the client equipment, and differ from one client equipment to another.
  • DNS device responsible for resolving domain name resolution requests issued by a client device as part of its access to a service, it is possible to control the equipment through which the connections established by the client equipment as part of the service pass, and therefore incidentally the processing applied to these connections.
  • customer equipment may be configured with customer identity preservation policies (for example, minimizing the volume of credentials shared with services, location or network attachment).
  • customer identity preservation policies for example, minimizing the volume of credentials shared with services, location or network attachment.
  • the invention makes it possible to ensure that the client equipment uses DNS information reported by a trusted entity which maintains a list of DNS servers per service. This list can be enriched with quality of service measures and depending on the location of the client equipment.
  • the trusted entity selects the DNS server(s) for the client equipment when accessing the service to check the identification information and/or improve the quality of service.
  • the invention allows in particular a better distribution of the DNS traffic sent by the client equipment; this avoids a concentration of DNS requests to a single DNS server, which reduces the traceability of users based on their DNS requests (also known as "DNS profiling").
  • the service provider has overall control over the provision of its service and can thus incur liability in the event of deterioration of this service ( g. degraded access time to the service).
  • control of the DNS configuration according to the service as proposed by the invention can be exploited to implement new functions in the network in connection with the service.
  • the DNS device can adapt its responses to the DNS queries of the client equipment so as to be in the path of all the connections established by the client equipment when accessing the service, namely not only the connection main connection established by the user equipment with the infrastructure offering the service, but also all the secondary connections established on the sidelines of this main connection, such as for example with tracking servers, etc. Thanks to this privileged position, the DNS device is able to analyze the data packets transmitted on all of these connections and to track or detect specific events likely to affect the private nature of the data transmitted in these packets, such as for example the transport by these packets of information identifying the user of the client equipment. It can also designate another device responsible for analyzing the data transported in the packets sent by the user's client device.
  • the invention also offers the possibility of adding more easily and immediately to the DNS device, new advanced functions advantageous for the implementation of the service.
  • deployment of such functions requires the involvement of several actors, which makes this deployment complex.
  • RR for "Resource Record”
  • RR for "Resource Record”
  • the invention allows a service provider to deploy new functions within the framework of this service without being dependent on these other players and allows the client equipment to benefit from such functions.
  • the DNS device designated by the trusted entity can also be advantageously configured with "private" domain names, specific to the implementation of the service and which the service provider does not wish to communicate to a public DNS server or to a nominal DNS server provided by the network operator (context of a service based on connected objects for example). Such a public or nominal DNS server will then return a negative response if it is asked to resolve such a private domain name. Not disclosing these private domain names is a security measure to minimize the risk of potential denial of service attacks targeting these domain names.
  • the invention offers a certain flexibility in terms of introducing or removing domain names at the level of the DNS chain, which is not the case with a public or nominal DNS server.
  • DNS device designated by the trusted entity it is also possible to configure the DNS device designated by the trusted entity so that it returns personalized responses to the client equipment when it is requested for the resolution of domain names, allowing for example to satisfy constraints of service.
  • a personalized response may consist in particular of sending one or more IP addresses located near the client equipment (also called "Geoproximity IP").
  • the step of configuring the client equipment comprises a transmission by the trusted entity to the client equipment of a message comprising at least information on the reachability of at least one said designated device for the service and authorized by the trusted entity.
  • the message in question may or may not be encrypted. Encrypting the message helps prevent hacking of connections by a third-party entity, and such encryption is preferable in the case of a trusted entity for the service.
  • the security of the exchanges between the trusted entity and the client equipment can be ensured by other mechanisms (for example for a trusted entity for the client configured using ACL rules (for "Access Control Lists in English) adequate).
  • This embodiment also has the advantage of separating the service logic from the DNS logic, and allows better stability of the DNS service and mechanism: the customization of the DNS service is carried out by the device designated by the trusted entity and not by the infrastructure (eg authoritative server) providing the service.
  • the message in question may be a response message to a service invocation message sent by the client equipment.
  • a service invocation message is for example a TCP 3WHS message as mentioned above, or a ClientHello TLS message (for "Transport Layer Security" in English) or even a Handshake QUIC message, messages known per se. This is transparent to the user and saves the signaling (and bandwidth) required to implement the invention.
  • the message in question may be a message sent asynchronously by the trusted entity.
  • said at least one reachability information is included in a header, an option, a frame (for example a QUIC frame), an attribute (for example an SDP (Session Description Protocol) attribute), a load useful (or "message body" in English with a predefined structure), etc.
  • a frame for example a QUIC frame
  • an attribute for example an SDP (Session Description Protocol) attribute
  • a load useful or "message body" in English with a predefined structure
  • This variant is relatively simple to implement and is based on already existing messages. Only a header (or, where applicable, an option, a frame, an attribute or a payload having a predefined structure according to the variant envisaged) must be newly introduced for the purposes of the invention.
  • the invention has a privileged application when any version of the HTTP protocol is used, it can also be used in association with other protocols, such as for example with the CoAP protocol (Constrained Application Protocol) by means of the definition of a new option dedicated to the invention, or with the QUIC protocol, by means of the definition of a new frame dedicated to the invention.
  • CoAP protocol Constrained Application Protocol
  • QUIC protocol QUIC protocol
  • the reachability information is sent in a dedicated response message whose structure is explicitly indicated by a new media type (or "media type” in English such as for example "json+dns-resolver ").
  • This media type indicates that the content of a message is of type "JSON" and carries a DNS server.
  • the configuration of the client equipment can be implemented via the sending, by the trusted entity, of a list of domain names potentially involved when accessing the service by the client equipment, and IP addresses which are respectively associated with them, for example in a response to a service invocation message or to a DNS query. It should however be noted that this embodiment has an implication on the size of the messages sent to the client equipment, and can induce, depending on the transport protocol involved, fragmentation.
  • the invention also offers the possibility of indicating to the client equipment a plurality of DNS devices (and in particular information on the reachability of these DNS devices), each DNS device being able to be associated with a context of use so that the client equipment is able to direct its DNS requests to the most suitable DNS device according to the context in which it is located (eg according to its geographical location).
  • the message transmitted by the trusted entity may include, for at least one said device designated for said service and authorized by said trusted entity, at least one item of information characterizing at least one functional capability of said device.
  • Such a functional capability is for example a list of methods, and/or records (RR), and/or protocols supported by the device in question.
  • the DNS device is adapted to the context in which the client equipment requests domain name resolution and can provide a detailed response to the client equipment.
  • the client equipment further comprises an obtaining module, configured to obtain for at least one said designated device, information characterizing at least one functional capacity of this device, the transmission module being configured to transmitting said at least one domain name resolution request to a said device selected according to said at least one functional capacity of this device.
  • the transmission method and the client equipment benefit from the same advantages mentioned above as the control method and the trusted entity.
  • control and transmission methods are implemented by a computer.
  • the invention also relates to a computer program on a recording medium, this program being able to be implemented in a computer or more generally in a trusted entity in accordance with the invention and comprises instructions adapted to the implementation of a control method as described above.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in client equipment in accordance with the invention and comprises instructions adapted to the implementation implementation of a transmission method as described above.
  • Each of these programs may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any what other desirable form.
  • the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information or recording medium can be any entity or device capable of storing programs.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a hard disk, or a flash memory.
  • the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be routed via an electrical or optical cable, by radio link, by wireless optical link or by other ways.
  • the program according to the invention can in particular be downloaded from an Internet-type network.
  • the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the control or transmission methods according to the invention.
  • control and transmission methods the trusted entity, the client equipment and the system according to the invention to have all or part of the aforementioned characteristics in combination.
  • NW Network
  • the NW network can be composed of one or more (sub)networks connected to each other.
  • the service S is an application service offered via the Internet by a service provider SP to a client equipment 2 of a user U, in accordance with the invention.
  • a service provider SP to a client equipment 2 of a user U
  • the service provider SP relies on a service infrastructure hosted in a service domain SR (or "Service Realm”).
  • the service domain SR comprises an authoritative server 3 (or "authoritative server” in English) with which, to access the service S, the user U establishes a so-called main connection (C1) via its client equipment 2.
  • the service domain SR comprises a plurality of servers (eg authoritative server, cache servers, load balancers (or " load balancers), etc.) hosted in a single structure (e.g. a cloud computing infrastructure) or a single piece of equipment, or in several structures or several pieces of equipment.
  • the service S can also be located in a network other than the Internet network, for example in an operator's network or in a public infrastructure (eg public cloud or "public cloud” in English).
  • the user equipment 2 in order to access the Internet network and the service S, the user equipment 2 is connected directly to an operator's network, and more particularly to a cellular access network AN or PLMN (for "Public Land Mobile Network” in English) administered by a PO operator.
  • AN cellular access network
  • PLMN Public Land Mobile Network
  • the user equipment 3 can be connected to the Internet network via a local network (or LAN for "Local Area Network” in English) such as a home network, a corporate network, etc., through dedicated equipment referred to as CPE (Customer Premises Equipment).
  • CPE Customer Premises Equipment
  • the operator OP configures the user equipment 2 with reachability information (e.g. address(es) IP, domain name, alias, authentication identifier, etc.) of a so-called nominal DNS server 4 to be used to resolve its DNS requests, regardless of the service to which the client equipment 2 wishes to access.
  • This reachability information can possibly be modified by the user U, via a user interface provided for this purpose, to replace the nominal DNS server 4 with a public DNS server 5, accessible via the Internet network.
  • This DNS configuration of the client equipment 2 (whether with the nominal DNS server 4 or with the public DNS server 5) is carried out independently of any access to a service by the client equipment 2, for example prior to any access to a service (in particular for the configuration with the nominal DNS server 4), in other words before any invocation or consumption of the service by the client equipment 2, and applies here once performed, regardless of the service to which the client equipment 2 accesses. It is referred to here as "nominal DNS configuration".
  • nominal DNS server 4 has been considered in the nominal DNS configuration. It is however possible to define in this nominal DNS configuration several DNS servers which can be selected according to the network interface used by the client equipment 2 to access a service.
  • the system 1 for accessing the service S makes it possible to check the DNS configuration of the client equipment 2 to adapt it to the service S. This check takes place when the client equipment 2 invokes the service S, as further detailed later.
  • the system 1 comprises, in addition to the client equipment 2, a trusted entity 6, in accordance with the invention.
  • the trusted entity 6 is an entity with which the provider SP of the service S has a relationship of trust. It may for example be an entity managed by the provider SP of the service S or an entity with which it has a security relationship. Such an entity is for example an entity 7 for coordinating the service S located in the service domain SR, or even the authoritative server 3.
  • this trusted entity 6 which, in accordance with the invention, is able to authorize at least one device generally referenced by 8 (also sometimes referred to as "DNS device 8" in the following), designated specifically for the service S, to resolve the DNS requests of the client equipment 2 and to control the DNS configuration of the client equipment 2 so that it addresses the DNS requests that it has within the framework of the access to the service S to this or these DNS devices 8 for the resolution of the domain names targeted by these DNS queries.
  • DNS device(s) 8 are chosen is described in more detail later. They may differ from one client device to another.
  • the DNS devices 8 belong in accordance with the invention to the system 1 for accessing the service S.
  • the client equipment 2 and the trusted entity 6 for the service S have the hardware architecture of a computer 9 as illustrated in . It is noted that as a variant, the client equipment 2 and/or the trusted entity 6 can be software instances hosted by a physical equipment having the hardware architecture of the computer 9.
  • the computer 9 comprises in particular a processor 10, a random access memory 11, a read only memory 12, a non-volatile memory 13, and communication means 14 allowing in particular the entities of the system 1 to communicate with each other.
  • the read only memory 12 of the computer 9 constitutes a recording medium in accordance with the invention, readable by the processor 10 and on which is recorded a computer program in accordance with the invention.
  • the ROM 12 of the computer 9 comprises, when the latter is or hosts a trusted entity 6 in accordance with the invention, a recording of a computer program PROG6, comprising instructions defining the main steps of a control method according to the invention.
  • modules 6A and 6B are described in more detail later with reference to the steps of the control method according to the invention.
  • the ROM 12 of the computer 9 then comprises a recording of a computer program PROG2, comprising instructions defining the main steps of a transmission method according to the invention.
  • modules 2A to 2C are described in more detail later with reference to the steps of the transmission method according to the invention.
  • the trusted entity 6 is the authoritative server 3.
  • the client equipment 2 is configured to use the nominal DNS configuration introduced previously, in other words to transmit its domain name resolution requests or DNS requests to the nominal DNS server 4.
  • the 2D local cache does not contain any alternative DNS configuration to the nominal DNS configuration to be applied in the context of access to the service S.
  • the client equipment 2 when the client equipment 2 wishes to access the service S, and in particular establish a connection with the authoritative server 3, it sends, via its transmission module 2C, a DNS request designated by QUERY (3), to its nominal DNS server 4 (step H10).
  • the nominal DNS server 4 responds to it, in a manner known per se, by providing an IP address, denoted @IP3, of the authoritative server 3 (step H20).
  • IP3 IP address
  • he can contact recursive DNS servers if necessary.
  • connection underlying the service for example via an exchange based on the TCP and TLS protocols, the client equipment 2 then sends an HTTP POST request of access to the service S to the authoritative server 3 using as destination address the IP address @IP3 which was transmitted to it (step H30).
  • the authoritative server 3 acts as a trusted entity 6 according to the invention. It therefore includes the modules 6A and 6B of the trusted entity 6 described above.
  • the authoritative server 3 upon receipt of the HTTP POST access request from the client equipment 2, the authoritative server 3 (acting as a trusted entity 6) processes this request. He also consults his authorization module 6A to obtain the reachability information(s) (eg IP addresses here) of the DNS device(s) 8 authorized for the service S to resolve the DNS queries sent in the context of access to the service S. It is assumed here that a number K greater than or equal to 1 of DNS devices 8 are concerned. These K DNS devices are referenced respectively by DNS devices 8-1, 8-2, ..., 8-K in the following.
  • the authoritative server 3 then inserts, via its control module 6B, in its HTTP 200 OK response to the HTTP POST access request received from the client equipment 2, the K IP addresses, @IP8-1, ..., @IP8 -K of the K DNS devices 8 provided by its authorization module 6A, an indication (explicit or implicit) that the client equipment 2 must send its future DNS requests issued within the framework of the service S to at least one of said K DNS devices 8, as well as here, the DNS query selection rules applying to these K DNS devices 8 (in other words, the rules which allow the client equipment 2 to recognize the DNS queries associated with the service S which must be addressed to these DNS devices 8). Then it sends the HTTP 200 OK response to client equipment 2 (step H40).
  • the addresses @IP8-1, ..., @IP8-K are inserted by the control module 6B in the DNS_RESOLVER header which in itself indicates to the client equipment 2 that it must send its future DNS requests sent within the framework of the service S to at least one of the DNS devices 8 associated with one of the addresses @IP8-1, ..., @IP8-K.
  • the control module 6B also inserts into the DNS_RESOLVER header in association with each IP address, at least one item of information characterizing at least one functional capacity as described above of the DNS device 8 corresponding to this IP address (e.g. a list protocols or RR records or even methods supported by each DNS device 8, or a combination of such lists).
  • Functional capacities can, depending on their nature, be inserted in different fields of the DNS_RESOLVER header.
  • the transport protocols supported by the DNS device 8 considered in a TRANSPORT_SET field
  • the RR records in an RR_SET field and the methods in a QUERY_SET field.
  • these names are given for illustrative purposes only.
  • the insertion of the DNS_RESOLVER header in the HTTP 200 OK response to the HTTP POST request is a control step within the meaning of the invention by the authoritative server 3 acting as a trusted entity 6 .
  • the DNS_RESOLVER header is inserted in a response to an HTTP POST access request to the service sent after the establishment of the underlying connection to the service S between the client equipment 2 and the authoritative server 3.
  • a header may be inserted in a response to an HTTP POST request sent during the procedure for establishing the underlying connection to the service S.
  • Such an HTTP POST request may for example be sent in a SYN and ClientHello TLS message if the TCP Fast Open and 0-RTT TLS mechanisms described in IETF RFC 7413 and RFC 8446 respectively are enabled.
  • the previously mentioned indications, carried by the DNS_RESOLVER header are inserted in a TCP and/or TLS option in response to a service access request or to a request to establish the underlying connection in service S.
  • the module 2B for modifying the client equipment 2 modifies the DNS configuration applied by the client equipment 2 (which corresponds here to that which is stored in the storage module 2A in the absence of DNS configuration associated with the service S stored in the local cache 2D). More specifically, it memorizes in the local 2D cache the addresses @IP8-1, ..., @IP8-K of the DNS devices 8 included in the DNS_RESOLVER header to be used when accessing the service S as well as the selection rules allowing the client equipment 2 to identify the DNS requests concerned by these DNS devices (step H50).
  • the transmission module 2C of the client equipment 2 addresses the future DNS requests (QUERY(X)) sent within the framework of the service S (for example, all the requests relating to the subdomains “*.example .com” according to the selection rules defined by the trusted entity 6) to one of the DNS devices 8 identified in the new DNS configuration stored in the local cache 2D (and no longer to its nominal DNS server 4 as when of step H10, which can however continue to be requested for DNS queries sent within the framework of services other than service S and not concerned by the DNS configuration stored in the local cache 2D) (eg steps 60, H70).
  • these DNS requests can target a public domain name, but also a private domain name that the DNS devices 8 are adapted to resolve, or a domain name generated within the framework of the service S for the client equipment 2, or an ephemeral domain name generated within the framework of the service S, etc., or even a domain name verifying several of these characteristics.
  • step H10 the 2D local cache already includes a DNS configuration to be applied for the service S different from the nominal DNS configuration, and this DNS configuration is associated in the local cache 2D to a non-expired period of validity
  • the client equipment 2 applies this DNS configuration recorded in the local cache 2D and addresses directly one of the DNS devices 8 to resolve its DNS request .
  • Said device supplies the address @IP3 of the authoritative server 3 in response to the DNS request sent by the client equipment 2 during step H20.
  • Steps H30 and H40 are maintained and make it possible, if necessary, to extend the validity period of the DNS configuration already stored in the local 2D cache for the service S, or if the DNS configuration applying to the service S has been modified by the entity 6, modify this DNS configuration.
  • the transmission module 2C selects one DNS devices 8 according to a given criterion.
  • a criterion is for example here the functional capacities of the DNS devices 8.
  • the transmission module 2C can either select the DNS device 8-1 or the device 8-2 for sending DNS GET and POST requests, and select the device 8-1 only for sending DNS FETCH requests.
  • SVCB Ses ViCe Binding
  • MX Mail eXchange
  • the DNS_RESOLVER header received by the client equipment 2 indicates a list of protocols supported by each of the DNS devices 8-1, 8-2, and more particularly for the DNS device 8-1 the Do53 and DoQ protocols, while for the DNS device 8-2 the DoH (DNS over HTTPS) and DoC (DNS over CoAP) protocols, the DoT (DNS over TLS) protocol, the Do53, DoQ (
  • other criteria can be considered, such as for example a random selection, or a selection of a DNS device 8 according to its geographical proximity with respect to the client equipment 2, or even a combination of several criteria, etc
  • the new DNS configuration to be applied is communicated by the authoritative server 3 / the trusted entity 6 to the client equipment 2 in response to its request for access to the service S. It should however be noted that this hypothesis is not limiting in itself and that the new configuration can be communicated to the client equipment 2 in response to any other service invocation message S, provided that it is sent while the client equipment 2 accesses the service S.
  • the indication to apply the new DNS configuration can be transmitted by the authoritative server 3 / the trusted entity 6 to the client equipment 2 asynchronously or spontaneously, that is to say without being linked to a particular service S invocation message sent by the client equipment 2.
  • the authoritative server 3/the trusted entity 6 itself indicates to the client equipment 2 the new DNS configuration to be applied for the service S, in other words the authoritative server 3 / the trusted entity 6 directly modifies the DNS configuration applied by the client equipment 2 for the service S.
  • the modification at the level of the client equipment 2 can be controlled (i.e. decided) by the trusted entity 6 but be implemented in the customer equipment 2 by an intermediate entity.
  • This intermediate entity can be any entity with which the trusted entity 6 maintains a relationship of trust and/or security, such as for example an entity of the service infrastructure or a third-party entity placed in particular on the path of communications borrowed when accessing the service by the client equipment. It may even be one of the DNS devices it has authorized for the service.
  • the authoritative service 3 / the trusted entity 6 is a trusted entity 6 for the service, since it is a entity of the infrastructure on which the service is based. It is however possible to envisage other trusted entities than entities of the service infrastructure, such as for example an entity designated by the service provider or of another infrastructure with which the service provider has established an agreement based on a trust.
  • the trusted entity which controls the DNS configuration used by the client equipment 2 during its access to the service S is a trusted entity for the client equipment 2.
  • it may be an intermediate equipment via which the client equipment 2 establishes a connection with the Internet network to access the service S and with which it has itself established a secure connection (for example encrypted, or a secure communication tunnel) so that all the messages transmitted and received by the client equipment 2 during access to the service S pass through this intermediate equipment.
  • Such intermediate equipment may be, by way of illustration, equipment of the CPE (for "Customer Premises Equipment") type, or a relay or proxy located in the Gi interface of a mobile network, etc.
  • This list of rules may come from measurements carried out by the intermediate equipment in question or by another equipment allowing the intermediate equipment to classify the DNS devices according to their availability or their performance, for example.
  • DNS devices for the service S, devices of the network NW via which it is desired that connections established by the client equipment within the framework of the service S transit. These connections can include the main connection established by the client equipment with the authoritative server to access the service, but also all the secondary connections established on the sidelines of this main connection, sometimes without the knowledge of the user of the client equipment. .
  • the DNS devices thus designated can thus resolve each DNS query sent by the client equipment 2 by providing their own IP addresses so as to receive each data packet sent by the client equipment on the main and secondary connections. Upon receipt of these data packets, they can thus set up various processing operations, such as for example the analysis of the content of these packets to determine whether they contain user identification information, or other information that they wish to stalk.
  • the DNS devices can also, as a variant, resolve each request sent by the client equipment by providing the IP address of another trusted equipment responsible for such processing. This use case makes it possible to place given equipment on the path of the main and secondary connections established by the client equipment as part of the S service.
  • DNS devices for the service S are designated DNS devices which have been configured to resolve, among other things, queries for domain names relating to private and/or personalized domain names and/or even ephemeral, generated within the framework of the service S, for example by the service provider. These domain names are deliberately kept secret and will remain unknown to public or nominal DNS servers set up by network operators.
  • This second use case can be adopted as a security measure to prevent denial of service attacks, for example. It also allows the service provider to consider customizable domain names, and for example to generate personalized domain names based on the identity of the user of the client equipment, or ephemeral domain names.
  • the use of service-specific DNS devices facilitates the addition and/or removal of such domain names and avoids the latency induced by such an approach with a public/nominal DNS server.
  • DNS devices for the service S, DNS devices which have been configured to carry out a personalized resolution of the DNS requests addressed by a client equipment, for example with a view to respecting the service constraints.
  • a DNS device may return to a client equipment an IP address for a domain name and located near the client equipment (e.g. having a delay of less than "x ms").
  • DNS devices which implement advanced DNS functions, which are not implemented by public or nominal DNS servers provided by the operators.
  • S DNS devices which implement advanced DNS functions, which are not implemented by public or nominal DNS servers provided by the operators.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Selective Calling Equipment (AREA)

Abstract

L'invention concerne un procédé de contrôle d'un équipement client (2) pour accéder à un service via au moins un réseau, ce procédé de contrôle étant destiné à être mis en œuvre par une entité (6,3) de confiance pour le service et/ou l'équipement client et comprenant une étape de contrôle d'une configuration de l'équipement client, lors d'un accès de celui-ci au service, pour qu'il transmette vers au moins un dispositif (8; 8-1,..., 8-K) désigné pour le service et autorisé par l'entité de confiance, au moins une requête de résolution de noms de domaine émise par l'équipement client dans le cadre du service.

Description

Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés
L’invention appartient au domaine général des télécommunications.
Elle concerne plus particulièrement les systèmes de résolution de noms de domaine ou DNS (pour « Domain Name System » en anglais).
De façon connue, un système DNS est une composante fondamentale dans les réseaux de communication IP (pour « Internet Protocol » en anglais). Il permet d’associer à une ressource telle qu’un nom de domaine, un identifiant de type URI (pour « Uniform Resource Identifier » en anglais) une ou plusieurs adresses IP permettant d’accéder à cette ressource.
Ainsi, lorsqu’un équipement client, tel que par exemple un terminal ou une application, souhaite établir, pour accéder à un service quelconque, une communication avec un serveur identifié par un nom de domaine pleinement qualifié (ou FQDN pour « Fully Qualified Domain Name » en anglais), tel que « www.example.com », le client DNS embarqué dans l’équipement client en question envoie une demande de résolution DNS à un serveur DNS pour récupérer l’adresse ou les adresses IP associées à ce nom de domaine. Le serveur DNS peut alors répondre avec une liste d’adresses IP si une entrée qui correspond à ce nom de domaine est disponible localement, ou relayer la demande de l’entité communicante vers un autre serveur DNS (serveur DNS récursif) selon la hiérarchie DNS connue s’il ne dispose pas d’une telle entrée, etc.
Dans l’état actuel de la technique, le service DNS, et plus particulièrement le serveur DNS à utiliser pour la résolution de noms de domaine, est généralement configuré au niveau de l’équipement client par l’opérateur qui lui fournit une connectivité IP (ex. opérateur de réseau d’accès ou de service IP). Cette configuration a lieu préalablement à toute communication de l’équipement client, typiquement lors de son raccordement ou de son attachement au réseau de l’opérateur en question ou via une configuration d’usine.
Certains utilisateurs remplacent cette configuration DNS nominale fournie par leur opérateur par des serveurs DNS alternatifs. Ces serveurs (désignés par « serveurs alternatifs » dans la suite de la description) sont généralement des serveurs DNS publics, offerts par des opérateurs tiers, et affichant des temps de réponse plus rapides que certains serveurs DNS nominaux fournis par les opérateurs, et/ou offrant des fonctions de sécurité plus avancées.
Quelle que soit la configuration DNS retenue (c’est-à-dire serveur nominal fourni par l’opérateur de connectivité IP, ou serveur alternatif public ou privé), elle s’applique indifféremment à tous les services auxquels accède l’équipement client. Les fournisseurs de services sont donc tributaires des performances de cette configuration DNS pour le rendu des services qu’ils proposent aux utilisateurs, et ne maîtrisent donc pas la qualité d’expérience globale perçue par ces derniers. En effet, si le service DNS sous-jacent offert par le serveur DNS nominal fourni par l’opérateur ou le serveur DNS alternatif sélectionné par l’utilisateur n’est pas optimal, il peut s’en suivre une dégradation du service.
L’invention vient améliorer cette situation en proposant, selon un premier aspect, un procédé de contrôle d’un équipement client pour accéder à un service via un réseau, ce procédé de contrôle étant destiné à être mis en œuvre par une entité de confiance pour le service et/ou l’équipement client et comprenant une étape de contrôle d’une configuration dudit équipement client, lors d’un accès de celui-ci audit service, pour qu’il transmette vers au moins un dispositif désigné pour le service et autorisé par l’entité de confiance, au moins une requête de résolution de noms de domaine émise par l’équipement client dans le cadre du service.
Corrélativement, l’invention vise aussi une entité de confiance pour un service et/ou un équipement client d’un réseau, cette entité de confiance comprenant un module de contrôle, configuré pour contrôler une configuration de l’équipement client lors d’un accès au service, pour qu’il transmette vers au moins un dispositif désigné pour le service et autorisé par l’entité de confiance, au moins une requête de résolution de noms de domaine émise par l’équipement client dans le cadre du service.
Cette entité de confiance est par exemple un serveur impliqué directement ou indirectement dans la fourniture du service, tel que par exemple un serveur autoritaire (ou « authoritative server ») sollicité par l’équipement client pour la fourniture du service.
Selon un autre exemple, il peut s’agir d’une entité intermédiaire placée sur un chemin de communication emprunté lors de l’accès au service par l’équipement client. Une telle entité intermédiaire peut être notamment un proxy (ou relais).
Il importe qu’il s’agisse d’une entité de confiance pour l’équipement client et/ou pour le service (et donc incidemment pour le fournisseur du service en question) pour éviter que cette entité ne soit utilisée pour détourner les données émises par l’équipement client.
L’invention propose donc de contrôler dynamiquement, par une entité de confiance pour le service et/ou pour l’équipement client, la configuration DNS de ce dernier afin de la corréler avec le service auquel il permet d’accéder. En d’autres termes, l’entité de confiance remplace le serveur DNS nominal ou le serveur DNS alternatif configuré par défaut dans l’équipement client par un dispositif qu’elle a désigné pour résoudre les requêtes DNS émises par l’équipement client dans le cadre d’un service. Ce contrôle permet de personnaliser le service DNS utilisé lors de l’accès au service (c’est-à-dire lorsque l’équipement client consomme le service en question), de l’optimiser pour ce service, et d’améliorer ainsi la qualité d’expérience perçue par l’utilisateur. Le service DNS ainsi contrôlé est avantageusement adapté au service : il peut notamment être adapté à des contraintes de service, offrir des fonctions avancées reposant sur le service DNS bénéficiant à l’utilisateur et au service, ou encore être configuré pour que tout ou partie des connexions (service) établies à partir de l’équipement client fassent l’objet de traitements particuliers. Il peut en outre être adapté à l’équipement client, et différer d’un équipement client à un autre. En contrôlant le dispositif (désigné ci-après par souci de simplification par « dispositif DNS ») chargé de résoudre les requêtes de résolution de noms de domaine émises par un équipement client dans le cadre de son accès à un service, il est possible de contrôler les équipements par lesquels transitent les connexions établies par l’équipement client dans le cadre du service, et donc incidemment les traitements appliqués à ces connexions.
Par ailleurs, dans certaines situations, l’équipement client peut être configuré avec des politiques de préservation de l’identité du client (par exemple, réduction au minimum du volume des données d’identification partagées avec les services, émulation de localisation ou d’attachement réseau). Appliquée dans un tel contexte, l’invention permet de s’assurer que l’équipement client utilise des informations DNS remontées par une entité de confiance qui maintient une liste de serveurs DNS par service. Cette liste peut être enrichie avec des mesures de qualité de service et en fonction de la localisation de l’équipement client. L’entité de confiance sélectionne pour l’équipement client le(s) serveur(s) DNS lors d’un accès au service pour contrôler les informations d’identification et/ou améliorer la qualité de service.
On note que par « lors d’un accès au service par l’équipement client », on entend de manière générale « à tout moment », dès lors que l’équipement client invoque/consomme le service en question. Ainsi, la modification de la configuration DNS de l’équipement client en une configuration DNS adaptée au service est mise en œuvre dès l’établissement de la connexion permettant d’accéder au service, aussi désignée ci-après par connexion sous-jacente au service (par exemple en réponse à une demande d’établissement d’une telle connexion sous-jacente au service envoyée par l’équipement client avant même que des données utiles soient échangées dans le cadre de ce service, tel que lors d’un échange 3WHS TCP (pour « 3-way handshake Transmission Control Protocol » en anglais). Toutefois, elle peut également avoir lieu ultérieurement, aussi longtemps que l’équipement client accède au service en question.
L’invention permet notamment une meilleure distribution du trafic DNS émis par les équipements clients ; on évite ainsi une concentration des requêtes DNS vers un seul serveur DNS, ce qui permet de réduire la traçabilité des utilisateurs sur la base de leurs requêtes DNS (aussi connue sous le nom de « profilage DNS »).
En outre, en disposant le cas échéant d’un contrôle sur la configuration DNS de l’équipement client, le fournisseur du service a une maîtrise globale sur la fourniture de son service et peut ainsi engager sa responsabilité en cas de dégradation de ce service (ex. temps d’accès dégradé au service).
Comme mentionné ci-avant, le contrôle de la configuration DNS en fonction du service tel que proposé par l’invention peut être exploité pour mettre en œuvre de nouvelles fonctions dans le réseau en lien avec le service.
En effet, le dispositif DNS peut adapter ses réponses aux requêtes DNS de l’équipement client de sorte à se trouver sur le chemin de toutes les connexions établies par l’équipement client lors de l’accès au service, à savoir non seulement la connexion principale établie par l’équipement utilisateur avec l’infrastructure offrant le service, mais également toutes les connexions secondaires établies en marge de cette connexion principale, comme par exemple avec des serveurs de traçage (ou « tracking servers », en anglais), etc. Grâce à cette position privilégiée, le dispositif DNS est en mesure d’analyser les paquets de données émis sur l’ensemble de ces connexions et de traquer ou détecter des événements déterminés susceptibles d’affecter le caractère privatif des données transmises dans ces paquets, comme par exemple le transport par ces paquets d’informations d’identification de l’utilisateur de l’équipement client. Il peut également désigner un autre équipement chargé de l’analyse des données transportées dans les paquets émis par l’équipement client de l’utilisateur.
L’invention offre également la possibilité d’adjoindre plus aisément et de façon immédiate au dispositif DNS, de nouvelles fonctions avancées avantageuses pour la mise en œuvre du service. Généralement, le déploiement de telles fonctions requiert l’implication de plusieurs acteurs, ce qui rend ce déploiement complexe. Par exemple, la définition d’un nouveau type d’enregistrement ou RR (pour « Resource Record ») n’est généralement pas recommandée car cela suppose la mise à jour d’un écosystème géré par plusieurs entités distinctes incluant les clients DNS, les serveurs DNS et les relais DNS chargés de l’acheminement des requêtes DNS (ou « forwarders » en anglais) les caches, etc., ainsi que la coordination entre ces entités afin de fiabiliser les informations maintenues par chacune d’entre elles. L’invention permet à un fournisseur du service de déployer de nouvelles fonctions dans le cadre de ce service sans être tributaire de ces autres acteurs et à l’équipement client de bénéficier de telles fonctions.
Le dispositif DNS désigné par l’entité de confiance peut également être avantageusement configuré avec des noms de domaine « privés », propres à la mise en œuvre du service et que le fournisseur du service ne souhaite pas communiquer à un serveur DNS public ou à un serveur DNS nominal fourni par l’opérateur du réseau (contexte d’un service reposant sur des objets connectés par exemple). Un tel serveur DNS public ou nominal renverra alors une réponse négative s’il est sollicité pour résoudre un tel nom de domaine privé. Le fait de ne pas communiquer ces noms de domaine privés constitue une mesure de sécurité permettant de minimiser le risque de potentielles attaques de déni de service visant ces noms de domaine.
Cela permet également au fournisseur de service de générer dans le cadre de son service des noms de domaine éphémères et personnalisés, par exemple en fonction de l’identité de l’utilisateur de l’équipement client. L’invention offre une certaine flexibilité en matière d’introduction ou de retrait de noms de domaine au niveau de la chaîne DNS, ce qui n’est pas le cas d’un serveur DNS public ou nominal.
Ainsi, au vu de ce qui précède, l’invention permet de gérer plusieurs types de requêtes de résolution de noms de domaine et notamment des requêtes concernant :
  • un nom de domaine privé ; et/ou
  • un nom de domaine généré dans le cadre du service pour l’équipement client ; et/ou
  • un nom de domaine éphémère.
Il est aussi possible de configurer le dispositif DNS désigné par l’entité de confiance pour qu’il retourne des réponses personnalisées à l’équipement client lorsqu’il est sollicité pour la résolution de noms de domaine, permettant par exemple de satisfaire des contraintes de service. Une telle réponse personnalisée peut consister notamment en l’envoi d’une ou plusieurs adresses IP situées à proximité de l’équipement client (encore appelées « Geoproximity IP »).
Dans un mode particulier de réalisation, l’étape de configuration de l’équipement client comprend une transmission par l’entité de confiance à l’équipement client d’un message comprenant au moins une information de joignabilité d’au moins un dit dispositif désigné pour le service et autorisé par l’entité de confiance.
Aucune limitation n’est attachée à la nature de l’information de joignabilité communiquée. Il peut s’agir notamment d’une adresse IP, d’un nom de domaine, un alias, un identifiant d’authentification, etc.
Ceci facilite la mise en œuvre de l’invention et permet une exécution immédiate de la nouvelle configuration DNS, dès réception du message. En outre, la quantité d’information véhiculée dans le message pour configurer l’équipement client est avantageusement réduite.
Il convient de noter que le message en question peut être chiffré ou non. Le chiffrement du message permet d’éviter le piratage des connexions par une entité tierce, et un tel chiffrement est préférable dans le cas d’une entité de confiance pour le service. Toutefois, la sécurisation des échanges entre l’entité de confiance et l’équipement client peut être assurée par d’autres mécanismes (par exemple pour une entité de confiance pour le client configurée à l’aide de règles ACL (pour « Access Control Lists » en anglais) adéquates).
Ce mode de réalisation présente en outre l’avantage de séparer la logique service de la logique DNS, et permet une meilleure stabilité du service et du mécanisme DNS : la personnalisation du service DNS est effectuée par le dispositif désigné par l’entité de confiance et non par l’infrastructure (ex. serveur autoritaire) fournissant le service.
Par exemple, le message en question peut être un message de réponse à un message d’invocation du service émis par l’équipement client. Un tel message d’invocation est par exemple un message TCP 3WHS tel qu’évoqué précédemment, ou un message ClientHello TLS (pour « Transport Layer Security » en anglais) ou encore un message Handshake QUIC, messages connus en soi. Ceci est transparent pour l’utilisateur et permet d’économiser la signalisation (et la bande passante) requise pour mettre en œuvre l’invention. En variante, le message en question peut être un message envoyé de façon asynchrone par l’entité de confiance.
Dans un mode particulier de réalisation, ladite au moins une information de joignabilité est incluse dans un entête, une option, une trame (par exemple une trame QUIC), un attribut (par exemple un attribut SDP (Session Description Protocol)), une charge utile (ou « message body » en anglais avec une structure prédéfinie), etc.
Par exemple, dans le contexte d’un message selon le protocole HTTP (HyperText Transfer Protocol), on peut envisager la présence d’un nouvel entête, appelé à titre illustratif DNS_RESOLVER, valorisé avec ladite au moins une information de joignabilité et indiquant à l’équipement client qu’il doit adresser ses futures requêtes DNS dans le cadre du service audit au moins un équipement associé à ladite au moins une information de joignabilité.
Cette variante est relativement simple à mettre en œuvre et s’appuie sur des messages déjà existants. Seul un entête (ou le cas échéant une option, une trame, un attribut ou une charge utile ayant une structure prédéfinie selon la variante envisagée) doit être nouvellement introduit(e) pour les besoins de l’invention.
Il convient de noter que si l’invention a une application privilégiée lorsqu’une version quelconque du protocole HTTP est utilisée, elle peut également être utilisée en association avec d’autres protocoles, comme par exemple avec le protocole CoAP (Constrained Application Protocol) moyennant la définition d’une nouvelle option dédiée à l’invention, ou avec le protocole QUIC, moyennant la définition d’une nouvelle trame dédiée à l’invention.
Dans un autre mode de réalisation, l’information de joignabilité est envoyée dans un message de réponse dédié dont la structure est explicitement indiquée par un nouveau type de média (ou « media type » en anglais tel que par exemple « json+dns-resolver »). Ce type de média indique que le contenu d’un message est de type « JSON » et transporte un serveur DNS.
Dans un autre mode de réalisation, la configuration de l’équipement client peut être mise en œuvre via l’envoi, par l’entité de confiance, d’une liste de noms de domaine potentiellement impliqués lors de l’accès au service par l’équipement client, et des adresses IP qui leur sont respectivement associées, par exemple dans une réponse à un message d’invocation du service ou à une requête DNS. Il convient toutefois de noter que ce mode de réalisation a une implication sur la taille des messages envoyés à l’équipement client, et peut induire, selon le protocole de transport impliqué, une fragmentation.
L’invention offre par ailleurs la possibilité d’indiquer à l’équipement client une pluralité de dispositifs DNS (et notamment d’informations de joignabilité de ces dispositifs DNS), chaque dispositif DNS pouvant être associé à un contexte d’utilisation pour que l’équipement client soit en mesure d’orienter ses requêtes DNS vers le dispositif DNS le mieux adapté en fonction du contexte dans lequel il se trouve (ex. en fonction de sa localisation géographique).
En variante, le message transmis par l’entité de confiance peut comprendre, pour au moins un dit dispositif désigné pour ledit service et autorisé par ladite entité de confiance, au moins une information caractérisant au moins une capacité fonctionnelle dudit dispositif.
Une telle capacité fonctionnelle est par exemple une liste de méthodes, et/ou d’enregistrements (RR), et/ou de protocoles supportés par le dispositif en question.
Cela permet une meilleure distribution des requêtes DNS émises par l’équipement client. Le dispositif DNS est adapté au contexte dans lequel l’équipement client sollicite une résolution de noms de domaine et peut apporter une réponse circonstanciée à l’équipement client.
Selon un deuxième aspect, l’invention vise aussi un procédé de transmission d’au moins une requête de résolution de noms de domaine destiné à être mis en œuvre par un équipement client dans le cadre d’un service fourni via un réseau, ce procédé comprenant :
  • une étape de modification, lors d’un accès au service et sous un contrôle d’une entité de confiance pour le service et/ou l’équipement client, d’une configuration de l’équipement client pour qu’il transmette vers au moins un dispositif désigné pour un traitement des requêtes de résolution de noms de domaine associées au service et autorisé par l’entité de confiance, au moins une requête de résolution de noms de domaine émise par l’équipement client dans le cadre de l’accès au service ; et
  • une étape de transmission d’au moins une requête de résolution de noms de domaine dans le cadre de l’accès au service vers au moins un dit dispositif désigné.
Corrélativement, l’invention concerne également un équipement client d’un réseau comprenant :
  • un module de modification, configuré pour modifier, lors d’un accès à un service fourni via le réseau et sous un contrôle d’une entité de confiance pour le service et/ou l’équipement client, une configuration de l’équipement client pour qu’il transmette vers au moins un dispositif désigné pour un traitement des requêtes de résolution de noms de domaine associées au service et autorisé par l’entité de confiance, au moins une requête de résolution de noms de domaine émise par l’équipement client dans le cadre de l’accès au service ; et
  • un module de transmission, configuré pour transmettre, au moins une requête de résolution de noms de domaine dans le cadre de l’accès au service vers au moins un dit dispositif désigné.
Dans un mode particulier de réalisation, l’équipement client comprend en outre un module d’obtention, configuré pour obtenir pour au moins un dit dispositif désigné, une information caractérisant au moins une capacité fonctionnelle de ce dispositif, le module de transmission étant configuré pour transmettre ladite au moins une requête de résolution de noms de domaines vers un dit dispositif sélectionné en fonction de ladite au moins une capacité fonctionnelle de ce dispositif.
Le procédé de transmission et l’équipement client bénéficient des mêmes avantages cités précédemment que le procédé de contrôle et l’entité de confiance.
Dans un mode particulier de réalisation, les procédés de contrôle et de transmission sont mis en œuvre par un ordinateur.
L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une entité de confiance conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de contrôle tel que décrit ci-dessus.
L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans équipement client conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de transmission tel que décrit ci-dessus.
Chacun de ces programmes peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash.
D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.
Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'information ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de contrôle ou de transmission selon l’invention.
Selon un autre aspect encore, l’invention vise un système d’accès à un service fourni via un réseau comprenant :
  • une entité de confiance selon l’invention ;
  • un équipement client selon l’invention ; et
  • au moins un dispositif désigné pour un traitement des requêtes de résolution de noms de domaine associées au service et autorisé par l’entité de confiance avec lequel est configuré l’équipement client par l’entité de confiance pour transmettre au moins une requête de résolution de noms de domaine dans le cadre de l’accès au service.
On peut également envisager, dans d'autres modes de réalisation, que les procédés de contrôle et de transmission, l’entité de confiance, l’équipement client et le système selon l’invention présentent en combinaison tout ou partie des caractéristiques précitées.
D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
la représente, dans son environnement, un système d’accès à un service via un réseau conforme à l’invention, dans un mode particulier de réalisation ;
la représente schématiquement l’architecture matérielle d’un ordinateur pouvant héberger l’une quelconque des entités selon l’invention appartenant au système de la ; et
la représente les principales étapes d’un procédé de contrôle et d’un procédé de transmission selon l’invention dans un mode particulier de réalisation dans lequel ils sont mis en œuvre par les entités du système de la .
Description de l’invention
La représente, dans son environnement, un système d’accès 1 à un service S fourni via un réseau NW, conforme à l’invention, dans un mode particulier de réalisation. Il convient de noter que le réseau NW peut être composé d’un ou des plusieurs (sous-)réseaux connectés entre eux.
Dans l’exemple envisagé à la , le service S est un service applicatif proposé via le réseau Internet par un fournisseur de service SP à un équipement client 2 d’un utilisateur U, conforme à l’invention. Aucune limitation n’est attachée à la nature du service S ainsi fourni (ex. service web, service de voix sur IP, service WebRTC, etc.), ni à la nature de l’équipement client 2 utilisé pour y accéder (ex. téléphone intelligent (ou « smartphone » en anglais), ordinateur fixe ou portable, tablette numérique, etc.).
Pour fournir le service S, le fournisseur de service SP s’appuie sur une infrastructure de service hébergée dans un domaine de service SR (ou « Service Realm » en anglais). Par souci de simplification, on considère ici que le domaine SR de service comprend un serveur autoritaire 3 (ou « authoritative server » en anglais) avec lequel, pour accéder au service S, l’utilisateur U établit une connexion dite principale (C1) via son équipement client 2. Cette hypothèse n’est toutefois pas limitative en soi, l’invention s’applique également lorsque le domaine de service SR comprend une pluralité de serveurs (ex. serveur autoritaire, serveurs de cache, répartiteurs de charge (ou « load balancers » en anglais), etc.) hébergés dans une seule structure (par exemple une infrastructure d’informatique en nuage ou « cloud computing » en anglais) ou un seul équipement, ou dans plusieurs structures ou plusieurs équipements. Le service S peut également se trouver dans un autre réseau que le réseau Internet, par exemple dans un réseau d’un opérateur ou dans une infrastructure publique (ex. cloud public ou « public cloud » en anglais).
Dans l’exemple envisagé ici, on suppose que pour accéder au réseau Internet et au service S, l’équipement utilisateur 2 est connecté directement à un réseau d’un opérateur, et plus particulièrement à un réseau AN d’accès cellulaire ou PLMN (pour « Public Land Mobile Network » en anglais) administré par un opérateur OP. Cette hypothèse n’est toutefois pas limitative en soi, et en variante, l’équipement utilisateur 3 peut être connecté au réseau Internet via un réseau local (ou LAN pour « Local Area Network » en anglais) tel qu’un réseau domestique, un réseau d’entreprise, etc., par l’intermédiaire d’un équipement dédié désigné par CPE (pour « Customer Premises Equipment » en anglais). 
On suppose ici que lorsque l’équipement utilisateur 2 se connecte au réseau AN de l’opérateur OP pour bénéficier d’une connectivité réseau, l’opérateur OP configure l’équipement utilisateur 2 avec une information de joignabilité (ex. adresse(s) IP, nom de domaine, alias, identifiant d’authentification, etc.) d’un serveur DNS 4 dit nominal à utiliser pour résoudre ses requêtes DNS, quel que soit le service auquel l’équipement client 2 souhaite accéder. Cette information de joignabilité peut éventuellement être modifiée par l’utilisateur U, via une interface utilisateur prévue à cet effet, pour remplacer le serveur DNS 4 nominal par un serveur DNS public 5, accessible via le réseau Internet.
Cette configuration DNS de l’équipement client 2 (que ce soit avec le serveur DNS 4 nominal ou avec le serveur DNS public 5) est réalisée indépendamment de tout accès à un service par l’équipement client 2, par exemple préalablement à tout accès à un service (notamment pour la configuration avec le serveur DNS nominal 4), autrement dit avant toute invocation ou consommation du service par l’équipement client 2, et s’applique ici une fois réalisée, quel que soit le service auquel l’équipement client 2 accède. On la désigne ici par « configuration DNS nominale ».
On note que par souci de simplification, on a considéré dans la configuration DNS nominale un seul serveur DNS nominal 4. Il est toutefois possible de définir dans cette configuration DNS nominale plusieurs serveurs DNS qui peuvent être sélectionnés en fonction de l’interface réseau utilisée par l’équipement client 2 pour accéder à un service.
Comme évoqué précédemment, le système 1 d’accès au service S permet de contrôler la configuration DNS de l’équipement client 2 pour l’adapter au service S. Ce contrôle a lieu lors de l’invocation par l’équipement client 2 du service S, comme détaillé davantage ultérieurement. A cet effet, le système 1 comprend outre l’équipement client 2, une entité 6 de confiance, conforme à l’invention.
Dans le mode de réalisation décrit ici, l’entité 6 de confiance est une entité avec laquelle le fournisseur SP du service S a une relation de confiance. Il peut s’agir par exemple d’une entité gérée par le fournisseur SP du service S ou d’une entité avec laquelle il dispose d’une relation de sécurité. Une telle entité est par exemple une entité 7 de coordination du service S se trouvant dans le domaine de service SR, ou encore le serveur autoritaire 3.
C’est cette entité 6 de confiance qui, conformément à l’invention, est en mesure d’autoriser au moins un dispositif référencé de manière générale par 8 (aussi parfois désigné par « dispositif DNS 8 » dans la suite), désigné spécifiquement pour le service S, à résoudre les requêtes DNS de l’équipement client 2 et à contrôler la configuration DNS de l’équipement client 2 pour qu’il adresse les requêtes DNS qu’il a dans le cadre de l’accès au service S à ce ou ces dispositifs DNS 8 pour la résolution des noms de domaine visés par ces requêtes DNS. La façon dont le ou les dispositifs DNS 8 sont choisis est décrite plus en détail ultérieurement. Ils peuvent différer d’un équipement client à un autre. Les dispositifs DNS 8 appartiennent conformément à l’invention au système 1 d’accès au service S.
Dans le mode de réalisation décrit ici, l’équipement client 2 et l’entité 6 de confiance pour le service S ont l’architecture matérielle d’un ordinateur 9 telle qu’illustrée à la . On note qu’en variante, l’équipement client 2 et/ou l’entité 6 de confiance peuvent être des instances logicielles hébergées par un équipement physique ayant l’architecture matérielle de l’ordinateur 9.
L’ordinateur 9 comprend notamment un processeur 10, une mémoire vive 11, une mémoire morte 12, une mémoire non volatile 13, et des moyens de communication 14 permettant notamment aux entités du système 1 de communiquer entre elles.
La mémoire morte 12 de l’ordinateur 9 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 10 et sur lequel est enregistré un programme d’ordinateur conforme à l’invention.
Plus spécifiquement, la mémoire morte 12 de l’ordinateur 9 comprend, lorsque ce dernier est ou héberge une entité 6 de confiance conforme à l’invention, un enregistrement d’un programme d’ordinateur PROG6, comportant des instructions définissant les principales étapes d’un procédé de contrôle selon l’invention.
Ce programme PROG6 définit des modules fonctionnels de l’entité 6 de confiance qui s’appuient sur ou commandent les éléments matériels 10 à 14 de l’ordinateur 9 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici :
  • un module 6A d’autorisation, configuré pour autoriser au moins un dispositif DNS 8 désigné pour le service S à résoudre des noms de domaine qui lui sont adressés par l’équipement client 2 dans le cadre du service S. Selon le contexte d’application de l’invention, le ou les dispositifs DNS 8 en question peuvent avoir été choisis par l’entité 6 de confiance ou par une autre entité, puis validés et autorisés par l’entité 6 de confiance. Aucune limitation n’est attachée à la façon dont le module 6A d’autorisation autorise, ou de façon équivalente, valide l’intervention du ou des dispositifs DNS 8. Par exemple, si ceux-ci ont été sélectionnés par une autre entité, cette validation peut résulter de l’existence d’une relation de sécurité ou de confiance avec cette autre entité, ou de la présence de cette autre entité dans une liste d’entités autorisées par le fournisseur du service S. On peut également envisager un échange sécurisé entre l’entité 6 de confiance et les dispositifs DNS 8 pour vérifier qu’ils sont bien autorisés à agir pour la résolution de noms de domaine dans le cadre du service S, ou la présence de ces dispositifs DNS 8 dans une liste fournie par le fournisseur de service S, etc. ; et
  • un module 6B de contrôle, configuré pour contrôler une configuration DNS de l’équipement client 2 appliquée lors d’un accès par l’équipement client 2 au service S, pour qu’il transmette vers au moins un dit dispositif DNS 8 désigné pour le service S et autorisé par le module 6A d’autorisation de l’entité 6 de confiance, au moins une requête de résolution de noms de domaine émise par l’équipement client 2 dans le cadre de son accès au service S. Les requêtes de résolution de noms de domaine concernées sont définies par des règles de sélection fournies par le module 6B de contrôle à l’équipement client 2. De telles règles de sélection définissent les noms de domaines associés au service S concernés par la configuration, tels que par exemple tous les sous-domaines « *.example.com » ou seulement une partie d’entre eux (ex. « *.piv.example.com). On peut envisager différentes façons pour le module 6B de contrôle de contrôler la configuration DNS de l’équipement client 2. Par exemple, le module 6B de contrôle peut contrôler la configuration DNS de l’équipement client 2 en lui envoyant un message contenant un entête spécifique, par exemple un entête nommé DNS_RESOLVER, cet entête contenant une information de joignabilité (ex. adresse IP, nom de domaine, alias, identifiant d’authentification, etc.) dudit au moins un dispositif DNS 8 désigné pour le service S et indiquant à l’équipement client 2 qu’il doit adresser ses requêtes DNS à ce ou ces dispositifs DNS 8. Ce message peut être envoyé de façon asynchrone (spontanée) par le module 6B de contrôle à l’équipement client 2 ou en réponse à un message d’invocation du service S. Il peut en outre comprendre au moins une information caractérisant une capacité fonctionnelle de chacun des dispositifs DNS 8, comme par exemple une liste des méthodes, ou des enregistrements (RR) ou encore des protocoles supportés par chacun des dispositifs DNS 8. En variante, le module 6B de contrôle peut agir par l’intermédiaire d’une autre entité du réseau pour qu’elle transmette un tel entête DNS_RESOLVER à l’équipement client 2. Dans une autre variante encore, le contrôle peut s’effectuer via la transmission d’une option dédiée ou d’une trame dédiée plutôt qu’un entête DNS_RESOLVER. D’autres variantes encore peuvent être envisagées de façon alternative ou complémentaire.
Les fonctions des modules 6A et 6B sont décrites plus en détail ultérieurement en référence aux étapes du procédé de contrôle selon l’invention.
Lorsque l’ordinateur 9 est ou héberge une équipement client 2 conforme à l’invention,
la mémoire morte 12 de l’ordinateur 9 comprend alors un enregistrement d’un programme d’ordinateur PROG2, comportant des instructions définissant les principales étapes d’un procédé de transmission selon l’invention.
Ce programme PROG2 définit des modules fonctionnels de l’équipement client 2 qui s’appuient sur ou commandent les éléments matériels 10 à 14 de l’ordinateur 9 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici :
  • un module 2A de stockage d’une configuration DNS, comprenant l’information de joignabilité (ex. adresse IP, nom de domaine, alias, identifiant d’authentification, etc.) d’un ou de plusieurs serveurs DNS à utiliser pour la résolution de noms de domaine. Le module 2A de stockage comprend ici, suite à la connexion de l’équipement client 2 au réseau AN, l’information de joignabilité, et plus particulièrement l’adresse IP, du serveur DNS nominal 4 (ou d’un serveur DNS nominal en cas de pluralité de serveurs DNS nominaux). En variante, si l’utilisateur U de l’équipement client 2 a modifié cette configuration, le module 2A de stockage peut comprendre l’information de joignabilité du serveur DNS public 5. En tout état de cause, le module 2A de stockage comprend l’information de joignabilité du serveur DNS de la configuration DNS nominale, introduite précédemment ;
  • un module 2B de modification, configuré pour modifier, en cours d’accès au service S et sous le contrôle de l’entité 6 de confiance, la configuration DNS de l’équipement client 2 applique pour résoudre ses requêtes DNS pour que l’équipement client 2 transmette vers au moins un dispositif DNS 8, désigné pour le service S et autorisé par l’entité 6 de confiance, au moins une requête de résolution de noms de domaine dans le cadre du service S. Dans le mode de réalisation décrit ici, la configuration DNS, incluant les règles de sélection des requêtes DNS concernées et définies par le module 6B de l’entité 6 de confiance (autrement dit celles associées au service S) et la ou les informations de joignabilité du ou des dispositifs DNS 8, est enregistrée dans un cache 2D local de l’équipement client 2. Chaque entrée du cache 2D fait correspondre une configuration DNS à un service donné et est associée ici à une durée de validité : tant que la durée de validité d’une entrée n’est pas expirée, elle est appliquée par l’équipement client 2 pour le service concerné, ce qui est avantageux en cas d’invocation récurrente dudit service comme illustré ultérieurement. On note que les règles de sélection associées à chaque configuration DNS permettent avantageusement de distinguer les configurations DNS stockées dans le cache 2D local et qui peuvent concerner plusieurs services distincts, et d’ainsi permettre à l’équipement client 2 d’appliquer, en fonction du service concerné, la bonne configuration DNS. En variante, on peut envisager un cache local par service ; et
  • un module 2C de transmission, configuré pour transmettre au moins une requête de résolution de noms de domaine dans le cadre de l’accès au service S (c’est-à-dire correspondant aux règles de sélection précitées) vers l’un des serveurs DNS identifié dans la configuration DNS stockée dans le cache local 2D. Ainsi, avant exécution de l’invention, le module 2C de transmission est configuré pour transmettre ses requêtes DNS vers le serveur DNS nominal 4 ou vers le serveur DNS public 5 selon la configuration DNS nominale adoptée et mémorisée dans le module de stockage 2A ; après exécution du procédé de contrôle selon l’invention, le module 2C de transmission est configuré pour transmettre ses requêtes DNS émises dans le cadre de l’accès au service S vers l’un des dispositifs DNS 8 autorisés par l’entité 6 de confiance identifiés dans le cache local 2D. Dans le mode de réalisation décrit ici, si plusieurs dispositifs DNS 8 sont autorisés par l’entité 6 de confiance dans le cadre de l’accès au service S, le module 2C de transmission est configuré pour obtenir au moins une information caractérisant une capacité fonctionnelle de chacun des dispositifs DNS 8 autorisés (ex. liste de méthodes, d’enregistrements RR ou de protocoles supportés par chacun des dispositifs DNS 8) et pour sélectionner l’un d’entre eux en fonction de ses capacités fonctionnelles. Ces informations sur les capacités fonctionnelles des dispositifs DNS 8 peuvent être stockées dans la configuration DNS mémorisée dans le cache local 2D. En variante, d’autres critères de sélection peuvent être envisagés, tel que par exemple, la localisation du serveur DNS par rapport à celle de l’équipement client 2, etc.
Les fonctions des modules 2A à 2C sont décrites plus en détail ultérieurement en référence aux étapes du procédé de transmission selon l’invention.
Nous allons maintenant décrire, en référence à la , les principales étapes d’un procédé de contrôle et d’un procédé de transmission selon l’invention telles qu’elles sont mises en œuvre respectivement par l’entité 6 de confiance et par l’équipement client 2 du système 1 dans un mode particulier de réalisation.
Dans l’exemple illustré à la , on suppose que les entités du système 1 et du réseau utilisent pour communiquer entre elles une version du protocole HTTP. Toutefois, cette hypothèse n’est pas limitative en soi, l’invention s’applique en combinaison avec d’autres protocoles, comme par exemple le protocole CoAP, le protocole QUIC, etc.
Par ailleurs, dans l’exemple envisagé à la , l’entité 6 de confiance est le serveur autoritaire 3.
Comme mentionné précédemment, on suppose en préliminaire que l’équipement client 2 est configuré pour utiliser la configuration DNS nominale introduite précédemment, autrement dit pour transmettre ses requêtes de résolution de noms de domaine ou requêtes DNS vers le serveur DNS nominal 4. En d’autres termes, le cache local 2D ne contient aucune configuration DNS alternative à la configuration DNS nominale à appliquer dans le cadre de l’accès au service S.
Ainsi, lorsque l’équipement client 2 souhaite accéder au service S, et établir notamment une connexion avec le serveur autoritaire 3, il adresse, par l’intermédiaire de son module de transmission 2C, une requête DNS désignée par QUERY(3), à son serveur DNS nominal 4 (étape H10). Le serveur DNS nominal 4 lui répond, de façon connue en soi, en fournissant une adresse IP, notée @IP3, du serveur autoritaire 3 (étape H20). Il peut notamment pour lui fournir cette réponse contacter des serveurs DNS récursifs si besoin.
Après avoir établi une connexion avec le serveur autoritaire 3 de façon connue en soi (connexion sous-jacente au service), par exemple via un échange reposant sur les protocoles TCP et TLS, l’équipement client 2 envoie alors une requête HTTP POST d’accès au service S au serveur autoritaire 3 en utilisant comme adresse de destination l’adresse IP @IP3 qui lui a été transmise (étape H30).
Comme mentionné précédemment, dans l’exemple envisagé ici, le serveur autoritaire 3 agit en tant qu’entité 6 de confiance selon l’invention. Il comprend par conséquent les modules 6A et 6B de l’entité 6 de confiance décrits précédemment.
Ainsi, sur réception de la requête d’accès HTTP POST de l’équipement client 2, le serveur autoritaire 3 (agissant en tant qu’entité 6 de confiance) traite cette requête. Il consulte par ailleurs son module 6A d’autorisation pour obtenir la ou les informations de joignabilité (ex. adresses IP ici) du ou des dispositifs DNS 8 autorisés pour le service S à résoudre les requêtes DNS émises dans le cadre de l’accès au service S. On suppose ici qu’un nombre K supérieur ou égal à 1 de dispositifs DNS 8 sont concernés. Ces K dispositifs DNS sont référencés respectivement par dispositifs DNS 8-1, 8-2, …, 8-K dans la suite.
Le serveur autoritaire 3 insère alors, via son module 6B de contrôle, dans sa réponse HTTP 200 OK à la requête d’accès HTTP POST reçue de l’équipement client 2, les K adresses IP, @IP8-1, …, @IP8-K des K dispositifs DNS 8 fournis par son module 6A d’autorisation, une indication (explicite ou implicite) que l’équipement client 2 doit envoyer ses futures requêtes DNS émises dans le cadre du service S vers l’un au moins desdits K dispositifs DNS 8, ainsi qu’ici, les règles de sélection des requêtes DNS s’appliquant à ces K dispositifs DNS 8 (autrement dit, les règles qui permettent à l’équipement client 2 de reconnaître les requêtes DNS associées au service S qui doivent être adressées à ces dispositifs DNS 8). Puis il transmet la réponse HTTP 200 OK à l’équipement client 2 (étape H40). Dans le mode de réalisation décrit ici, les adresses @IP8-1, …, @IP8-K sont insérées par le module 6B de contrôle dans l’entête DNS_RESOLVER qui indique en soi à l’équipement client 2 qu’il doit envoyer ses futures requêtes DNS émises dans le cadre du service S vers l’un au moins des dispositifs DNS 8 associés à l’une des adresses @IP8-1, …, @IP8-K. Le module 6B de contrôle insère par ailleurs dans l’entête DNS_RESOLVER en association avec chaque adresse IP, au moins une information caractérisant au moins une capacité fonctionnelle telle que décrite ci-avant du dispositif DNS 8 correspondant à cette adresse IP (ex. une liste de protocoles ou d’enregistrements RR ou encore de méthodes supportées par chaque dispositif DNS 8, ou une combinaison de telles listes). Il peut en outre insérer dans l’entête DNS_RESOLVER une durée de validité associée à la configuration DNS ainsi transmise pour le service S. Il convient toutefois de noter que cette durée de validité est optionnelle et qu’en variante on peut envisager que la configuration DNS s’applique au niveau de l’équipement client 2 tant qu’elle n’est pas modifiée par l’entité 6 de confiance.
Les capacités fonctionnelles peuvent en fonction de leur nature être insérées dans des champs différents de l’entête DNS_RESOLVER. Par exemple, les protocoles de transport supportés par le dispositif DNS 8 considéré dans un champ TRANSPORT_SET, les enregistrements RR dans un champ RR_SET et les méthodes dans un champ QUERY_SET. Bien entendu ces noms ne sont donnés qu’à titre illustratif.
L’insertion de l’entête DNS_RESOLVER dans la réponse HTTP 200 OK à la requête HTTP POST est une étape de contrôle au sens de l’invention par le serveur autoritaire 3 agissant en tant qu’entité 6 de confiance.
On note que l’exemple envisagé ici, l’entête DNS_RESOLVER est inséré dans une réponse à une requête d’accès HTTP POST au service envoyée après l’établissement de la connexion sous-jacente au service S entre l’équipement client 2 et le serveur autoritaire 3. On peut toutefois envisager en variante qu’un tel entête soit inséré dans une réponse à une requête HTTP POST envoyée durant la procédure d’établissement de la connexion sous-jacente au service S. Une telle requête HTTP POST peut par exemple être envoyée dans un message SYN et ClientHello TLS si les mécanismes TCP Fast Open et 0-RTT TLS décrits respectivement dans les documents IETF RFC 7413 et RFC 8446 sont activés.
Dans une autre variante, les indications précédemment citées, portées par l’entête DNS_RESOLVER, sont insérées dans une option TCP et/ou TLS en réponse à une requête d’accès au service ou à une demande d’établissement de la connexion sous-jacente au service S. 
Sur réception de la réponse HTTP 200 OK du serveur autoritaire 3 et détection de l’entête DNS_RESOLVER inclus dans la réponse, le module 2B de modification de l’équipement client 2 modifie la configuration DNS appliquée par l’équipement client 2 (qui correspond ici à celle qui est mémorisée dans le module 2A de stockage en l’absence de configuration DNS associée au service S mémorisée dans le cache local 2D). Plus spécifiquement, il mémorise dans le cache local 2D les adresses @IP8-1, …, @IP8-K des dispositifs DNS 8 compris dans l’entête DNS_RESOLVER à utiliser lors de l’accès au service S ainsi que les règles de sélection permettant à l’équipement client 2 d’identifier les requêtes DNS concernées par ces dispositifs DNS (étape H50).
De la sorte, le module 2C de transmission de l’équipement client 2 adresse les futures requêtes DNS (QUERY(X)) envoyées dans le cadre du service S (par exemple, toutes les requêtes portant sur les sous-domaines « *.example.com » en fonction des règles de sélection définies par l’entité 6 de confiance) à l’un des dispositifs DNS 8 identifiés dans la nouvelle configuration DNS mémorisée dans le cache local 2D (et non plus à son serveur DNS nominal 4 comme lors de l’étape H10, qui peut toutefois continuer d’être sollicité pour des requêtes DNS envoyées dans le cadre d’autres services que le service S et non concernées par la configuration DNS mémorisée dans le cache local 2D) (ex. étapes 60, H70).
On note que ces requêtes DNS peuvent viser un nom de domaine public, mais également un nom de domaine privé que les dispositifs DNS 8 sont adaptés à résoudre, ou un nom de domaine généré dans le cadre du service S pour l’équipement client 2, ou un nom de domaine éphémère généré dans le cadre du service S, etc., ou encore un nom de domaine vérifiant plusieurs de ces caractéristiques. En adaptant la configuration DNS de l’équipement client 2 en fonction du service S, une grande flexibilité est offerte au fournisseur du service S en matière de résolution DNS.
En outre, il convient également de noter que si, avant l’étape H10, le cache local 2D comprend déjà une configuration DNS à appliquer pour le service S différente de la configuration DNS nominale, et que cette configuration DNS est associée dans le cache local 2D à une durée de validité non expirée, alors lors de l’étape H10, l’équipement client 2 applique cette configuration DNS enregistrée dans le cache local 2D et s’adresse directement à l’un des dispositifs DNS 8 pour résoudre sa requête DNS. Ledit dispositif fournit l’adresse @IP3 du serveur autoritaire 3 en réponse à la requête DNS envoyée par l’équipement client 2 lors de l’étape H20. Les étapes H30 et H40 sont maintenues et permettent le cas échéant de prolonger la durée de validité de la configuration DNS déjà mémorisée dans le cache local 2D pour le service S, ou si la configuration DNS s’appliquant au service S a été modifiée par l’entité 6 de confiance, de modifier cette configuration DNS.
Comme évoqué précédemment, si plusieurs dispositifs DNS 8 sont identifiés dans la nouvelle configuration DNS mémorisée par le cache local 2D, pour chaque requête DNS QUERY(X) devant être émise par l’équipement client 2, le module 2C de transmission sélectionne l’un des dispositifs DNS 8 en fonction d’un critère donné. Un tel critère est par exemple ici les capacités fonctionnelles des dispositifs DNS 8.
Ainsi, à titre illustratif, pour K=2, supposons que l’entête DNS_RESOLVER reçu par l’équipement client 2 indique une liste de méthodes supportées par chacun des dispositifs DNS 8-1, 8-2, et plus particulièrement pour le dispositif DNS 8-1 les méthodes HTTP {GET, POST, FETCH}, et pour le dispositif DNS 8-2 les méthodes HTTP {GET, POST}. Alors le module 2C de transmission peut sélectionner indifféremment le dispositif DNS 8-1 ou le dispositif 8-2 pour l’envoi de requêtes DNS GET et POST, et sélectionner le dispositif 8-1 uniquement pour l’envoi de requêtes DNS FETCH.
Selon un autre exemple illustratif pour K=2 toujours, supposons que l’entête DNS_RESOLVER reçu par l’équipement client 2 indique une liste d’enregistrements RR supportés par chacun des dispositifs DNS 8-1, 8-2, et plus particulièrement pour le dispositif DNS 8-1 un enregistrement de type SVCB (« SerViCe Binding », en anglais) tandis que pour le dispositif DNS 8-2 un enregistrement de type MX (« Mail eXchange », en anglais). Alors le module 2C de transmission sélectionne le dispositif DNS 8-1 pour résoudre les requêtes DNS portant sur un enregistrement SVCB.
Selon un autre exemple illustratif encore pour K=2, supposons que l’entête DNS_RESOLVER reçu par l’équipement client 2 indique une liste de protocoles supportés par chacun des dispositifs DNS 8-1, 8-2, et plus particulièrement pour le dispositif DNS 8-1 les protocoles Do53 et DoQ, tandis que pour le dispositif DNS 8-2 les protocoles DoH (DNS over HTTPS) et DoC (DNS over CoAP), le protocole DoT (DNS over TLS), les protocoles Do53, DoQ (DNS over QUIC), DoH et DoC étant connus de l’homme du métier et non détaillés ici. Alors le module 2C de transmission supportant le protocole DoH peut décider de ne sélectionner que le dispositif DNS 8-1 pour résoudre ses requêtes DNS.
En variante, on peut envisager d’autres critères, comme par exemple une sélection aléatoire, ou une sélection d’un dispositif DNS 8 en fonction de sa proximité géographique par rapport à l’équipement client 2, ou encore une combinaison de plusieurs critères, etc.
Dans l’exemple qui vient d’être envisagé, la nouvelle configuration DNS à appliquer est communiquée par le serveur autoritaire 3 / l’entité 6 de confiance à l’équipement client 2 en réponse à sa requête d’accès au service S. Il convient toutefois de noter que cette hypothèse n’est pas limitative en soi et que la nouvelle configuration peut être communiquée à l’équipement client 2 en réponse à tout autre message d’invocation du service S, dès lors qu’il est envoyé pendant que l’équipement client 2 accède au service S. En variante, l’indication d’appliquer la nouvelle configuration DNS peut être transmise par le serveur autoritaire 3 / l’entité 6 de confiance à l’équipement client 2 de façon asynchrone ou spontanée, c’est-à-dire sans être en lien avec un message d’invocation du service S particulier émis par l’équipement client 2.
Par ailleurs, dans l’exemple qui vient d’être décrit, le serveur autoritaire 3 / l’entité de confiance 6 indique lui/elle-même à l’équipement client 2 la nouvelle configuration DNS à appliquer pour le service S, autrement dit le serveur autoritaire 3 / l’entité de confiance 6 modifie directement la configuration DNS appliquée par l’équipement client 2 pour le service S. En variante, la modification au niveau de l’équipement client 2 peut être contrôlée (i.e. décidée) par l’entité 6 de confiance mais être mise en place dans l’équipement client 2 par une entité intermédiaire. Cette entité intermédiaire peut être n’importe quelle entité avec laquelle l’entité 6 de confiance entretient une relation de confiance et/ou sécurisée, telle que par exemple une entité de l’infrastructure de service ou une entité tierce placée notamment sur le chemin des communications emprunté lors de l’accès au service par l’équipement client. Il peut même s’agir de l’un des dispositifs DNS qu’elle a autorisé pour le service.
Il convient également de noter que dans le mode de réalisation qui vient d’être décrit, le service autoritaire 3 / l’entité de confiance 6 est une entité de confiance 6 pour le service, dès lors qu’il s’agit d’une entité de l’infrastructure sur laquelle s’appuie le service. On peut toutefois envisager d’autres entités de confiance que des entités de l’infrastructure de service, comme par exemple une entité désignée par le fournisseur du service ou d’une autre infrastructure avec laquelle le fournisseur du service a établi un accord reposant sur une relation de confiance.
On peut également envisager d’appliquer l’invention dans un contexte où l’entité de confiance qui contrôle la configuration DNS utilisée par l’équipement client 2 lors de son accès au service S est une entité de confiance pour l’équipement client 2. Par exemple, il peut s’agir d’un équipement intermédiaire via lequel l’équipement client 2 établit une connexion avec le réseau Internet pour accéder au service S et avec lequel il a lui-même établi une connexion sécurisée (par exemple chiffrée, ou un tunnel de communication sécurisé) de sorte que tous les messages émis et reçus par l’équipement client 2 lors de l’accès au service S transitent par cet équipement intermédiaire. Un tel équipement intermédiaire peut être à titre illustratif un équipement de type CPE (pour « Customer Premises Equipment » en anglais), ou un relais ou proxy localisé dans l’interface Gi d’un réseau mobile, etc. On peut alors envisager qu’il soit configuré avec une liste de règles lui permettant de sélectionner les dispositifs DNS appropriés pour un service donné. Cette liste de règles peut provenir de mesures effectuées par l’équipement intermédiaire en question ou par un autre équipement permettant à l’équipement intermédiaire de classer les dispositifs DNS en fonction par exemple de leur disponibilité ou de leurs performances.
Nous allons maintenant détailler à titre illustratif plusieurs cas d’usage de l’invention. Ces différents cas d’usage guident ou impactent le choix des dispositifs DNS vers lesquels orienter les requêtes DNS de l’équipement client lors de son accès au service.
Selon un premier cas d’usage, on désigne comme dispositifs DNS pour le service S, des dispositifs du réseau NW via lesquels on souhaite que des connexions établies par l’équipement client dans le cadre du service S transitent. Ces connexions peuvent comprendre la connexion principale établie par l’équipement client avec le serveur autoritaire pour accéder au service, mais également toutes les connexions secondaires établies en marge de cette connexion principale, parfois à l’insu de l’utilisateur de l’équipement client. Les dispositifs DNS ainsi désignés peuvent ainsi résoudre chaque requête DNS émise par l’équipement client 2 en fournissant leurs propres adresses IP de sorte à recevoir chaque paquet de données émis par l’équipement client sur les connexions principale et secondaires. Sur réception de ces paquets de données, ils peuvent ainsi mettre en place divers traitements, comme par exemple l’analyse du contenu de ces paquets pour déterminer s’ils contiennent des informations d’identification de l’utilisateur, ou d’autres informations qu’ils souhaitent traquer. Les dispositifs DNS peuvent aussi en variante résoudre chaque requête émise par l’équipement client en fournissant l’adresse IP d’un autre équipement de confiance chargé de tels traitements. Ce cas d’usage permet de placer des équipements donnés sur le chemin des connexion principale et secondaires établies par l’équipement client dans le cadre du service S.
Selon un deuxième cas d’usage, on désigne comme dispositifs DNS pour le service S, des dispositifs DNS qui ont été configurés pour résoudre entre autres des requêtes de noms de domaine afférant à des noms de domaine privés et/ou personnalisés et/ou encore éphémères, générés dans le cadre du service S, par exemple par le fournisseur du service. Ces noms de domaine sont volontairement gardés secrets et resteront inconnus des serveurs DNS publics ou nominaux configurés par les opérateurs de réseau. Ce deuxième cas d’usage peut être adopté comme mesure de sécurité pour prévenir des attaques de déni de service par exemple. Il permet également au fournisseur de service d’envisager des noms de domaine personnalisables, et par exemple de générer des noms de domaine personnalisés en fonction de l’identité de l’utilisateur de l’équipement client, ou des noms de domaine éphémères. Le recours à des dispositifs DNS propres au service permet de faciliter l’ajout et/ou le retrait de tels noms de domaine et d’éviter la latence induite par une telle démarche auprès d’un serveur DNS public/nominal.
Selon un troisième cas d’usage, on peut envisager de désigner comme dispositifs DNS pour le service S, des dispositifs DNS qui ont été configurés pour réaliser une résolution personnalisée des requêtes DNS adressées par un équipement client, par exemple dans un souci de respect des contraintes de service. Par exemple, un tel dispositif DNS peut retourner à un équipement client une adresse IP pour un nom de domaine et située à proximité de l’équipement client (par ex. présentant un délai inférieur à « x ms »).
Selon un quatrième cas d’usage, on peut envisager de désigner comme dispositifs DNS pour le service S des dispositifs DNS qui mettent en œuvre des fonctions DNS avancées, qui ne sont pas mises en œuvre par des serveurs DNS publics ou nominaux fournis par les opérateurs de réseau (par exemple qui supporte le protocole DoC, tel que décrit dans le document de M.S. Lenders intitulé « DNS Queries over CoAP (DoC), draft-lenders-dns-over-cap-01 », 1er septembre 2021.
Bien entendu, d’autres cas d’usage de l’invention peuvent être envisagés en complément de ceux qui viennent d’être cités.

Claims (16)

  1. Procédé de contrôle d’un équipement client (2) pour accéder à un service via au moins un réseau, ledit procédé de contrôle étant destiné à être mis en œuvre par une entité (6,3) de confiance pour ledit service et/ou pour ledit équipement client et comprenant une étape de contrôle (H40) d’une configuration dudit équipement client, lors d’un accès de celui-ci audit service, pour qu’il transmette vers au moins un dispositif (8 ;8-1, …, 8-K) désigné pour ledit service et autorisé par ladite entité de confiance, au moins une requête de résolution de noms de domaine émise par ledit équipement client dans le cadre dudit service.
  2. Procédé de contrôle selon la revendication 1 dans lequel ladite entité de confiance (3) est un serveur impliqué dans la fourniture dudit service.
  3. Procédé de contrôle selon la revendication 1 dans lequel ladite entité (6) de confiance est une entité intermédiaire placée sur un chemin de communication emprunté lors de l’accès par ledit équipement client audit service.
  4. Procédé de contrôle selon l’une quelconque des revendications 1 à 3 dans lequel l’étape (H40) de contrôle d’une configuration dudit équipement client comprend une transmission par l’entité de confiance audit équipement client d’un message comprenant au moins une information de joignabilité (@IP8-1, …, @IP8-K) d’au moins un dit dispositif désigné pour ledit service et autorisé par ladite entité de confiance.
  5. Procédé de contrôle selon la revendication 4 dans lequel ledit message est un message de réponse à un message d’invocation dudit service émis par ledit équipement client ou un message envoyé de façon asynchrone par ladite entité de confiance.
  6. Procédé de contrôle selon la revendication 4 ou 5 dans lequel ladite au moins une information de joignabilité est incluse dans un entête, une option, une trame, un attribut, ou une charge utile du message.
  7. Procédé de contrôle selon l’une quelconque des revendications 4 à 6 dans lequel ledit message est conforme à une version d’un protocole HTTP (HyperText Transfer Protocol) ou d’un protocole CoAP (Constrained Application Protocol) ou d’un protocole QUIC.
  8. Procédé de contrôle selon l’une quelconque des revendications 4 à 7 dans lequel ledit message comprend, pour au moins un dit dispositif désigné pour ledit service et autorisé par ladite entité de confiance, au moins une information caractérisant au moins une capacité fonctionnelle dudit dispositif.
  9. Procédé de contrôle selon l’une quelconque des revendications 1 à 8 dans lequel au moins une dite requête de résolution de noms de domaine concerne :
    • un nom de domaine privé ; et/ou
    • un nom de domaine généré dans le cadre dudit service pour ledit équipement client ; et/ou
    • un nom de domaine éphémère.
  10. Procédé de transmission d’au moins une requête de résolution de noms de domaine destiné à être mis en œuvre par un équipement client (2) dans le cadre d’un service fourni via un réseau, ledit procédé comprenant :
    • une étape (H50) de modification, lors d’un accès audit service et sous un contrôle d’une entité de confiance pour ledit service et/ou ledit équipement client, d’une configuration de l’équipement client pour qu’il transmette vers au moins un dispositif désigné pour un traitement des requêtes de résolution de noms de domaine associées au service et autorisé par ladite entité de confiance, au moins une requête de résolution de noms de domaine émise par ledit équipement client dans le cadre dudit service ; et
    • une étape (H60,H70) de transmission d’au moins une requête de résolution de noms de domaine dans le cadre dudit service vers au moins un dit dispositif désigné.
  11. Programme d’ordinateur (PROG6,PROG2) comportant des instructions pour l’exécution d’un procédé de contrôle selon l’une quelconque des revendications 1 à 9 ou d’un procédé de transmission selon la revendication 10, lorsque ledit programme est exécuté par un ordinateur.
  12. Support d’enregistrement (12) lisible par un ordinateur (9) sur lequel est enregistré un programme d’ordinateur selon la revendication 11.
  13. Entité (6) de confiance pour un service et/ou pour un équipement client d’un réseau, ladite entité de confiance comprenant un module (6B) de contrôle, configuré pour contrôler une configuration dudit équipement client lors d’un accès audit service, pour qu’il transmette vers au moins un dispositif désigné pour ledit service et autorisé par ladite entité de confiance, au moins une requête de résolution de noms de domaine émise par ledit équipement client dans le cadre dudit service.
  14. Equipement client (2) d’un réseau comprenant :
    • un module (2B) de modification, configuré pour modifier, lors d’un accès à un service fourni via le réseau et sous un contrôle d’une entité de confiance pour ledit service et/ou ledit équipement client, une configuration de l’équipement client pour qu’il transmette vers au moins un dispositif désigné pour un traitement des requêtes de résolution de noms de domaine associées au service et autorisé par ladite entité de confiance au moins une requête de résolution de noms de domaine émise par ledit équipement client dans le cadre dudit service ; et
    • un module (2C) de transmission, configuré pour transmettre au moins une requête de résolution de noms de domaine dans le cadre dudit service vers au moins un dit dispositif désigné.
  15. Equipement client selon la revendication 14 comprenant en outre un module (2C) d’obtention, configuré pour obtenir pour au moins un dit dispositif désigné, une information caractérisant au moins une capacité fonctionnelle de ce dispositif, ledit module de transmission étant configuré pour transmettre ladite au moins une requête de résolution de noms de domaines vers un dit dispositif sélectionné en fonction de ladite au moins une capacité fonctionnelle de ce dispositif.
  16. Système (1) d’accès à un service fourni via un réseau comprenant :
    • une entité (6) de confiance selon la revendication 13 :
    • un équipement client (2) selon la revendication 14 ou 15 ; et
    • au moins un dispositif (8 ;8-1, …, 8-K) désigné pour un traitement des requêtes de résolution de noms de domaine associées audit service et autorisé par ladite entité de confiance avec lequel est configuré ledit équipement client par ladite entité de confiance pour transmettre au moins une requête de résolution de noms de domaine dans le cadre de l’accès audit service.
PCT/EP2022/081048 2021-11-10 2022-11-08 Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés WO2023083772A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202280074344.XA CN118303013A (zh) 2021-11-10 2022-11-08 控制方法和传输方法以及被配置为实施这些方法的实体
EP22813298.1A EP4430814A1 (fr) 2021-11-10 2022-11-08 Procédés de contrôle et de transmission, et entités configurées pour mettre en ?uvre ces procédés

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2111975 2021-11-10
FR2111975A FR3129051A1 (fr) 2021-11-10 2021-11-10 Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés

Publications (1)

Publication Number Publication Date
WO2023083772A1 true WO2023083772A1 (fr) 2023-05-19

Family

ID=80999528

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/081048 WO2023083772A1 (fr) 2021-11-10 2022-11-08 Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés

Country Status (4)

Country Link
EP (1) EP4430814A1 (fr)
CN (1) CN118303013A (fr)
FR (1) FR3129051A1 (fr)
WO (1) WO2023083772A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150271031A1 (en) * 2014-03-20 2015-09-24 NSONE Inc. Systems and methods for improving domain name system traffic routing
US20190166210A1 (en) * 2016-05-10 2019-05-30 Orange Method for accessing a content hosted on a server selected as a function of the location of the user terminal

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150271031A1 (en) * 2014-03-20 2015-09-24 NSONE Inc. Systems and methods for improving domain name system traffic routing
US20190166210A1 (en) * 2016-05-10 2019-05-30 Orange Method for accessing a content hosted on a server selected as a function of the location of the user terminal

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
M.S. LENDERS, DNS QUERIES OVER COAP (DOC), DRAFT-LENDERS-DNS-OVER-CAP-01, 1 September 2021 (2021-09-01)

Also Published As

Publication number Publication date
FR3129051A1 (fr) 2023-05-12
CN118303013A (zh) 2024-07-05
EP4430814A1 (fr) 2024-09-18

Similar Documents

Publication Publication Date Title
EP3568989A1 (fr) Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés
EP3568966B1 (fr) Procédés et dispositifs de délégation de diffusion de contenus chiffrés
FR3081653A1 (fr) Procede de modification de messages par un equipement sur un chemin de communication etabli entre deux noeuds
WO2018115647A1 (fr) Validation de livraison de contenu et de verification d'une delegation de livraison d'un contenu
WO2023083772A1 (fr) Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés
FR3023098A1 (fr) Procede et systeme de traitement d'une demande de resolution d'un nom d'un serveur, emise par une application cliente sur un reseau de communication.
WO2021123593A1 (fr) Procede de resolution d'identifiants de nommage
WO2021176166A1 (fr) Procede et dispositif de detection de l'usage d'un serveur de noms de domaine non certifie
WO2023083771A1 (fr) Procédés de contrôle, de vérification et de configuration, et entités configurées pour mettre en œuvre ces procédés
WO2019243706A1 (fr) Procédé de découverte de fonctions intermédiaires et de sélection d'un chemin entre deux équipements de communication
WO2020128239A1 (fr) Procédé de détermination d'une chaîne de délégation associée à une résolution d'un nom de domaine dans un réseau de communication
EP3900305A1 (fr) Procédé d'acquisition d'une chaîne de délégation relative à la résolution d'un identifiant de nom de domaine dans un réseau de communication
WO2023083769A1 (fr) Procédé de traitement d'au moins un paquet de données, dispositif et système associés.
EP3149902B1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
WO2024068722A1 (fr) Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants
WO2023083770A1 (fr) Procédé de recherche de données sensibles dans au moins un paquet de données, dispositif et système associés
FR3067538A1 (fr) Procede de controle de l'obtention par un terminal d'un fichier de configuration
WO2024156613A1 (fr) Procédé de révocation d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants
WO2023247459A1 (fr) Procédé de suspension d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants
WO2024083694A1 (fr) Procédé de traitement d'une requête en résolution d'au moins un identifiant de nommage, dispositif et programme d'ordinateur correspondants
FR2893208A1 (fr) Procede et dispositif de fourniture d'un alias de federation d'identite reseau a un fournisseur de service

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22813298

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202280074344.X

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 18708760

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2022813298

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022813298

Country of ref document: EP

Effective date: 20240610