FR3023098A1 - METHOD AND SYSTEM FOR PROCESSING A REQUEST FOR RESOLUTION OF A NAME OF A SERVER, ISSUED BY A CLIENT APPLICATION ON A COMMUNICATION NETWORK. - Google Patents

Abstract

Method for processing a request for resolving a name of a server (18), sent by a client application (11) installed on a client terminal (1), over a communication network. This method comprises the steps of: a) obtaining by a first network entity (11, 12) a set of DNS messages following the request for resolution; b) - obtaining by the first network entity (11,12) network connectivity information relating to at least the client terminal or the server (18), and generating a code, said marking, representative of the network connectivity information ; c) - processing by the first network entity (11,12) of the set of DNS messages according to the marking code, and sending accordingly a set of DNS messages, said marked, to a second network entity (14 ); d) - processing by the second network entity (14) of the set of marked DNS messages, in order to deliver to the client application (11) at least one DNS response adapted according to the network connectivity information.

Description

TECHNICAL FIELD The invention relates generally to the field of client-server type communications in an Internet Protocol (IP) -based communication network. It relates in particular to a method and a system for processing a request for resolution of a name of a server, sent by a client application installed on a client terminal, on a communication network. State of the art Currently in a network based on the Internet protocol (IP) protocol stack, commonly referred to as "IP network", such as the global Internet network, each equipment connected to the network has at least one digital address that allows to uniquely identify it on the network. These addresses are currently of two types "IPv4" and "IPv6". IPv4 corresponds to version 4 of the IP protocol while IPv6 corresponds to version 6 of the IP protocol. A network address of the type IPv4 is coded on four bytes (32 bits). With the growth of the number of users and servers on the Internet with the exhaustion of available IPv4 addresses, this leads to the development of IPv6 allowing the coding of a 16-byte (128-bit) IP address. Moreover, in order to facilitate users searching for computing resources on the Internet without having to know the IP address of these resources (server in particular), a system of naming resources known as DNS (Domain Name System) has been created. The DNS system is described in particular in the IETF RFC 1034 and 1035 specifications. It relies on three essential components: a domain namespace, a distributed server system, called name servers, and client programs called "resolvers" (resolvers in English). The domain name space (Domain Name Space) has a tree structure in which higher-level domains (called TLDs, for Top Level Domain) are defined, attached to a root node represented by a period. Each node of the tree is called a "domain name", each node having a label with a maximum length of 63 characters. The set of domain names thus constitutes an inverted tree where each node is separated from the next by a dot ("."). The full name corresponding to the set of labels of the nodes of a tree, separated by points, and terminated by an end point, is called FQDN (Fully Qualified Domain Name), that is to say "Name of Fully Qualified Domain ". Because IPv6 addresses are more complex than IPv4 addresses, the DNS system has been augmented by "DNS Extensions to IP Support Version 6" extensions that are described in RFC 1886 and 3596. These RFC documents describe the support for the registration. AAAA type (corresponding to an IPv6 address) as well as necessary changes to DNS records for IPv6 support (such as MX records, etc.).

Therefore, in the context of the transition from IPv4 to IPv6 that aims at the progressive replacement of the IPv4 protocol by IPv6 over the Internet, the IPv4 and IPv6 IP network interconnection, brings equipment or network nodes identified by IP addresses. IPv4 or IPv6 type, or by addresses of both types, to communicate with each other. Two approaches are then possible to allow communication between a network device having only IPv6 addresses and a network device having only IPv4 addresses: the "dual stack" and the "protocol translation". Regarding the "double-stack", a device or IP node is said to "dual-stack" (DS) if it embeds the two IPv4 and IPv6 protocol stacks and if it is capable of transmitting, receiving and processing indifferently IPv4 and IPv6 packets.

For protocol translation, the Network Address Translation 64 (NAT64) mechanism, described in the Request for Comments (RFC) 6146 and 6052 published by the Internet Engineering Task Force (IETF), allows an IPv6 client device to attach a IPv4 server equipment. The translation of protocols by NAT64 (Network Address Translation 64) is based on the use of the DNS system or its DNS64 extension described in RFC 6147. With the DNS naming system, an IPv4 server device can be represented by an IPv6 address, even if the service provided by this device is not IPv6 compatible. The IPv6 address assigned to the IPv4 server equipment serves to route IPv6 traffic from an IPv6 client device to a NAT64 protocol translation gateway. The latter is responsible for translating the IPv6 traffic of the client equipment into IPv4 traffic understandable by the IPv4 server equipment. The IPv6 address used to identify IPv4 server equipment in the naming system can be managed statically by the DNS system, or dynamically created or synthesized by the DNS64 system.

Protocol translation is very useful for content providers as well as providers of cloud computing solutions because it allows an IPv4 service to be reachable by IPv6 client devices, even if the infrastructure service itself is not IPv6 compatible. However, this approach has limitations. Indeed, since operating systems are generally configured to favor IPv6, a "dual stack" client device will prefer the IPv6 address of an IPv4 server device, if it is represented in the IPv4 naming system. both types of addresses (IPv4 and IPv6). As a result, a "double stack" client will generate essentially IPv6 traffic which will be routed to a protocol translation gateway, even though a native IPv4 path, that is to say that does not require protocol translation, exists . This results, on the one hand, in a possible degradation of service for the customer "double stack". Indeed, the protocol translation offers a service "at best" (best effort) which is accompanied by a loss of information, related in particular to the quality of service (QoS). On the other hand, this implies an additional traffic load on the protocol translation gateway, which increases the costs and investments for the service provider or the operator. Thus, in the current context of IPv4 and IPv6 transition, the resolution of a domain name requested by a client application to reach a remote server may result in the latter obtaining several addresses, IPv4 and IPv6, making it possible to join the remote server. There arises the problem of the selection by the client application of the IP address among IPv4 and IPv6 addresses returned by a domain name server, in order to make possible or optimize the communication between the client application and the remote server, in terms of quality of service (QoS) and the quality of the user experience (QoE or perceived quality). DISCLOSURE OF THE INVENTION The present invention aims to improve in particular the situation described above by proposing, according to a first aspect, a method of processing a request for resolution of a name of a server, issued by a client application installed on a client terminal, on a communication network. According to the invention, this method comprises the steps of: a) obtaining by a first network entity of a set of DNS messages following the request for resolution; b) obtaining by the first network entity network connectivity information relating to at least the client terminal or the server, and generating a code, said marking, representative of the aforementioned network connectivity information; c) - processing by the first network entity of the set of DNS messages according to the marking code, and sending accordingly a set of DNS messages, said marked, to a second network entity; d) - processing by the second network entity of said set of marked DNS messages, in order to deliver to the client application at least one DNS response adapted according to said network connectivity information. The obtaining by the first network entity of network connectivity information relating to at least the client terminal or the remote server to which the client terminal is trying to access, makes it possible to act, via the aforementioned marking code, or on the DNS requests (generated for example by a resolver module of the terminal after reception of the request for resolution), or directly on the DNS responses generated by the processing of the aforementioned DNS requests (for example by an authoritative DNS server), so that the answers DNS actually received by the client application of the terminal are adapted, depending on the implementation, to the IP connectivity constraints of the client terminal, to the IP traffic exchanged between the client application and the server, and to the connectivity constraints of the remote server .

According to a first embodiment of the invention, in the above step a) the set of DNS messages is a set of DNS queries generated following the reception by a DNS resolution module of the name resolution request; and in step b), the network connectivity information includes at least one type and preference information of active IP interface usage for said client terminal.

According to this embodiment, it is the DNS requests that undergo a specific processing to cause the obtaining of DNS responses adapted in particular to the network constraints of the client terminal, which are defined by at least one type of information and preference of use of the client. Active IP interface for the client terminal. According to a first embodiment of the first embodiment, step c) of processing the set of DNS queries includes the insertion of the marking code in each request of the set of DNS queries, within a given field of the body of the request, thus forming a set of marked requests. In practice according to an embodiment characteristic, this field is an RDATA field of the request body according to the DNS protocol EDNSO extension.

In this variant embodiment, the processing step d) comprises reading the marking code contained in each request of the set of marked requests, and then searching for DNS records conforming to the connectivity information obtained from the code of marking. If at least one such record is found, at least one DNS response is generated, this response containing the record. This (at least one) DNS response is then sent to the client application. Thus, by marking the DNS requests according to the network connectivity constraints of the client terminal, the DNS responses are for example selected according to their adequacy with the network constraints of the client terminal. According to a second variant embodiment of the first embodiment, the processing step c) includes filtering the set of DNS queries according to the marking code. According to this variant, no information is inserted in the body of the DNS queries, the DNS queries undergo only a filtering, for example those corresponding to an IP interface associated with a degree of low usage preference are deleted before sending to the second network entity, in order to obtain DNS responses conforming to the IP interface usage preferences of the client terminal. According to various implementations of this first embodiment, the first network entity is located in the client terminal or in a local DNS server vis-à-vis the client application, and said second network entity is located in an authoritative DNS server. for the domain associated with the server. According to a second embodiment of the invention, in step a) the set of DNS messages is a set of DNS responses generated by the first network entity, following the reception of a set of DNS queries generated by a DNS resolution module following the receipt of the name resolution request; and, in step b), the network connectivity information is characteristic of a type of IP address identifying the server contained in each DNS response of the response set. According to this second embodiment, step c) of processing, by the first network entity of each DNS response, comprises the insertion of the marking code within a given field of the body of the response, thus forming a set of marked responses, then sending the set of marked DNS responses to the second network entity. In this second embodiment, it is thus only the DNS responses that are tagged according to the invention so as to contain network connectivity information relating to the remote server, and once these DNS responses transmitted to the client terminal, the application client can advantageously confront this connectivity information related to the remote server with its own connectivity constraints, in order to choose at least one IP address contained in a DNS response, to communicate with the remote server under optimal conditions in terms of quality of service and network performance.

In practice, in this embodiment, the aforementioned field is an RDATA field of the response body according to the DNS protocol EDNSO extension. According to an embodiment characteristic of this embodiment, the processing step d) performed by the second network entity comprises: obtaining information indicative of network connectivity preference for the client terminal; comparing the marking code contained in each response of the set of marked responses with the information indicative of network connectivity preference for the client terminal, then the selection of the DNS responses satisfying the information indicative of network connectivity preference for the terminal customer.

According to various implementations of this second embodiment, the first network entity is located in an authoritative DNS server for the domain associated with the server, and the second network entity is located in the client terminal, for example in the client application, or in the client terminal. a DNS server, local vis-à-vis the client application. According to a second aspect, the invention relates to a system for processing a request for resolution of a name of a server, issued by a client application installed on a client terminal, on a communication network, this system comprising: at least one first network entity comprising: a module for obtaining a set of DNS messages following the request for resolution; a module for obtaining network connectivity information relating at least to said client terminal or to the server, and for generating a code, referred to as a marking code, representative of this network connectivity information; and a module for processing the set of DNS messages according to the marking code, in order to obtain a set of DNS messages, said to be marked; at least one second network entity comprising: a module for receiving said set of marked DNS messages from this at least one first network entity; and a processing module of the set of marked DNS messages, in order to deliver to the client application at least one DNS response adapted according to the network connectivity information. According to a third aspect, the invention relates to a first network entity as defined above, implemented in a system for processing a request for resolving a name of a server, according to the invention. According to a fourth aspect, the invention relates to a second network entity as defined above, implemented in a system for processing a request for resolving a name of a server, according to the invention.

In practice, the means constituting the invention which are included in the various entities (also called nodes) network mentioned above, and in particular the modules implemented in a "first" or a second "entity" according to the invention, such that described briefly above, are essentially implemented in software form that is to say one or more computer programs stored in one or more memories, type RAM (Random Access Memory), ROM (Read Only Memory) or magnetic type (hard disk for example), and executed by a processor embedded in the considered network entity. Therefore, according to a fifth aspect, the present invention is also directed to a computer program implemented by a network entity on a communication network, this program comprising code instructions for the implementation of steps a), b) , c) and / or d) a method of processing a request for resolution of a name of a server, as defined above, when this program is executed by a processor equipping the considered network entity. Finally, the invention also provides a computer-readable information recording medium, comprising instructions of a computer program according to the invention. Such a recording medium may be constituted by any entity or device capable of storing such a program. For example, the medium may include storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a removable recording means such as a USB key or a recording medium magnetic, such as a hard disk. On the other hand, a software module according to the invention can in particular be downloaded to an Internet type network. The benefits of using a system for processing a request to resolve a name of a server, a first or a second client module network entity, as well as a program for computer, according to the invention, as briefly discussed above, are identical or contribute to those mentioned above in connection with the processing method of processing a request for resolution of a name of a server, according to the invention, and therefore will not be recalled here.

BRIEF DESCRIPTION OF THE FIGURES Other features and advantages of the present invention will be apparent from the following detailed description, which refers to the accompanying drawings, in which: FIG. 1 represents the topography of a network environment in which the present invention is implemented; FIG. 2 represents a network environment according to a first variant of a first embodiment of the invention; FIG. 3 represents a network environment according to a second variant of the first embodiment of the invention; FIG. 4 is a flowchart illustrating a method of processing an access request to a remote server according to the first embodiment of the invention; FIGS. 5 and 6 respectively represent the format of a standard DNS query and the format of a DNS query marked according to the DNS protocol, applicable to the first embodiment of the invention; FIG. 7 represents a network environment according to a first variant of a second embodiment of the invention; FIG. 8 represents a network environment according to a second variant of the second embodiment of the invention; FIG. 9 is a flowchart illustrating a method of processing an access request to a remote server according to the second embodiment; and FIG. 10 represents the format of a DNS response, applicable to the second embodiment of the invention. DETAILED DESCRIPTION OF THE INVENTION The following is an explanation of the DNS system described in particular in the IETF RFC 1034 and 1035 specifications. As mentioned before, it relies on three essential components: a domain namespace, a distributed server system, called name servers, and client programs called "resolvers" (resolvers in English).

The domain name space (Domain Name Space) has a tree structure in which higher-level domains (called TLDs, for Top Level Domain) are defined, attached to a root node represented by a period. Each node of the tree is called a "domain name", each node having a label with a maximum length of 63 characters. The set of domain names thus constitutes an inverted tree where each node is separated from the next by a dot ("."). The full name corresponding to the set of labels of the nodes of a tree, separated by points, and terminated by an end point, is called FQDN (Fully Qualified Domain Name), that is to say "Name of Fully Qualified Domain ".

The maximum depth of the tree is 127 levels and the maximum length of a FQDN name is 255 characters. Thus a name FQDN uniquely identifies a machine on the Internet, and thus identifies a service provided by a server on the network. For example, the address "www.orange.fr" represents a name FQDN. Name Servers are machines that map a domain name to one or more IP addresses that identify machines or devices on a network. Each domain has a name server called a primary domain name server, and usually a secondary domain name server, to take over from the primary name server if unavailable. of the last. Each name server is declared in an immediately higher-level domain name server, which implicitly allows for delegation of authority over the domains. DNS is a distributed architecture, where each entity is responsible for managing its domain name. A server that has all the information about a domain is referred to as an authoritative or authoritative server for that domain. The name server that is authoritative for the domain associated with the node under the root (for example the ".fr" node in the "www.orange.fr" address) is called a higher-level domain server or "TLD server". (Top Level Domain server). Finally, a server with authority over the domain above the top-level domain is called a "root server". Thus, a name server defines an area, that is to say a set of domains on which the server has authority, it is then said "authoritative" (authoritative) for this area. In the DNS system, the mechanism to obtain an IP address (for example: 193.43.55.67) of a network equipment (for example a multimedia content server) considered, from a domain name assigned to this equipment (eg 'srv.mycompany.com') is referred to as "domain name resolution", the opposite process (obtaining a domain name from an IP address) being referred to as "reverse resolution". In order to be able to solve a domain name, each client machine such as a user terminal must be equipped with an application called resolver (resolver) generally integrated into the operating system of the machine. When a client application such as an internet browser wants to connect to a host known by its domain name (for example "www.orange.fr"), it will query a name server defined in its network configuration. Each machine connected to the network has indeed in its configuration the IP addresses of at least one name server of its ISP. This name server is usually called "local name server". Thus, in the example of the address "www.orange.fr" the client application (internet browser for example) sends a request to the local name server. If it has the record in its cache, it sends it to the client application, otherwise it can query a TLD server corresponding to the domain ".fr". The TLD Name Server then returns a list of IP addresses from the authoritative name servers on the ".fr" domain to then determine the authoritative name server on the ".orange" domain. The local name server then queries the latter in order to obtain the IP address of the server whose FQDN is "www.orange.fr". The address resolution mechanism as explained above, is based on a communication protocol, the DNS protocol, including the definition of DNS messages of different types (query, response in particular) and information (Resource Records - RR) associated with each domain name, and recorded in a specific DNS records (or Resource Records - RR) format in the distributed database formed by all the domain name servers. The format of DNS (RR) records and DNS messages is detailed in IETF RFC 1035, particularly sections 3.2 and 4. Figure 1 shows a network environment in which the present invention can be implemented. artwork. In this environment, a client application 11 installed on a user terminal 1 must establish a communication with a remote server 18. To communicate with the server 18, the client application 11 uses the FQDN name associated with the server 18, which it transmits to a domain resolver resolution module (resolver) installed on the terminal. The resolution module 11a is responsible for obtaining at least one IP address associated with the server 18, which the client application 11 will have to use to exchange data with the server. Once the server IP address or addresses 18 have been sent to the user terminal 1, the resolution module 11a caches the obtained IP addresses before sending them to the application 11, which will use them in the order of their reception, in order to communicate with the server 18. It is specified here that is meant: - by "client application" (11), any software application installed on a communicating equipment, such as for example, a web browser, a client FTP (File Transfer Protocol), a mail client, etc. ; - "Equipment communicating" any computer device such as for example a user terminal (1) such as a computer, a mobile phone, or a digital tablet, used by a user to access a service on the Internet, or an enterprise network, or intermediate equipment of a network; - by "remote server" (18), any network entity offering a network service on the Internet, such as a web server, a mail server, a multimedia content server (video, for example), etc. In Figure 1, the entity 12 represents a network equipment performing at least one switching function for routing incoming packets via a network such as the Internet. The equipment 12 includes a DNS server module 12a, responsible for resolving the names associated with destination servers on behalf of user terminals such as the terminal 1, and a module 12b responsible for routing network traffic from or intended for a client application (11). Depending on the environments considered, entity 12 may be confused with an Internet router dedicated to one or more end users. This Internet router can be for example integrated in a conventional manner within a residential gateway (usually referred to as "box" in English).

During an attempt to connect the client application 11 to the remote server 18, the client application 11 first communicates locally with the resolution module 11a in order to obtain the IP addresses of the remote server 18. For this purpose, a cache 11c is first consulted. The cache memory 11c temporarily records, in effect, previously obtained DNS responses, with a predefined duration TTL (rhyme To Live) validity, thus optimizing network performance. If the information sought (network addresses) is not in the cache memory 11c, the resolution module 11a generates blocks of DNS information to trigger the resolution of the name of the server 18 to obtain one or more network addresses. The blocks of DNS information for the resolution of the name of the server 18 are sent to the DNS server module 12a of the equipment 12, which therefore plays in this example, the local DNS server role for the client terminal 1. The module Local DNS 12a also has for optimizing the network performance of a cache 12c in which are stored previous DNS responses, issued by remote servers such as the server 18, with a predefined validity period (TTL). Thus, when the information (network addresses) relating to the server 18, requested by the client application 11, is not obtained from the DNS records stored temporarily in the cache 12c of the local DNS server 12a, the latter communicates with a server authoritative names 14, to get them. After obtaining the network addresses of the authoritative name server, the routing device 12b then follows the corresponding data packets to the server 18 based on routing rules, static or dynamic. Alternatively, the routing device 12b may also use Network Address Translation (NAT) translation rules to allow the routing of data packets between the client application 11 and the server 18. The authoritative name server 14 comprises in particular a standard DNS server module 14a, responsible for the processing of DNS queries, and a database 14c containing associations between the network addresses of servers, such as the server 18, and their server name or "Fully Qualified Domain Name" (FQDN). The network addresses managed in the database 14c can be of the IPv4 or IPv6 type and each is associated with the corresponding server name (FQDN).

In addition, the authoritative DNS server 14 may further comprise a DNS64 server module 14a '. The operation of the server module DNS64 (authoritarian) 14a 'is described in the document RFC 6147. The function of the DNS64 module 14a' is to generate dynamically an IPv6 address representing an IPv4 server 18, from the IPv4 address thereof , as well as at least one IPv6 Prefix identifying a NAT64 gateway in the Internet. The DNS64 configuration is managed by a database module 14c '. In the context of the present description: the term "native IP address" denotes an IP address corresponding to an active IP interface on an IP server entity (for example entity 18). This address can be IPv4 or IPv6; the term "fictitious IP address" denotes an IP address representing the IP server 18, but does not correspond to an active IP interface on the IP server 18. In a NAT64 context, this address is an IPv6 address representing an IPv4 server, via a NAT64 gateway. The operation of the authoritative DNS64 server 14a 'is as follows. Upon receipt of an IPv6 DNS request information block, the standard authoritative DNS server module (14a) is first polled to obtain the DNS record (s) corresponding to the server 18. If no DNS record is obtained (IPv4 or IPv6), or if at least one IPv6 DNS record, containing a native IPv6 address, is obtained, then the authoritative DNS64 server sends the obtained DNS response to the module 12a. If at least one IPv4 DNS record is obtained, but no IPv6 DNS record is obtained (corresponding to at least one "native" IPv6 address), then: at least one "fictitious" IPv6 address, representing the server 18, is synthesized from the IPv4 address obtained from it, as well as from the IPv6 prefix of the NAT64 gateway; an IPv6 DNS response type DNS information block, containing at least the synthesized IPv6 DNS record, is generated and is transmitted to the local DNS server module 12a. The IPv4 DNS records are also sent to the module 12a by the DNS server in an IPv4 DNS response type DNS information block. As mentioned above, the network environment represented in FIG. 1, comprises a routing equipment 19 connected to the network in which the server 18 is located, via the routing equipment 17. The routing equipments 17 and 19 are intended for routing data packets to server 18, based on standard address translation or routing rules (NAT IPv4), or NAT64-compliant address translation rules (described in RFC) 6146) for translating IPv6 packets from an IPv6 client into IPv4 packets understandable by an IPv4 server. The NAT64 gateway is represented in FIG. 1 either by a router entity 19, located in the network of the operator of the server entity 18, or by a translation module 17b of a routing equipment 17 whose role is to translate any received IPv6 packet to server 18 into an IPv4 packet understandable by the IPv4 server entity 18, and vice versa. The network environment also includes a proxy server 13 of the client terminal environment, and a proxy name server 16 of the authoritative DNS server environment 14. The proxy name servers (DNS) 13 and 16, include respectively at least one module (13a, 16a) capable of intercepting and processing blocks of DNS information. In accordance with the invention, the network environment represented in FIG. 1 further comprises a module 15 configured to obtain and adapt blocks of DNS information to network constraints relating to client-server exchanges in this environment.

According to the invention, the device 15 for obtaining DNS information blocks adapted to the constraints of the network of the client application 11 and the server 18 comprises in particular two distinct functional modules: a module for marking blocks of information DNS and a module processing DNS information blocks. The aforementioned modules may be distributed according to the embodiments chosen on different machines, which is illustrated in FIG. 1, by dashed line encompassing several distinct entity modules (1, 12, 13, 14, 16). Embodiment Next, a first embodiment of the invention will be described. FIGS. 2 and 3 respectively represent a network environment according to a first variant and a second variant of this first embodiment.

According to this first embodiment of the invention, the device for processing a request to access a remote server (18) by a client application (11) comprises a DNS request marking module (15a) and a DNS response processing module (15b). According to this first embodiment, the marking module (15a) is located in the network of the client entity, that is to say either in the user terminal 1 (FIG. 2) or in the local DNS server 12 or in the local DNS proxy server entity 13a (FIG. 3), and the processing module (15b) is located in the authoritative DNS server 14 or in the associated proxy name server 16. According to this first embodiment of the invention, the implementation of the method is triggered by the reception by a client entity DNS (11a, 12a or 13) of a request for the resolution of the name of the server 18, this request being initiated by the client application 11 in the client terminal 1. In this first embodiment, in order to reduce the delay in marking a request-type DNS information block by the marking function provided by the marking module (15a), a preliminary operation of creating marking information is performed by the marking module (15a). This marking information creation operation consists in creating for each active IP interface of the terminal 1 a record whose format is described below. This information useful for the marking function is stored in a cache memory 15c, whose content is managed at the client terminal 1 or in the local DNS server 12 (according to the considered variant of the first embodiment). The cache 15c is structured by one or more records describing at least one active IP interface of the terminal 1 and each having the following fields: a type, an identifier, a state, a usage preference of the type of the interface, as well as a validity period (Time to Live (TTL)). The aforementioned fields are detailed below.

Type of IP interface: This field corresponds to the IP stack type of the IP interface. It is coded on two bits. The value '10' indicates an IPv4 stack, the value '01' indicates an IPv6 stack and the value '11' indicates a "dual stack". IP interface identifier: This field corresponds to the network identifier of the IP interface. It contains an identifier of the associated network interface such as its IP address (IPv4 or IPv6). Functional status of the IP interface: This field indicates whether the interface is functional or not. It is coded on 1 single bit. The value '0' indicates that the IP interface is functional. The value '1' indicates that the IP interface is non-functional - for example, due to a physical or software problem on the network to which the network interface is attached (3G, Ethernet, etc.) such as a failure about the default gateway or the link between the terminal and the default gateway, etc. Preference for use of the IP interface: this field indicates the preference of use of the interface. The value of a usage preference '0' indicates that the user of the client terminal does not wish to use this interface momentarily. This field is 8-bit coded. Validity period: This field corresponds to the lifetime or Time to Live (TTL) of the record in the cache (15c). By default, the value of this field is the same for all records in the cache. However, the user can change the TTL value of a given record, for example, by setting it to '0' to force updating of the entire cache. By way of example, consider a terminal having a single network interface, and having obtained from an Internet access operator two IP addresses: one of the public IPv4 type and another of the global IPv6 type. At a given moment, the records stored in the cache 15c may be: <10, 192.0.1.10, 0, 1, 5>: interface of the functional IPv4 type and which the client terminal 1 uses. This recording is valid for a further 5 seconds. and <11, 2a01: c079 :: c0a8: 1c3, 1,0, 5>: IPv6 type interface, non-functional (for example due to a problem on the default gateway), and the terminal administrator does not do not want to use it momentarily. This record is valid for another 5 seconds. The cache memory (15c) of the marking module (15a) is fed by a function of collecting the functional state of each IP interface of the client terminal (1), noted: Collect IP Interface Status (ip interface). According to the invention, this function performs, at regular time intervals, tests aimed at verifying the functional state of each IP interface of the client terminal (1), and updates the contents of the cache memory (15c) by indicating the functional state of each network interface of the client terminal.

In practice, the above function first checks whether an IP interface is active, and then checks whether the underlying network is functional. Indeed, for a client terminal, it is sufficient for example that the default gateway of an IP interface is down, so that it becomes unnecessary, even when the IP interface of the terminal is active. FIG. 4 is a flowchart illustrating a method for resolving a server name according to the first embodiment of the invention, according to the first variant (steps E40-E46) and according to the second variant (specific steps E41a-E46a, other steps being similar). First Variant of the 1st Embodiment (M1-V1) In connection with FIG. 4, a method for processing a resolution of a server name according to the first variant mentioned above, illustrated by FIG. 2, and according to which the marking module of the DNS information blocks (15a) is located in the resolver module 11a of the client terminal 1. In step E40, the resolver module 11a including the marking module 15a receives a request resolving the name of the server 18 to network addresses, for example via a known request of the type Get Host by Name O. In response to this request, the module 11a first consults its local cache 11c. If no DNS response corresponding to the received request is found in the cache 11c, then the resolver module 11a generates DNS information blocks of the request type for the resolution of the name of the server 18. It will be noted here that a resolver module of a recent operating system (OS) usually generates an IPv4 DNS request type DNS information block to obtain one or more IPv4 addresses associated with the server 18, and an IPv6 DNS query type information block, for obtain one or more IPv6 addresses for the server 18. In step E41, each generated query type DNS information block is transferred to the DNS information block marking module 15a.

In step E42, the DNS information block marking module (15a) consults its cache 15c in order to obtain valid information (the TTL of which is not zero), indicating the type of each functional IP interface on the client terminal 1. For this, according to the invention, the following function is used: Get IP Interface Status O.

If the Get IP Interface Status () function determines that the cache 15c contains at least one record whose lifetime (TTL) is equal to zero, then in step E44, the update of the cache 15c is forced by the execution of the Collect IP Interface Status function (ip interface), causing the update of the cache 15c with indication of the functional state of each network interface of the client terminal 1. Otherwise (no record has a duration of life equal to zero), we go to step E43. At this stage, a function noted: Generate DNS Marking (cache) is executed in order to obtain a summary of the valid information obtained from the cache 15c and to generate from this summary a code that will be used for the marking of DNS queries The execution of the above Generate DNS Marking function first causes the selection of the type and the usage preference of each record representing a functional IP interface (whose value of the "Functional state of the IP interface" field is 0, see above). Then, the redundancies between these records are eliminated and for each set of functional records of the cache 15c, only one marking code is generated. Each code contains at most three pairs of information: a first describing the state of the IPv4 interfaces, a second describing the state of the IPv6 interfaces and a third describing the state of the "double stack" interfaces. The value of the code generated by the Generate DNS Marking function is encoded on 32 bits.

For example, if the cache 15c of the marking module contains the following records: - <10, 192.0.1.10, 0, 2, 5> - <01, 2a01: c079 :: c0a8: 1c3, 1.0, 5> - <01, 2a11: 0db8 :: d0b8: 1, 0,1, 5> Then the Generate DNS Marking function will generate the following code: (<IPv4,2>, <IPv6,1>) The code below above it will indicate to the module (15b) handling of the marked DNS queries, that a block of information of the IPv4 DNS response type must first be returned, the value '2' (associated with the IPv4 address) in the code indicating a higher value. great preference.

In the particular case of a value preferably equal between several addresses, for example, for a generated code (<IPv4,1>, <IPv6,1>), the processing module will send blocks of information of the DNS response type IPv4 and IPv6. Finally, if the marking code is (<IPv6,1>), then the processing module will only return IPv6 responses. Still in FIG. 4, in step E45, the marking module (15a) activates a DNS query marking function, called Apply Marking (DNS Request, Code) using the marking code obtained in the previous step (E43 ), to mark each block of DNS information of the query type. For this purpose, the Apply Marking function uses the EDNSO (Extensible Mechanisms for DNS (EDNSO) - RFC 2671) DNS extensions, to register the code in the DNS query, as shown in Figure 6.

Figures 5 and 6 respectively represent the format of a standard DNS query and the format of a DNS query marked, according to the DNS protocol, applicable to the first embodiment of the invention; According to a particular implementation (denoted var10), the module 15a does not perform any filtering of the DNS queries which have a lower priority (precedence in English). The advantage of this approach is a better reliability of the service. Indeed, IPv4 and IPv6 DNS requests are not sent in the same IP packets, if the preferred functional interface undergoes any degradation, for example following the mobility of the user, or if the information block DNS request whose precedence is greatest, is lost in the network, while the block of information of the type of DNS query of less precedence arrives at the destination, this will not prevent the communication to be established via an interface Less preferred functional IP, while avoiding any additional DNS resolution time. According to another implementation (denoted var11) which is alternative to the preceding one, in step E45, the function _Apply_Marking (DNS Request, Code) executed by the module 15a uses the marking code obtained in step E43 to filter out that is, remove query-type DNS information blocks that have the lowest precedence level. For example, if a client terminal 1 is "dual stacked" but is configured to "prefer" to communicate with servers (18) using the IPv4 stack, then the _Apply_Marking function will filter the IPv6 DNS queries. In another example, a client terminal 1 may be configured to "prefer" to use IPv6 to communicate with a "double stack" server, without accepting to go through gateways of NAT64 type. In this case, if, for example, the server 18 is reachable in native IPv4, and in IPv6 via NAT64, then, by removing the IPv4 DNS queries, the implementation var11 will privilege a non-native path with respect to the native IPv4 path. In this case of particular use, the implementation of variant var10 will provide a better quality of communication. In step E46, the DNS information block marking module (15a), which, in the embodiment described here, merges with the entity 11a generates, according to the marking code, the information block or blocks. Query DNS and sends them to the local DNS server entity 12a. According to an implementation variant in which the marking module 15a is not confused with the resolver module 11a, the module 15a first intercepts the DNS requests generated by the resolver module 11a, then carries out a marking of each DNS request and provides each marked DNS information block directly to the operating system (OS) of the client terminal 1. The DNS request is then sent by the OS of the client terminal to the local DNS server entity 12 (module 12a). Moreover, according to a particular implementation, the local DNS server module 12a sends the received DNS information block or blocks of request type, marked, without modifying them, to the authoritative DNS server entity 14, without filtering the requests of less precedence. According to another possible implementation, if the module 11a has used the marking code to suppress the lower precedence DNS requests, then the local DNS server module (12a) sends one or more blocks to the authoritative DNS server entity 14. Request-type DNS information, standard (s), that is, not including an EDNSO extension. According to another possible implementation of this first variant of the first embodiment of the invention, the local DNS server module 12a consults the marking of the DNS information blocks of the request type for the resolution of the same server 18, deletes the requests of least precedence and sends to the authoritative DNS server entity 14, one or more standard DNS information blocks of the query type, that is to say not including an EDNSO extension. The sending of the request-type DNS information blocks to the authoritative DNS server entity 14 is illustrated by the step E47 detailed below in the description. Second Variant of the 1st Embodiment (M1-V2) Still in connection with FIG. 4, the steps, denoted E41a-E46a, specific to the second variant mentioned above, illustrated in FIG. 3, will be described, according to which the DNS information block marking module (15a) is located either in the local DNS server entity 12 (resolver module 12a) or in the local DNS proxy server entity 13, of the network part of the client entity. As explained above, in step E40, following the receipt of a request for resolving the name of the server 18, the resolver module 11a of the terminal 1 first consults its local cache 11c. If no DNS response corresponding to the received request is found in the local cache, then the resolver module 11a generates query-type DNS information blocks for the resolution of the server name 18 in one or more network addresses. In step E41a, the module 11a routes each request-type DNS information block generated in the previous step, to the local DNS entity 12 (module 12a).

As already mentioned, in this variant, the module for marking the information blocks DNS (15a) is located as illustrated by FIG. 3, either in the local DNS server module 12a, or in the local DNS proxy module 13a. A structure in memory 15d is managed by the marking module 15a. This memory structure corresponds either to the memory referenced 12d when the marking module is located in the local DNS server 12, or to the memory referenced 13c when the marking module 15a is located in the local DNS proxy server 13. This memory, 12d or 13c as appropriate, contains in particular for each client terminal (1) records, defining for each client terminal (1), the list of its IP interfaces, the stack or type of active and functional IP interfaces (IPv4 or IPv6) , the preference of use by type of interface, as well as a value of duration of validity (TTL).

In step E42a, the DNS information block marking module (15a) first associates the request with the client terminal that generated it, for example, by using the source mac or ip address of the packet carrying the DNS query. Then, the module 15a performs a number of functions to obtain the IP preferences of the terminal in question.

Firstly, the module 15a consults the cache memory (12d or 13c) in order to obtain valid information indicating the type of each functional IP interface for the client terminal 1 under consideration. For this purpose, a Get IP Interface Status function (terminal id) is executed. Following the execution of the above function: if the terminal is not identified by at least one record in the memory structure 12d or 13c, or if the terminal is identified by at least one record in the memory structure 12d or 13c, but there is at least one record whose TTL is equal to 0 in the structure in memory then a cache update is triggered, in step E44a, via a collection function IP Interface Status (client id). The execution of this function causes the updating of the cache memory (12d or 13c), with indication of the interfaces of the client terminal, as well as the usage preferences of the functional network interface (s) of the client terminal 1 (identified by the '_id client' parameter). Otherwise (no record has a lifetime of zero), proceed to step E43a in which the client module 15a obtains usage preference information from the interface (s) Functional IP of the client terminal 1. According to a first implementation, a client function executed in the module 15a queries a server function executed in the client terminal 1, according to a client-server relationship. Specifically, this is for the client function of the Collect IP Interface Status function (client id), and for the server function of each terminal, the Generate DNS Marking O function. The Collect IP Interface Status client function uses a client id identifier to query the terminal in question and obtain its IP preferences thanks to the Generate DNS Marking O local function. The client id client identifier is either the IP address or the physical address of a terminal interface. having generated at least one DNS request destined for the local DNS server 12. As explained above in relation to the first variant (M1-V1), the marking code obtained by the client function following the interrogation of a client terminal contains at most three pairs of information: a first describing the state of the IPv4 interfaces, a second describing the state of the IPv6 interfaces and a third describing the state of the "double stack" interfaces. In the particular case, where the marking module 15a is located in the DNS proxy entity 13, the module 15a uses an interception function of the DNS query type information blocks to obtain for each DNS request the client identifier. at the origin of this DNS query. According to a second implementation applicable, for example, to a context of residential customers, the memory structure (12d or 13c) can be manually powered by a user of the client terminal 1 via a web interface provided by a local DNS server router 12. This router 12 is then confused with a residential gateway (also called box in English). Once the cache 12d or 13c is updated, the module 15a then proceeds to step E43a. In the opposite case (if the terminal is identified with valid records, ie whose lifetime is different from zero), proceed to step E43a in which the client module 15a obtains information. usage preference information of the functional IP interface (s) of the client terminal 1. The module 15a then proceeds to step E45a. In step E45a, according to a particular implementation, the marking module 15a applies to a request-type DNS information block an EDNSO DNS extension as illustrated in FIG. 6. According to another possible implementation, the marking module 15a uses the marking code obtained in the previous step (E44a) to filter that is to say eliminate the query type DNS information blocks that have the lowest priority. In step E46a, the DNS information block marking module 15a transmits each request-type DNS information block (marked or standard, depending on the implementation) to the local DNS server module 12a. The following steps E47-E50 shown in Figure 4, are applicable to the two embodiments described above (M1-V1, Ml-V2). In step E47, each request-type DNS information block generated in the previous step (E46, E46a) is transmitted to the authoritative DNS server entity 14.

In the embodiment chosen and presented, the authoritative DNS server 14 comprises either a standard authoritative DNS server module 14a or an authoritative DNS server module 14a enriched with an authoritative DNS64 server module 14a '. According to a first implementation (denoted IM1), the module 15b for processing the DNS information blocks (15b) according to the invention is located in the authoritative DNS server entity 14, on which is instantiated a DNS authoritative server module 14a and a DNS64 authoritative server module 14a '(see Figures 2 and 3). Still in step E47, the processing module 15b activates a Read Code function (DNS Request) in order to obtain from the EDNSO extensions of each received request type DNS block the preference information relating to the client terminal 1 (type functional IP interfaces, terminal preferences). In step E48, when the module 15b processing blocks of DNS information is confused with the authoritative server module DNS64 14a ', it activates a function Apply DNS Code (DNS Request, Code), in order to obtain blocks of DNS response type information, adapted to the marking code obtained from the previous step (E47). For this, the processing module 15b consults a DNS database 14c as well as that (14c ') associated with the entity 14a' in order to obtain one or more DNS records adapted to the constraints of the client terminal 1 via a function noted: Search DNS Code If no DNS record satisfying the marking code ('Code') is obtained, and if the preferences associated with the client terminal 1 allow the latter to use one or more addresses ( s) Fictitious IP (s) (that is to say non-native), then the processing module 15b synthesizes at least one. According to this first embodiment of the invention, the particularity of the aforementioned function is that it is configured to always privilege records bearing the native identity of the server entity 18, when it corresponds to the preferences and needs of the server. customer terminal 1.

Thus, according to a first example, if the marking code obtained is (<IPv4,2>, <IPv6,1>), the Search DNS Code function (DNS Request, Code) is configured to deduce that the client terminal 1 is "double stack", but that it "prefers" to obtain a DNS response of type IPv4, and retains only the IPv4 DNS record. In this case, even if the server 18 is natively "double stacked" or if it is accessible via a NAT64 gateway, only its native IPv4 addresses will be sent to the client terminal 1 incorporated in one or more blocks of information type IPv4 DNS response. In a second example, if the code corresponds to the record: (<1Pv4,1>, <IPv6,1>), the Search DNS Code function (DNS Request, Code) is configured to deduce that the client terminal 1 has of a "double stack", and that it "wishes" to obtain IPv4-type DNS responses and IPv6-type DNS responses. Thus, if the server 18 is IPv4 but is additionally represented by one or more fictitious IPv6 addresses in the DNS database or via DNS64, then only the IPv4 native addresses will be sent to the client terminal 1 "double stack", via one or more information blocks of the DNS I Pv4 response type.

According to a third example, if the code corresponds to the record: (<IPv4,1>, <IPv6,2>), the Search DNS Code function (DNS Request, Code) is configured to deduce that the client terminal 1 has of a "double stack", and that it "wants" to obtain IPv4-like DNS responses and IPv6-like DNS responses, with a preference for native IPv6 addresses. Thus, if the server 18 is IPv4 but is additionally represented by one or more fictitious IPv6 addresses in the DNS database or via DNS64, then only the IPv4 native addresses will be sent to the client terminal 1 "double stack", via one or more blocks of IPv4 DNS response type information, thus preferring native paths to traversing NAT gateways (NAT64 in this example).

According to a fourth example, if the obtained code corresponds to the following record: (<IPv6,1>), the Search DNS Code function (DNS Request, Code) is configured to deduce that the client terminal 1 has only one IPv6 stack functional and it is possible to send him a block of DNS information of type response with fictitious IPv6 addresses. In this case, if the server 18 is IPv4 but is represented by one or more fictitious IPv6 addresses in the DNS database (14c) or via DNS64, then these IPv6 addresses will be sent to the client terminal 1 via a or more IPv6 DNS response information blocks. According to a second implementation (denoted IM2), the module 15b for processing the DNS information blocks is not located on the authoritative DNS server entity 14 but on a DNS proxy server entity 16 located upstream of the entity 14. In this case, in step E48, the module 15b (confused with the module 16a in FIG. 3) intercepts each block of DNS information of the request type, then activates a Read Code function (DNS Request), in order to obtain from the EDNSO extensions of the query type DNS information blocks, the preference information of the client terminal 1 corresponding to the DNS request (type of functional IP interfaces, preferences of the client terminal). The module 15b then activates the Apply DNS Code function, in order to obtain at least one block of information of the DNS query type, adapted to the marking code obtained.

For this, the processing module 15b activates the Search DNS Code function (DNS Request, Code) to obtain at least one DNS record adapted to the constraints of the client terminal 1. This function is configured to operate as follows, depending on the code obtained: If the client terminal 1 is of the IPv6 type, then the processing module 15b sends the information block or blocks of DNS query type to the authoritative DNS64 server (14a '). It thus authorizes, if necessary, the synthesis of fictitious IPv6 addresses for establishing a communication between the client terminal 1 and the server 18. If the client terminal 1 is of the "double stack" or IPv4 type, then the processing module 15b transmits the DNS request (s) directly to the authoritative DNS server (14a) and not to the authoritative DNS64 server. Thus, it does not allow the synthesis of fictitious IPv6 addresses and therefore prefers native translation paths for dual-stack terminals. The advantage of this second implementation (IM2) is that the processing module 15b is simple to implement because it only acts on DNS requests and not on DNS responses.

Therefore, it does not require a complex memory structure to associate pairs (DNS queries, code) with DNS responses. According to this implementation, it is possible to directly query the authoritative DNS server (14a) without consulting the authoritative DNS64 server (14a ').

In step E49, the authoritative server 14 generates one or more blocks of DNS information of the response type and transmits them to the local DNS server 12 (module 12a). Finally, in step E50, the local DNS module 12a receives the DNS response type information block or blocks. It stores them in memory 12c before transmitting them to the resolver module 11a of the client terminal 1. The latter stores them in memory 11c before transmitting them to the client application 11. The DNS responses obtained by the application 11 are adapted to the constraints of the client terminal 1. 2nd Embodiment A second embodiment of the invention will now be described according to two variant embodiments (denoted M2-V1 and M2-V2). FIGS. 7 and 8 respectively represent a network environment according to the first variant and a network environment according to the second variant of this second embodiment. Fig. 9 is a flowchart illustrating a method of resolving a server name according to the second embodiment, applicable to the two aforementioned variants. Finally, FIG. 10 represents the format of a DNS response applicable to this second embodiment. According to this second embodiment of the invention, the system for processing a request for the resolution of a name of a server by a client application comprises a module (15a) for marking DNS responses (information blocks DNS response type) and a module (15b) for processing the DNS responses marked. For both variants considered, the marking module 15a is located in the authoritative DNS server 14. According to the variants under consideration, the module 15b for processing the marked responses is located either in the resolver 11a (see FIG. 7) or in the local DNS server 12a or in a proxy DNS server 13 located upstream of the DNS server 12a (see Figure 8). According to the second embodiment, the implementation of the method according to the invention is triggered by the reception by a DNS server entity (14a, 14a ') of a request for the resolution of a server name (18) in one or more network addresses. This request is initiated by the local DNS server 12 (module 12a), on behalf of a client application 11, having sent an access request to this server (18). In FIG. 9, the process for processing a DNS resolution request according to the invention starts with the step E90 during which the authoritative DNS server 14 receives a request for resolution of the name of the server 18, in the form of DNS information blocks of the IPv4 and / or IPv6 DNS query type.

According to a first configuration, the server entity 14 contains an authoritative DNS server 14a, and according to another configuration, the server entity 14 comprises in addition to the authoritative DNS server 14a, a standard DNS64 server module 14a '.

The following steps E91-E97 shown in FIG. 9 are applicable to the two embodiments described above (M2-V1, M2-V2). In step E91, in response to the received DNS requests, the server entity 14 attempts to obtain DNS responses.

According to the first configuration, the entity 14 contains a standard authoritative DNS server 14a. The latter consults its database 14c looking for IPv4 or IPv6 DNS records corresponding to the server 18. According to a second configuration, the entity 14 contains in addition to the standard authoritative DNS server 14a, an authoritative DNS64 server 14a '. The latter processes the DNS requests as follows: For each IPv4 DNS request received, the IPv4 DNS request is processed by the standard DNS server 14a. For each IPv6 DNS request received, the DNS64 server 14a 'consults the DNS server 14a, which consults its database 14c looking for the DNS record representing the server 18. If at least one DNS record is obtained, then, according to the In this case, the DNS64 server 14a 'will generate: o An IPv6 DNS6 response containing at least one IPv6 DNS record including a "native" IPv6 address of the "double stack" server 18; o An IPv6 DNS6 response containing at least one IPv6 DNS record including a "fictitious" IPv6 address of the IPv4 server. This address is synthesized by the DNS64 server as described above.

According to the invention, according to the configuration chosen (as explained above), the marking module 15a can be confused with either the authoritative DNS server 14a or the DNS64 server 14a '. In step E91, when obtaining DNS responses associated with a DNS request, the marking module 15a inscribes in a memory structure 15d (which is identical with the structure 14d in FIG. 7) a "type" information. "defined below. The data structure in memory 14d consists of the following fields: A field containing an identifier of the processed DNS request, obtained by copying the identifier of the processed DNS request. It is coded on 16 bits. A field containing an identifier of the DNS record, in the order of its obtaining by the module 14 (14a or 14a 'according to the configuration). This field is coded on 4 bits. According to one implementation, it can be provided that this field contains the IP address contained in the DNS record obtained.

A field indicating the "Type" of the record. The Type of a record in structure 14d indicates the type of IP address contained in this DNS record. This field is coded on 2 bits as follows: 00: "Authentic", "Not shared" 01: "Authentic", "shared": "Fictive", "Not shared" 11: "Fictitious", "shared" At the step E92, the authoritative DNS server 14 (the module 14a or the module 14a 'according to the chosen configuration) routes the DNS response type information block to the marking module 15a. It is also possible that the marking module 15a intercepts the block of information type DNS response. In step E93, the DNS information block marking module 15a verifies that there is at least one record in the DNS response type information block being processed. If the DNS response is not empty, that is to say that it contains at least one IPv4 or IPv6 type DNS record, then the module 15a proceeds to step E94. Otherwise, in step E95, the empty DNS response is not tagged. The module 15a goes to the step E97.

At the step E94, the DNS response not being empty, the module 15a activates the local function Generate DNS Response Marking (DNS Request ID), the execution of which causes the consultation of the cache 14d in order to obtain the type of the addresses IPs contained in the DNS record (s) of a DNS response associated with a DNS query. The Generate DNS Response Marking function is configured to first identify the initial DNS request in the memory 14d by the DNS Request ID identifier field (see step E91 above). Then, the above function obtains, in the order of their reading, the Type of each DNS record included in the response. The information obtained is a DNS response marking code used in the next step (E96). For example, the "0010" code obtained for a DNS response indicates that the DNS response contains two DNS records: The first DNS record contains a public IPv4 address, "Authentic" "Not shared" The second DNS record contains a global IPv6 address "Fictive", "Not shared", synthesized by the DNS64 module (14a ').

In step E96, the marking module (15a) activates the Apply Marking (DNS Response, Code) marking function whose execution causes the application to each block of information of the DNS response type, the code obtained by the step E94. This code indicates the type of each record included in the DNS response, in the order of their insertion in the DNS response.

To this end, the Apply Marking function inserts the above code in the RDATA field of the EDNSO extension applied to the DNS response, as shown in Figure 10. The sending of the request-type DNS information blocks to local DNS server entity 12 is illustrated by step E97.

In step E97, each DNS response type information block generated in the previous step (E96, E96a) is transmitted to the local DNS server entity 12 (module 12a). In step E98, the set of DNS response type information blocks is received by the local DNS server module 12a.

If the received DNS response is empty then it is unmarked. This response is routed as it is by the local DNS server 12a to the application 11. Otherwise, there is at least one non-empty and marked DNS response. The processing of the marked DNS responses is then implemented. Processing of the Marked DNS Responses As mentioned above, in the embodiments shown, the module 15b for processing DNS response type information blocks is located, according to a first variant (M2-V1) in the local DNS resolver module ( 11a) (see FIG. 7), and according to a second variant (M2-V2) in the local DNS module 12a or proxy 13 (see FIG. 8).

First Variant of the 2nd Embodiment (M2-V1) According to the first variant M2-V1 of the processing of the marked responses, the module 15b for processing the DNS response type information blocks is located in the local DNS resolver module (11 a) as shown in FIG. 7. In this case, in step E98, the local DNS server module 12a stores the DNS responses received in the memory structure 12c. The module 12a then transmits each block of received information of the DNS response type marked, without modification, to the client terminal (1). In step E99, the marked DNS information blocks are received by the entity 11a of the client terminal 1. They are first stored in the cache 11c. Then, they are processed by the DNS information block processing module (15b), confused with the resolver module (11a). According to this first variant of the second embodiment of the invention (M2-V1), the processing module 15b manages in a memory structure 15c the state of the functional IP interfaces of the client terminal 1. This data structure 15c, described above, indicates for each active IP interface, its type, its identifier, its state, the preference of use of the interface as well as a validity period (Time to Live - TTL). In order to obtain the IP preferences of the client terminal 1, the processing module 15b executes the local function Get IP Interface Status Summary ().

This function first checks whether the cache 15c contains at least one record whose lifetime (TTL) is equal to zero. If this is the case, then the updating of the cache 15c is forced by the execution of the Collect IP Interface Status function (ip interface). In the opposite case (if no record has a lifetime equal to zero), proceed to step E100. At this stage, a function noted: Generate Terminal IP Preference () is executed in order to obtain a summary of the valid information obtained from cache 15c. This function summarizes the contents of the cache 15c into a code that will indicate the instantaneous IP preferences of the client terminal 1.

Execution of the aforementioned Generate Terminal IP Preference function first causes the selection of the type and the usage preference of each record representing a functional IP interface (whose value of the field "Functional state of the IP interface" is to 0, see above). Then, the redundancies between these records are eliminated and for each set of functional records of the cache 15c, only one marking code is generated. Each code contains at most three pairs of information: a first describing the state of the IPv4 interfaces, a second describing the state of the IPv6 interfaces and a third describing the state of the "double stack" interfaces. The value of the code generated by the Generate Terminal IP Preference function is 32-bit. For example, if the cache 15c of the marking module contains the following records: - <10, 192.0.1.10, 0, 2, 5> - <01, 2a01: c079 :: c0a8: 1c3, 1.0, 5> - <01, 2a11: 0db8 :: d0b8: 1, 0,1, 5> Then the Generate DNS Request Marking function will generate the following code: (<IPv4,2>, <IPv6,1>) Pass then at step E101 in which, the processing module 15b activates the Apply Marking function (DNS Response, Code1, Code2) to adapt the DNS records contained in the DNS response (s) received (s) to the constraints the client terminal 1.

For this, it uses the code indicated in the marking of the DNS responses (RDATA field), as well as the code indicating the state of the functional IP interfaces of the terminal 1 in order to provide the client application (11) only the address or addresses "Useful" IPs of the server 18, that is to say those adapted to the constraints of the network of the client terminal 1. Thus, if the code indicating the IP preferences of the client terminal 1 is (<IPv4.2>, <IPv6,1>), and the resulting response contains two DNS records: - A first DNS record that includes a genuine non-shared IPv4 address - A second DNS record that includes a non-shared fictitious IPv6 address then, the Apply Marking function will indicate to the client application 11 only the IPv4 address of the server 18. It removes the DNS response containing a fictitious IPv6 address. In another example, if the code indicating the IP preferences of the client terminal 1 is (<1Pv4,1>, <IPv6,1>), and the response obtained contains two DNS records: A first DNS record that includes an IPv4 address Authentic Unshared A second DNS record that includes a genuine non-shared IPv6 address means that Terminal 1 is configured to equally accept IPv4 DNS responses and IPv6 DNS responses. The processing module 15b then returns to the client application (11) the IPv4 and IPv6 addresses. In a third example, if the code indicating the IP preferences of the client terminal 1 is (<IPv6,1>), and the response obtained contains two DNS records: - A first DNS record that includes an authentic non-shared IPv4 address - A second DNS record that includes a non-shared fictitious IPv6 address then the processing module 15b returns to the client application (11) the fictitious IPv6 address. Finally, in step E102, the client application (11) obtains from the module 11a, confused with the module 15b, one or more IP addresses associated with the server entity 18, adapted to the constraints of the network of the terminal 1.

Second Variant of the 2nd Embodiment (M2-V2) According to the second variant M2-V2 of the processing of the marked responses, the module 15b for processing the DNS response type information blocks is located in the local DNS server module 12a or else in the DNS proxy module 13, as shown in FIG. 8. A memory structure 15d is managed by the module 15b. This structure in memory corresponds either to the memory referenced 12d when the marking module 15b is located in the local DNS server 12, or to the memory referenced 13c when the marking module 15b is located in the local DNS proxy server 13. This memory , 12d or 13c as appropriate, contains in particular for each client terminal (1) records, defining for each client terminal (1), the IP interfaces, the stack or type of active and functional IP interfaces (IPv4 or IPv6), the preference of use by type of interface, as well as a value of duration of validity (TTL). In step E98a, the DNS information block processing module (15b) first associates the response obtained with the client terminal that generated the associated DNS request. For this, the module 15b previously maintains a memory structure associating each block of DNS information to the terminal that generated it (structure 15e). Then, in step E99a, the module 15b performs a number of functions to obtain the IP preferences of the client terminal that generated the DNS query in question.

Firstly, the module 15b consults the cache memory (12d or 13c) in order to obtain valid information indicating the type of each functional IP interface for the client terminal 1 under consideration. For this purpose, a Get IP Interface Status function (terminal id) is executed. The module 15b uses the identifier of the DNS query to obtain the identifier of the terminal that generated the DNS query. Following the execution of the above function: if the terminal is not identified by at least one record in the memory structure 12d or 13c, or if the terminal is identified by at least one record in the memory structure 12d or 13c, but there is at least one record whose TTL is 0 in the memory structure, then a cache update is triggered, via a Collect IP Interface Status function (id customer). The execution of this function causes the updating of the cache memory (12d or 13c), with indication of the interfaces of the client terminal, as well as the usage preferences of the functional network interface (s) of the client terminal 1 (identified by the '_id client' parameter). According to a first implementation, a client function executed in the module 15b interrogates a server function executed in the client terminal 1, according to a client-server relationship. Specifically, for the client function, this is the Collect IP Interface Status function (client id), and for the server function, for each terminal, the Generate Client Terminal Preferences () function, similar to the Generate DNS Request function. Marking O described above. The Collect IP Interface Status client function uses a client id identifier to query the terminal in question and obtain its IP preferences and the list of these IP interfaces, thanks to a server function on the client terminal 1 that we call Generate Client Terminal Preferences O The client ID of the client is either the IP address or the physical address of an interface of a terminal that has generated at least one DNS request to the local DNS server 12. The marking code obtained by the function client following the interrogation of a client terminal contains at most three pairs of information: a first describing the state of IPv4 interfaces, a second describing the state of IPv6 interfaces and a third describing the state of interfaces "double battery". In the particular case, where the module 15b is located in the DNS proxy entity 13, the module 15b uses a function of interception of the DNS query type information blocks to obtain for each DNS request the identifier of the client terminal to the origin of this DNS query.

Then, it communicates with the terminal as described below to obtain the list of IP interfaces of the terminal as well as its IP preferences. According to a second implementation applicable, for example, to a context of residential customers, the memory structure (12d or 13c) can be manually powered by a user of the client terminal 1 via a web interface provided by a local DNS server router 12. This router 12 is then confused with a residential gateway (also called box in English). Once the cache 12d or 13c is updated, the module 15b then proceeds to step E100a. In the opposite case (if the terminal is identified with valid records, ie whose lifetime is different from zero), we proceed to the step E100a during which the module 15b obtains information. preferably of use of the functional IP interface (s) of the client terminal 1. In step E100a, the module 15b stores first of all the marked DNS responses received in the memory 12c. Then, it activates the Apply Marking function (DNS Response, Codel, Code2) to adapt the DNS records contained in the DNS response (s) to the constraints of the client terminal 1. For this, it uses the code indicated in the marking of the DNS responses (RDATA field), as well as the code indicating the state of the functional IP interfaces of the terminal 1 in order to indicate to the client terminal (11) only the DNS response (s) received "useful", that is to say , those which are adapted to the constraints of the network of this one. This function is similar to what is described above (E101). The module 15b then proceeds to the step E101a, where it sends the useful DNS records resulting from the previous step E100a in one or more block (s) of DNS response type information to the client terminal 1.

Finally, in step E102a, the entity 11a receives one or more IP addresses associated with the server entity 18, adapted to the constraints of the network of the terminal 1. It stores them in memory 11c before delivering them to the client application (11) .30

Claims (16)

REVENDICATIONS1. A method of processing a request for resolving a name of a server (18), issued by a client application (11) installed on a client terminal (1), over a communication network, the method being characterized by steps of: a) - obtaining by a first network entity (11, 12; 14) a set of DNS messages following said resolution request; b) - obtaining by the first network entity (11,12; 14) network connectivity information relating to at least said client terminal or said server (18), and generating a code, said marking, representative of said information of network connectivity; c) - processing by said first network entity (11,12; 14) said set of DNS messages according to said marking code, and sending accordingly a set of DNS messages, said marked, to a second network entity (14 11,12); d) - processing by the second network entity (14; 11,12) of said set of marked DNS messages, in order to deliver to the client application (11) at least one DNS response adapted according to said network connectivity information. The method according to claim 1, wherein in step a) said set of DNS messages is a set of DNS queries generated following the reception by a DNS resolution module (11a) of said name resolution request, and wherein in step b) said network connectivity information includes at least one type and preference information of active IP interface usage for said client terminal (1). 3. The method according to claim 2, wherein step c) of processing the set of DNS queries includes: the insertion of the marking code in each request of said set of DNS queries, within a determined field of the body of the query, thus forming a set of marked queries. The method of claim 3, wherein the processing step d) comprises reading the marking code contained in each request of the set of marked requests, and then searching for DNS records conforming to said connectivity information obtained at from said marking code, and if at least one such record is found, generating at least one DNS response containing said record, then sending said at least one DNS response to the client application (11). The method of claim 3, wherein said determined field is an RDATA field of the request body according to the EDNSO extension of the DNS protocol. The method of claim 2, wherein the processing step c) includes filtering said set of DNS queries according to the marking code. The method according to any one of claims 2 to 6, wherein said first network entity is located in the client terminal (1) or in a local DNS server (12) vis-à-vis the client application, and said second network entity is located in an authoritative DNS server (14) for the domain associated with the server (18). The method of claim 1, wherein in step a) said set of DNS messages is a set of DNS responses generated by said first network entity (14), upon receipt of a set of DNS queries generated by a DNS resolution module (11a) following receipt of said name resolution request, and wherein in step b) said network connectivity information is characteristic of a type of IP address identifying said server (18); ) contained in each DNS response of said set. The method of claim 8, wherein in the processing step c) said first network entity (14) of each DNS response of said set comprises inserting the tag code within a field determined the body of the response, thereby forming a set of marked responses, and then sending said set of marked DNS responses to said second network entity (11,12). The method of claim 9, wherein the processing step d) performed by said second network entity (11,12) comprises: obtaining information indicative of network connectivity preference for the client terminal; comparing the marking code contained in each response of the set of marked responses with said information indicative of network connectivity preference for said client terminal (1), then the selection of the DNS responses satisfying said information indicative of network connectivity preference. for said client terminal. The method of claim 8, wherein said determined field is an RDATA field of the response body according to the EDNSO extension of the DNS protocol. The method of any one of claims 8 to 11, wherein said first network entity is located in an authoritative DNS server (14) for the domain associated with the server (18), and said second network entity is located in said client application. (11) or in a local DNS server (12) vis-à-vis the client application. 13. System for processing a request for resolution of a name of a server (18), issued by a client application (11) installed on a client terminal, on a communication network, characterized in that it comprises: at least one first network entity (11, 12; 14) comprising: - a module for obtaining a set of DNS messages following said request for resolution; a module for obtaining network connectivity information relating at least to said client terminal (1) or to said server (18), and for generating a code, said marking code, representative of said network connectivity information; and a module for processing the set of DNS messages according to the marking code, in order to obtain a set of DNS messages, said to be marked; at least one second network entity (14; 11,12) comprising: a module for receiving said set of marked DNS messages from said at least one first network entity (11,12; 14); and - a module for processing the set of marked DNS messages, in order to deliver to the client application (11) at mo ins a DNS response adapted according to said network connectivity information. Network entity implemented for processing a server name resolution request, issued by a client application installed on a client terminal (1), on a communication network, said network entity comprising: a module for obtaining a set of DNS messages following said request for resolution; a module for obtaining network connectivity information relating at least to said client terminal or to said server, and for generating a code, referred to as a marking code, representative of said network connectivity information; and a module for processing the set of DNS messages according to the marking code, in order to obtain a set of DNS messages, said to be marked. 15. Network entity implemented for processing a server name resolution request, issued by a client application installed on a client terminal, on a communication network, said network entity comprising: a module receiving a set of marked DNS messages from a network entity according to claim 14; and- a module for processing the set of marked DNS messages, in order to deliver to the client application at least one DNS response adapted according to said network connectivity information. 16. Computer program implemented by a network entity on a communication network, said program comprising code instructions for implementing steps a), b), c) and / or d) of a method processing a request for resolving a name of a server, according to any one of claims 1 to 12, when the program is executed by a processor equipping said network entity.