FR3018411A1 - METHOD AND SYSTEM FOR PROCESSING A DNS QUERY ISSUED BY A NETWORK NODE DURING A DACCE ATTEMPT BY A CLIENT APPLICATION TO A REMOTE SERVER OVER AN IP NETWORK - Google Patents

Abstract

A method and system for processing a DNS request issued by a first network node (12; 1) during an access attempt by a client application (11) to a remote server (18) over an IP network. The method comprises steps of: - receiving the DNS request by a second network node (14; 12); obtaining, from the DNS query, a DNS identifier associated with a third network node (1, 12; 18); - Searching from the obtained DNS identifier, at least one record having a predefined format and containing network connectivity information relating to at least the third network node (1,12; 18); - if at least one record has been found, retrieving at least one record, and using the second network node (14; 12) connectivity information contained in at least one record to at least adapt the processing of the DNS request based on this connectivity information.

Description

Method and system for processing a DNS request sent by a network node during an access attempt by a client application to a remote server on an IP network Technical field The invention relates generally to the field of telecommunications and more specifically, client-server type communications in an IP (Internet Protocol) based communication network. In particular, a method and system for processing a DNS request issued by a network node during an access attempt by a client application to a remote server over an IP 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 the following version 6 of the IP protocol. A network address of the IPv4 type is coded on four bytes (32 bits), for example 193 193.55.67. 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. In addition, a network entity can be identified by one or more network addresses of the same type, IPv4 or IPv6. It can also be simultaneously identified by several IP addresses of different type. The network address of a network entity allows the determination of a path through the network to reach this network entity. Routing protocols, static or dynamic, make it possible to determine a path between two entities connected to a network such as the client application and the destination server. The Internet currently consists of a set of interconnected networks, some of IPv4 type, others of IPv6 type or of "dual stack" type. Since IPv4 and IPv6 addresses are not compatible, communication between a network device with only IPv6 addresses and network equipment with only IPv4 addresses is a problem. Two approaches are then possible to allow such communication: the translation of protocols and the "dual stack", which define mechanisms, some of which are standardized by the Internet Engineering Task Force (IETF) and published in form. technical specifications called Request For Comments (RFC). Concerning the translation of protocols, one can cite the NAT64 mechanism (Network Address Translation 64) allowing an IPv6 client equipment to join an IPv4 server equipment. 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. Moreover, in order to facilitate the search for computing resources on the Internet by the users 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 has a tree structure in which higher-level domains (referred to as Top Level Domains (TLDs)) are 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 end of a branch is called a host, and is a machine or an entity in the network. The host name assigned to it must be unique in the domain under consideration, or if applicable in the subdomain. For example, the web server of a domain usually has the name "www". The term "domain" formally corresponds to the suffix of a domain name, that is to say the set of tags of the nodes of a tree, with the exception of the host. 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 an FQDN name makes it possible to uniquely locate a machine on the Internet, and thus makes it possible to identify 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 for obtaining an IP address (for example: 193.43.55.67) of a network equipment (for example a multimedia content server) considered, from an FQDN name assigned to this equipment ( for example: 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 resolve a FQDN 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 a web browser wants to connect to a host known by its name FQDN (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 name 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 discussed in detail in IETF RFC 1035, particularly sections 3.2 and 4.

With the IPv4 to IPv6 transition referred to above, the IP protocol, the interconnection of IPv4 and IPv6 type IP networks, brings equipment or network nodes identified by IPv4 or IPv6 type IP addresses, or by addresses of both types. , having to communicate with each other. Some of these devices are compatible only with IPv4 (IPv4 only), others are only compatible with IPv6 (IPv6 only), others are compatible with both types of IP (dual stack). In this context, the resolution of a FQDN name requested by a client application to reach a remote server may result in it obtaining several IP addresses, IPv4 and IPv6, making it possible to reach 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 name server, in order to make possible or optimize the communication between the client application and the server. remote, in terms of quality of service (QoS) and the quality of the user experience (QoE or perceived quality). RFC 6724 of the IETF describes two address selection algorithms for version 6 of the internet protocol (IPv6), one for the selection of the source address (address of the client equipment initiating the communication) the other for selection of the destination address (address of the server equipment). Concerning in particular the selection of the destination address, this document recommends, in the case where the server entity is accessible via several different type of network addresses (IPv4 and IPv6), that the client entity preferentially selects IPv6 addresses if it itself has an IPv6 address (source address). This selection criterion aims at favoring the gradual abandonment of IPv4 on the Internet, but does not take into account the better performances that can be obtained if necessary by the establishment of a communication only IPv4 with the server entity, when the client entity has an IPv4 address in addition to the IPv6 address.

On the other hand, in the case where the server entity is accessible via several network addresses of the same type (for example IPv4), it is then recommended that the client entity uses the IP addresses obtained by DNS resolution according to the order in which they appear in the records (RRs) contained in the DNS response. Thus, if a first communication attempt fails with a given IP address, the client entity retries with the next IP address and so on. The maximum number of attempts to establish communication with the server entity is set by the client application. It will be understood that with this latter method of selection, the more the number of effective attempts to establish communication increases and the quality of user experience is degraded.

The IETF RFC 6555 defines requirements for address selection algorithms for dual-stack client hosts to improve the user experience. In particular, it is proposed in this document to record in a cache memory of the client entity the result of each connection attempted to a server using the IPv4 address or the IPv6 address associated with the server. When trying to connect to the server again, if the last attempt using one of the two addresses (IPv4 or IPv6) failed, then the client application will have to prefer the other address for the new one. attempt. The selection method proposed in the aforementioned document makes it possible to reduce the number of simultaneous attempts of IPv4 or IPv6 connections made by a dual-stack client to a dual-stack server, but requires the updating of client applications and systems. operation, and does not guarantee a better quality of customer experience once the connection is established; in fact, for example, a rapidly established IPv4 or IPv6 connection may then be unsatisfactory from the point of view of the bit rate observed during the data exchange between the client and the server (for example a multimedia document downloaded from streaming). In another example, a Dual Stack terminal that selects the IPv6 connection due to its speed, can then observe a degradation of the user experience related to the absence of certain functions of the service, which would be available only in IPv4.

Thus, none of the network address selection methods discussed above seem sufficiently efficient to ensure a good quality of user experience. In other words, the current methods of DNS query processing - for the resolution of domain names (DNS resolution) or network address (reverse DNS resolution) -, in a context of coexistence of IPv4 and IPv6 addresses, in particular following an attempt to connect a user terminal to a server on an IP network, suffer from variable performance that penalizes the quality of user experience. DISCLOSURE OF THE INVENTION The present invention aims at improving the situation described above by proposing, according to a first aspect, a method of processing a DNS request sent by a first network node during an access attempt by a user. client application to a remote server on an IP network. According to the invention, this method comprises the steps of: receiving said DNS request by a second network node; obtaining, from the DNS query, a DNS identifier associated with a third network node; searching, from the obtained DNS identifier, at least one record having a predefined format and containing network connectivity information relating to at least the third network node; if at least one record has been found, retrieval of at least one record, and use by the second network node of the connectivity information contained in at least one record for, in particular, adapting the processing of the DNS request according to this information of connectivity. The obtaining according to the invention of network connectivity information, during the processing of a DNS request, makes it possible to significantly improve this processing by allowing, in particular, depending on the use case considered, to adapt the network mechanisms involved. in DNS processing, such as the adaptation of DNS responses or the selection of the best network path or the translation of IP packets (IPv4 to IPv4 or IPv4 to IPV6 and vice versa), depending on the constraints of the client application and / or the user terminal, or the remote server that the client application is trying to access. According to a particular characteristic of the invention, the aforementioned step of searching, from the obtained DNS identifier, of at least one record containing network connectivity information relating to the third network node, comprises: sending by a client module installed in the second network node for a server module installed in a fourth network node, of a specific request message containing at least the DNS identifier, in order to obtain at least one record relating to the third network node; the search by the record server module corresponding to the DNS identifier and the sending to the client module of a specific response message containing the result of the search for records. Such an implementation of the registration search step containing network connectivity information, in the form of a client / server mechanism with a client module and a server module that can be implemented on separate entities or network nodes, allows to easily adapt this implementation according to the case of uses of DNS query processing, which we want to optimize. According to a first embodiment of the invention, the method is implemented in a network environment in which the first node is a local DNS server used by a client application, the second network node is an authoritative DNS server for the associated domain to the remote server, and the third node is a user terminal in which the client application or the local DNS server is executed. According to a first variant of the aforementioned first embodiment, the fourth network node is a DNS TLD (Top Level Domain) server. According to a second variant of the first embodiment mentioned above, the fourth network node is the local DNS server.

According to a second embodiment of the invention, the method is implemented in a network environment in which the first node is a user terminal, the second network node is a local DNS server used by the user terminal, and the third node is the remote server. According to a characteristic of this second embodiment, the fourth network node is an authoritative DNS server for the domain associated with the remote server. According to implementation features of the method of the invention which are common to the two embodiments: A request message according to the invention is a data structure organized in a format comprising at least the following elements: a header containing at least one sequence number; a message body containing at least: a field containing the DNS identifier. - A response message according to the invention is a data structure organized in a format comprising at least the following elements: a header containing at least: a sequence number, this sequence number being identical to that of the corresponding request message , and a return code indicating a record search result; a message body containing at least: a field containing the DNS identifier and at least one record, if at least one record has been found. A record according to the invention corresponding to a considered network node is a data structure organized in a format comprising at least the following fields: a first field containing a DNS identifier relating to the network node; a second field containing data representative of at least one type of network connectivity available for joining the network node; a third field containing data representative of a usage preference of one type of network connectivity among several types of network connectivity to join the node. In practice, according to an embodiment of the invention, the DNS identifier associated with the third network node is at least one domain name obtained by the second node from a network address associated with the third network node. Such a domain name may include a Domain Name (DN) or an FQDN. Correlatively, according to a second aspect, the invention relates to a system for processing a DNS request sent by a first network node during an access attempt by a client application to a remote server on an IP network, comprising: means for receiving said DNS request by a second network node; means for obtaining, from the DNS query, a DNS identifier associated with a third network node; means for obtaining, from the obtained DNS identifier, at least one record having a predefined format and containing network connectivity information relating to at least the third network node; means for the second network node to process the connectivity information contained in at least one record, in particular to adapt the processing of the DNS request according to the connectivity information.

In particular, according to an embodiment of the system according to the invention, the means for obtaining at least one record from the DNS identifier include: a client module installed in the second node, configured to generate and sending to a server module a specific request message containing at least the DNS identifier, in order to obtain at least one record relating to the third network node; the server module, installed in a fourth network node, configured to receive the request message and then search for records corresponding to the DNS identifier, and send to the client module a specific response message containing a search result of recordings.

Therefore, the present invention also relates to a client module installed in a network node, implemented in the aforementioned system, and a server module installed in a network node, implemented in a aforementioned system, according to the invention. invention. In practice, the means constituting the invention which are included in the various network nodes mentioned above, and in particular the client and server modules according to the invention, as briefly described above - and whose operation allows to implement particular the search step from a DNS identifier obtained, at least one record having a predefined format and containing network connectivity information relating to a network node -, are essentially implemented in software form that is to say say one or more computer programs stored in one or more memories, of RAM (Random Access Memory), ROM (Read Only Memory) or magnetic type (hard disk for example), and executed by a processor incorporated in the considered network node . Therefore, according to a last aspect, the present invention also relates to a computer program implemented in one or more network nodes, this program comprising code instructions whose execution by a computer processor causes the implementation of any or part of the steps of a method of processing a DNS request, according to the invention. 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 advantages provided by a system for processing a DNS query, a client module or a server module, as well as a computer program, according to the invention, as briefly described above, are identical or contribute to those mentioned above in relation to the method of processing a DNS query 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 according to a first embodiment; 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 for obtaining network connectivity information, according to the first embodiment of the invention; FIGS. 5 and 6 respectively represent the format of a request and a response for obtaining connectivity information, according to a implementation compliant with the DNS protocol, applicable to the first variant of the first embodiment; FIGS. 7 and 8 respectively represent the format of a request and a response for obtaining connectivity information, according to an implementation outside the DNS protocol, applicable to the first variant of the first embodiment; FIGS. 9 and 10 respectively represent two examples of request formats for obtaining connectivity information, according to an implementation compliant with the DNS protocol, applicable to the second variant of the first embodiment; FIGS. 11 and 12 respectively represent two examples of connectivity information obtaining response formats, according to a DNS protocol implementation, applicable to the second variant of the first embodiment; FIGS. 13 and 14 respectively represent two examples of request formats for obtaining connectivity information, according to an implementation outside the DNS protocol, applicable to the second variant of the first embodiment; FIG. 15 represents the format of a response for obtaining connectivity information, according to an implementation outside the DNS protocol, applicable to the second variant of the first embodiment; FIG. 16 represents a network environment according to a second embodiment of the invention; and FIG. 17 is a flowchart illustrating a method for obtaining network connectivity information, according to the second embodiment of the invention. DETAILED DESCRIPTION OF THE INVENTION FIG. 1 represents the topography of a network environment in which the present invention is implemented according to a first embodiment. In FIG. 1, a client application 11 installed on a user terminal 1 must establish a communication with a remote server 18. In order to communicate with the server 18, the client application 11 uses the domain name associated with the server 18, it transmits to a module (not shown) resolving (resolver) domain name installed on the terminal, which resolution module is responsible for obtaining the IP address (s) associated with the server 18 and that the client application 11 will have to use to exchange data with the server. Once the IP addresses associated with the server 18 are returned to the user terminal 1, a network address selection module on the terminal 1 is responsible for determining the IP address associated with the server 18 that the client application 11 must use to establish a communication.

Here it is specified that: - by "client application" (11), any software application installed on a communicating device, such as, for example, a web browser, an FTP client (File Transfer Protocol), an email client etc. ; - "communicating equipment" means any computer device such as, for example, a user terminal (1) such as a computer, a mobile telephone, or a digital tablet, used by a user to access a service on the Internet , or on a corporate 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 (eg video), etc. Back to FIG. 1, the entity 12 is a network equipment device performing at least one switching function for routing incoming packets through networks 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 for the client application 11. Depending on the environments considered, the 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). When an attempt is made to connect the client application 11 to the remote server 18, the client application 11 therefore exchanges with the module 12a the equipment 12, which acts as a local DNS server for the terminal 1. DNS information blocks for resolving the name of the server 18 into one or more network addresses. The module 12a optimizes the performance of the network by reducing the number of exchange of DNS information blocks exchanged with the network, by managing a cache 12c in which are stored previous DNS responses, with a validity period TTL (Time To Live) predefined. The local name server 12a also comprises a database 12d in which are stored DNS records corresponding to the terminals of the users of the network to which the user terminal 1 is connected. When the information (network addresses) relating to the server 18, searched by the client application 11, are not obtained from the DNS records stored temporarily in the cache 12c of the local DNS server 12a, the latter communicates with an entity 14, authoritative name server, to obtain it. If the latter can not provide the requested information, it exchanges DNS information blocks with a root DNS server, 13, to obtain them. The routing device 12b then follows the 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 the data packets between the client application 11 and the server 18. The authoritative name server 14 comprises in particular the entity 14a which is responsible for the processing of the DSN requests, and a database 14c containing the 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). According to the invention, the authoritative DNS server entity 14a also has a cache memory 14c 'whose structure makes it possible to store associations between a network address (of the IPv4 or IPv6 type) and an FQDN. These associations represent entities such as the local DNS server 12 and come from exchanges between the server 14 and entities such as the local DNS server 12 during previous address resolution operations.

The authoritative DSN server 14 also has a buffer structure 14d, in order to temporarily store network addresses of IPv4 or IPv6 type and, where appropriate, associations between a network address and an FQDN. The network environment shown in FIG. 1 also comprises a routing equipment 17 connected to the network in which the server 18 is located, and intended to route data packets to the server 18, based on routing rules. or address translation (NAT) rules. The network environment also includes a TLD name server, 16, comprising at least one top level domain name server module (16a) and a local DNS database (16b) for managing the different DNS records corresponding to the servers. DNS such as the local DNS server 12.

According to the invention, the network environment shown in FIG. 1 comprises a device for obtaining network connectivity information relating to certain nodes or network equipment located in the environment of FIG. 1. According to the embodiments envisaged, the information obtained may relate to the client application 11, the terminal or 1 of the end user, or the remote server 18. More generally, the system described allows any computer device or intermediate equipment to obtain information network connectivity for certain nodes or network devices. This obtaining device is referenced by the number 15 in the figures. According to the embodiment described and illustrated, it comprises several distinct functional modules distributed over different machines.

Such a device for obtaining network connectivity information thus makes it possible to provide information which, according to the use case, enables entity 12 or 14, or equivalent entities in the network, to adapt network mechanisms. such as DNS processing, the selection of the best network path, or the translation of IP packets, to the constraints of the entity 1, 12 or 18. For example, the entity 14 can adapt its DNS response describing the server entity 18 to IPv4 or IPv6 network connectivity constraints of the entity 1. By network information concerning a considered network entity, obtained by the device 15, it is necessary to understand data concerning the network properties of the network entity concerned. This network data is organized as one or more records, referred to herein as "Distributed Identity Protocol (DID) records". One or more DIP records can represent the same network entity. In practice, according to the implementation described, the device 15 for obtaining connectivity information comprises a client module and a server module, respectively called DIP client and DIP server in the context of the present description. According to an embodiment given by way of example, such a DIP record according to the invention comprises in particular the following fields: Name of the network entity: this field corresponds to the FQDN of the network entity. This field has a variable size. Domain Name (DN): This field corresponds to the domain name (DN) of the network entity when it manages several other different network entities with the same type of network connectivity. This field has a variable size. Validity period: This field corresponds to the Time To Live (TTL) of the record in cache 15b. Its value is dictated by the DIP server module. This field is 32-bit coded. Class: This field corresponds to the network class for which the registration is applicable. By default, this field corresponds to the Internet class. This field is coded on 16 bits.

Record Type: This field corresponds to the type of information stored in a cache of the DIP server (15b). By default, this field corresponds to the type "DIP" that must be registered with the IANA. This field is coded on 16 bits. Network Connectivity Type: This field corresponds to the types or families of network connectivity available to join the network entity identified by the FQDN field, or to join the managed network entities under the domain identified by the DN field. The caches (15b) of the DIP client and (15d) of the DIP server store as many DIP records as there are types of network connectivity per network entity. This field is coded on two bits as follows: a) '00': IPv4 not shared, b) '01': IPv4 shared, c) '10': IPv6, d) '11': Dual Stack.

Network Connectivity Type Usage Preference: This field corresponds to the usage preference of a type of network connectivity. It is necessary because a network entity can have several types of network connectivity (IPv4, shared IPv4, IPv6 or Dual Stack). This field is 8-bit coded. It contains a decimal value indicating the usage preference of a DIP record.

Network Connectivity Type Usage Priority: This field corresponds to the usage preference of a given type of network connectivity. It is necessary because a network entity can have several types of network connectivity simultaneously and several network addresses of the same type simultaneously. This field is 8-bit coded. It contains a decimal value indicating the usage priority of a DIP record. Network Connectivity Type Usage Weight: This field is the weight to be given to each usage preference of a type of network connectivity. Equally preferably, the type of connectivity to which the largest weight corresponds has priority. This field is used only if multiple records of equal priority exist. This field is coded on at least 8 bits. Port Number: This field corresponds to the port number on which a service is accessible, by type of network connectivity. A service is then identified by the pair: FQDN and port number. This field is used only when the entity identified by the FQDN field is a server. This field is coded on 16 bits.

As indicated above, the device for obtaining connectivity information according to the invention comprises several distinct functional modules which are distributed on different machines. In particular, depending on the implementation chosen, the device for obtaining connectivity information (15) may include modules instantiated on the authoritative DNS server 14 and on the DNS server TLD 16, or on the authoritative DNS server 14 and on the local DNS server 12. In the embodiments described below, the device 15 for obtaining network information, according to the invention, comprises a client module (DIP client) 15a and a server module (DIP server). 15c. With reference to FIGS. 2 and 3, a network environment according to a first embodiment of the invention will now be described, according to a first (FIG. 2) and a second variant (FIG. 3). In this first embodiment, the implementation of the method according to the invention is triggered by the reception by the DNS server 14a of a request-type DNS information block for the resolution of the name of the server 18 in one or more multiple network addresses.

According to the first embodiment presented, the DIP client module 15a is located in the authoritative DNS server 14 or at a proximity such that the communication between the DIP client 15a and the DNS server 14 can be done without loss or latency (high-performance network ). According to the first variant of this embodiment, illustrated in FIG. 2, the DIP server module 15c is located in the DNS server TLD 16. As represented in FIG. 2, the DIP client module 15a manages a cache memory 15b in which are stored network information including the local DNS server 12a. However, the cache 15b may also contain network information on the client application 11 and on the terminals (1) of the user or servers such as the server 18. The network information stored in the cache 15b represents network properties of the network entity concerned. This network data is organized as one or more DIP records as defined above. The DIP client module 15a uses a buffer-type volatile memory 15b '. The buffer 15b 'temporarily stores one or more DIP records. The client module DIP also manages a memory association table 15d ', making it possible to associate a DNS query generated by the local DNS server 12a with a request DIP specific to the invention, making it possible to obtain network information that is useful for the processing of the DNS query. The association between a DNS request and a DIP request is made by the respective sequence numbers.

It can also be provided that the memory 15d 'stores in addition to sequence numbers, a timer, a number of retries (retries) for sending DIP requests made, as well as a copy of the DIP request generated following the reception of DIP requests. a DNS query. The DIP server module 15c - present in the DNS server TLD 16 according to the first variant of the first embodiment (FIG. 2) and in the local DNS server 12, according to the second variant (FIG. 3) - manages a memory 15d in which are stored network information, in the form of DIP records whose structure has been exposed above. As already mentioned, the stored network information may, depending on the implementation, relate to one or more local DNS servers 12a or one or more client applications (11), to user terminals (1), or to resource servers such as the server 18. In practice, in the first variant, the DIP server 15c is merged with the resolver module (16a) of the DNS TLD server. The DIP server 15c manages a database 15d intended to store records containing the network data according to the invention ("DIP data"). This database 15d can be confused with the database 16b specific to the DNS server TLS, or independent of the latter. The memory 15d is fed with DIP information according to the invention, during the initial registration of each local DNS server (12) with the DNS server TLD 16. The Internet Registrar (Registrar) who is responsible for the DNS server 16 may offer the subscription to a service providing DIP records according to the invention, either by default or in the form of a free or paid option. The "DIP service" thus enables end users using the local DNS server (12) to obtain a better quality Internet experience, when accessing servers (18) offering services on the Internet (for example providing content).

According to the second variant, illustrated in Figure 3, the DIP server module 15c is located in the entity 12. The latter comprises the module 12a corresponding to the name server itself. The local DNS server 12a also comprises a database 12d in which it stores the DNS records corresponding to the terminals (1) of the end users. In the implementation chosen, the DIP server module 15c is confused with the module 12a of the local DNS server. The DIP server 15c manages the database (memory) 15d in which are stored the records containing the network data DIP according to the invention, as defined above. The database 15d may be confused with the database 12d specific to the local DNS server 12, or independent of the latter.

The database 15d is in any case previously supplied with network information according to the invention, that is to say in "DIP records", these records concerning in particular end users considered as a whole or individually. In this case, the local operator can offer the subscription to the "DIP service" according to the invention, either by default, or in the form of a free or paid option. The local operator can also collect the network information according to the invention (DIP) in the network automatically, or add them beforehand to the request of the end user who has subscribed to the DIP option in order to benefit from the 'a better Internet user experience. Fig. 4 is a flowchart illustrating a method of obtaining network connectivity information, according to the first embodiment of the invention. The method starts with step E60 in which the authoritative DNS server 14 receives a DNS request from the local DNS server 12a to obtain the network address of the server 18. In step E61, the module 14a of the authoritative DNS server identifies the source network address of the DNS request received in step E60 and stores it in the buffer 14d. In step E62, the module 14a of the authoritative DNS server consults its cache memory 14c 'to determine the FQDN identifier of the local DNS server 12 corresponding to the network address, in practice an IP address, identified in step E61. If the cache memory 14c 'contains the FQDN identifier of the local DNS server (12), then proceed to step E63, during which the authoritative DNS server (module 14a) reads the FQDN identifier of the local DNS server. 12 and updates the buffer 14d. The authoritative DNS server (14a) then executes step E65. On the other hand, if in step E62, the cache 14c 'does not contain the FQDN identifier of the local DNS server (12), it proceeds to the step E64 during which the authoritative DNS server (14) obtains the FQDN identifier of the local DNS server (12) by performing an inverse resolution of the network address of the local DNS server. For this purpose, a query is made to the Internet domain "in-addr.arpa", if the network address used by the local DNS server is of type IPv4, or the Internet domain "ipv6.arpa", if the The network address used by the local DNS server is IPv6. The authoritative DNS server (module 14a) then updates, on the one hand, the cache 14c 'with the network address of the local DNS server 12 and the associated FQDN identifier, and on the other hand, the buffer memory (buffer 14d) with the network address association of the local DNS server (12) and the FQDN identifier. The authoritative DNS server (14a) then proceeds to step E65. However, in a particular implementation where the DIP client module 15a is not confused with the authoritative DNS server (module 14a), the authoritative DNS server goes from step E64 or E63, as the case may be, to step E65 ' during which the authoritative DNS server (14a) sends to the client DIP (15a), via a reliable network and without latency (for example a network using the optical fiber transmission), a message containing the sequence number of the DNS request to cause the generation of a DIP request, as well as the FQDN identifier of the local DNS server (12a). We then go to step E65.

In step E65, the DIP client (15a), having obtained the FQDN and the domain name (DN) of the local DNS server (12), consults its cache memory 15b in order to search for DIP records according to the invention containing network information about the local DNS server (12); the sought DIP records are those containing as FQDN identifier or as domain name (DN) those obtained in step E63 or step E64.

If at least one DIP record is found in the cache memory 15b, step E66 is proceeded to, during which the DIP client module 15a obtains the DIP records found by reading and stores them in the buffer 15b '. Then we go to step E73. However, in the aforementioned implementation in which the DIP client module 15a is not confused with the authoritative DNS server (module 14a), it goes from step E66 to step E71 'described below. On the contrary, if in step E65 no DIP record corresponding to the FQDN or the domain name (DN) of the local DNS server (12) has been found in the cache memory 15b, proceed to step E67 (or E67 '). At this stage, in order to obtain such DIP records according to the invention, the DIP client module 15a generates one or more requests ("DIP request") for the DIP server module 15c according to the invention. Obtaining DIP records according to the invention is implemented according to two variants respectively corresponding to the case where the DIP server 15c is merged with the TLD server 16a (FIG. 2) - variant "Ml-V1" - or where the DIP server 15c is confused with the local DNS server 12a (Figure 3) - variant "M1-V2". Steps E67-E70 (and E67'-E70 ') are detailed below in the description according to the considered embodiment variant (M1-V1, M1-V2). If the DIP client module 15a receives from the DIP server 15c one (or more) response ("DIP response") following the sending of one or more DIP requests, it verifies (step E68) their integrity, in accordance with the variants of step E67 described below. If the received DIP response is valid, then the DIP client module 15a proceeds to step E69.

If, conversely, the received DIP response is not valid, then, according to the implementation exposed, a variable N initialized before a predetermined positive value, used as a counter of attempts to send DIP requests to the DIP server 15c, is tested. If the value of the variable N is not equal to zero, then the variable is decremented by 1, then it returns to the step E67 or E67 '. On the other hand, if the value of the variable is equal to zero, then the DIP client module 15a sets a return code of the DIP response message to the value '1' indicating a non-coherent message. The DIP client module 15a then proceeds to step E69. In step E69, the DIP client module 15a processes each of the received DIP responses. For this purpose, each of the DIP response messages is processed according to the return code indicated in the header of the DIP response message, in accordance with the embodiments described below in the description (variant Ml-V1 and variant Ml-V2 ). Regardless of the variant considered, the DIP client module 15a processes each DIP response message according to its return code (RC) as follows: - If RC = 0 ("Success"), this means that records DIPs containing network information relating to at least the local DNS server 12a have been obtained. The DIP client module 15a then proceeds to the step E71 during which the DIP client module 15a updates the cache 15b with the valid DIP records obtained in the step E69, and also purges the DIP records stored in the cache 15b , whose lifetime (TTL) has expired. The process then ends with a return code equal to zero. The DIP client 15a then proceeds to step E73. - If the RC # 0 ("Empty or Incoherent Response"), this means that the DIP client 15a could not obtain network information on the local DNS server 12a. The DIP client 15a then proceeds to step E72 during which no update of the cache 15b is performed. The process ends with a nonzero return code. Then we go to step E73. In an implementation according to which the DIP client module 15a is not confused with the authoritative DNS server 14a, but connected thereto by a reliable and latency-free network, for example a network using the optical fiber transmission, the DIP client 15a then going from step E71 or step E72 to step E71 '. In step E71 ', the DIP client module 15a sends to the authoritative DNS server 14a a message containing the sequence number of the DNS request that originated the generation of the DIP request, the FQDN of the local DNS server (12a). , as well as the DIP record (s) obtained. The authoritative DNS server (14a) then proceeds to step E73 during which it updates a cache memory with the information contained in the DIP records received in step E71 '. Step E73 represents the end of the method, according to the invention, of obtaining network information concerning in particular the local DNS server 12a and / or the user terminal 1. According to the use case considered, these network information DIPs may be used either by the authoritative DNS server (14a) or by other network entities for various purposes, for example to: - adapt DNS responses to the constraints of one or more network entities such as the user terminal; - enable, disable or adapt various mechanisms or services in the ISP network, taking into account the specificities and constraints of end-users, etc.

We will now detail obtaining DIP records according to the invention according to the two aforementioned embodiments.

The first variant, referred to herein as "M1-V1", corresponds to the case where the DIP server 15c is merged with the TLD server 16a, and whose network environment is illustrated in FIG. The second variant, designated as "M1-V2" in the present description, corresponds to the case where the DIP server 15c is merged with the local DNS server 12a, and whose network environment is illustrated by FIG. 1. First Variant of the 1st Embodiment (M1-V1) In this variant, the DIP server 15c is merged with the TLD server 16a as illustrated in FIG. 2. The steps E67-E70 (E67'-E70 ') will be detailed. ) of Figure 4 according to this variant (M1-V1) by considering two implementations: an implementation within the framework of the DNS protocol (designated M1-V1_i1) and an implementation outside DNS, that is to say independent the DNS protocol (designated M1-V1_i2). 1.1. DNS Implementation (M1-V1 i1) Figures 5 and 6 respectively represent the format of a network connectivity DIP information request and response, in a DNS-compliant implementation, applicable to the first variant. (M1-V1) of the first embodiment. In this implementation, in step E67, the client module 15a generates, for the server module 15c, one or more DNS requests of the DIP type whose format is illustrated in FIG. 5. Routing means then determine a better path to the server DIP 15c.

The DIP client 15a manages in memory 15d a table for associating the DNS request received from the local DNS server (12a) with the generated DIP request. The DIP client 15a updates the table 15d '. On receipt of the DIP type DNS request by the DIP server module 15c, the latter, in step E70, first searches its local database 15d in order to find DIP records corresponding to the identifier FQDN of the local DNS server 12a. It then generates a DIP-type DNS response, that is, a DNS response containing zero, one or more DIP records found in the local database 15d, and then finally sends the DNS DIP response to the DIP client 15a. . Routing means determine the best path to the DIP client 15a.

The format of a DNS DIP response according to this implementation represented in FIG. 6. Thus, according to the format represented, the RDATA field contains zero, one or more DIP records containing at least the following fields as defined above in the description: - Domain name (DN) of the network entity; - Type of network connectivity; - Use preference of the type of network connectivity; - Use priority of the type of network connectivity; - User weight of the type of network connectivity; - Port number. The DNS implementation (M1-V1_i1) requires prior reservation and registration of the type of DNS record of type "DIP" with the IANA. On the other hand, it requires extending the DNS protocol to support the generation of DIP-type DNS queries, the storage of DIP-type DNS records, and the generation of DNS-type DIP responses. 1.2. Non-DNS implementation (M1-V1_i2) Figures 7 and 8 respectively represent the format of a request and a response for obtaining connectivity information, according to a non-DNS implementation, applicable to the first variant (M1-V1_i2). V1) of the first embodiment.

In this second implementation, in step E67, the DIP client 15a generates, for the DIP server 15c, one (or more) request of the DIP type, which is routed by routing means to the DIP server 15c. However, unlike the previous implementation (M1-V1_i2), the DIP request is generated independently of the DNS protocol. Figure 7 shows the format of a non-DNS protocol DIP request, according to this second implementation. Figure 8 shows the format of a non-DNS protocol DIP response, according to this second implementation. The message header is common to request or response type DIP messages. As a result, it contains the following fields: - Sequence ID: This field is coded on 16 bits. It is necessary for the identification of a DIP transaction (request / response). All responses have the same sequence number as the corresponding request. - Flags: - Flag 'QR': this field is coded on 1 bit. It indicates the type of the message (QR = 0 if Question, QR = 1 if Answer); - Flag 'AA': This field is coded on 1 bit. It indicates whether the DIP response comes from an authoritative name server or not. - Flag 'TC': Flag TC: This field is coded on 1 bit. It indicates whether the DIP response is truncated or not. - Flag 'Z': This field is coded on 1 bit. He is reserved. - RCODE (Return Code): This field is 4-bit coded and is used only in a DIP response. It can contain one of the following values: - 0: to indicate success, that is, one or more DIP responses were found. - 1: to indicate that the domain is well managed by the TLD server (16) but that no DIP response record corresponding to the DATA field has been found. - 2: to indicate that a system problem has occurred in the DIP server module (15c), which could not process the DIP request. - 3: to indicate that no domain corresponding to the DATA field has been found. - 4: to indicate that the DIP message is non-coherent. - 5-15: reserved values. - Checksum: this field is coded on 8 bits. It is necessary for the integrity management of DIP exchanges. Its content is calculated by applying a hashing algorithm on the entire DIP message (header (without checksum) and body). On receipt of a DIP message, the receiving entity recalculates the checksum using the same hash algorithm and compares the result with the contents of the checksum field. If the DIP message is corrupted, it is silently deleted. The body of a DIP message depends on the type of the DIP message (request or response). The body of a request type DIP message (Figure 8) contains the following fields: - TYPE: This field is coded on 16 bits. It indicates the type of the request. Only one type is defined in this version which is the DIP type. - TTL: this field is coded on 32 bits. It indicates the time of validity (Time To Live) of a DIP message. It is used for caching DIP messages. - DATA LENGTH: This field is coded on 16 bits. It indicates the size of the DATA field. - DATA: this field is of variable size. It indicates the FQDN or DNS of the local DNS server (12). A DIP request is sent (Figure 4, step E67) by default on a User Datagram Protocol / Internet Protocol (UDP) packet to the DIP server (15c). UDP is used to avoid latency issues related to establishing a TCP connection. Alternatively, a DIP request may be sent using Transmission Control Protocol / Internet Protocol (TCP / IP), particularly at step E67 '(FIG. 4), to the DIP server (15c). Finally, when sending each DIP request, the client module DIP (15a) updates the data structure (table 15d ') by: - inserting the sequence number of the DNS query which is at the origin of the generation of the DIP request; - triggering a timer; updating the variable N whose value is indicative of the number of attempts to send to the device 15c (DIP server); - creating a copy of the generated DIP request, which is stored in a buffer memory. The corresponding line of the table (15d ') is purged if one of the following conditions occurs: - when the timer expires and the maximum number of attempts to send to the DIP server (15c) is reached; - upon receipt of a valid DIP response (ie, undistorted, unduplicated, with an error code indicating success).

Thus, referring again to FIG. 4, once a DIP request has been sent by the DIP client module 15a to the DIP server module (15c), the client module DIP proceeds to the step E68 already described. Upon receipt of the DIP request, the DIP server (15c) checks the integrity of the DIP request in (step 70) by calculating the checksum of the message, by applying the same hash algorithm as that used by the client module DIP ( 15a), on the header and the body of the received DIP request, and then comparing the calculated value with the value of the checksum present in the header of the received DIP request. If the DIP request is invalid then the DIP server 15c deletes it "silently" that is to say without transmitting a response message. In a variant, the DIP server (15c) deletes the invalid DIP request and generates an empty response type DIP message whose return code is equal to 3. In this case, the value of the sequence number is the same as that of the DIP request to which the response message matches. On the contrary, if the DIP request is valid then the DIP server (15c) searches its local database (15d) of DIP records corresponding to the FQDN identifier of the local DNS server (12a), which identifier is indicated. in the DATA field of the DIP request. The DIP server then generates a DIP response containing zero, one or more DIP records found in the local database (15d). The format of the DIP response is shown in FIG. 8. Finally, the DIP response is sent to the DIP client module (15a).

In the transmitted DIP response, the DATA field (Figure 8) includes zero, one or more DIP records containing at least the following fields: - Domain Name (DN) of the relevant network entity (defined above). - Network connectivity type (defined above). - Use preference of the type of network connectivity (defined above). - Use priority of the type of network connectivity (defined above). - User weight of the type of network connectivity (defined above). - Port number (defined above). 2. Second Variant of the First Embodiment (M1-V2) In this variant, the DIP server 15c is merged with the local DNS server 12a, as illustrated in FIG. 3. The steps E67-E70 (E67'- E70 ') of Figure 4 according to this variant (M1-V2) by considering two implementations: an implementation within the framework of the DNS protocol (designated M1-V2_i1) and a non-DNS implementation, that is to say say independent of the DNS protocol (designated Ml-V2_i2). 2.1. DNS Implementation (M1-V2 il) FIGS. 9 and 10 respectively represent two examples of request formats for obtaining connectivity information, according to a DNS protocol implementation, applicable to the second variant of the first embodiment. FIGS. 11 and 12 respectively represent two examples of connectivity information obtaining response formats, according to a DNS protocol implementation, applicable to the second variant of the first embodiment. In this implementation, the DIP client module (15a) generates (step E67, FIG. 4), destined for the DIP server module (15c), one or more DIP type DNS requests whose format is defined below. According to a first example, the local DNS server (12) on which the DIP server module (15c) is installed manages a population of end users with network connectivity of the same type. In this case, the DIP client module (15a) generates, to the DIP server module (15c), DIP DNS request messages whose format is represented in FIG. 9. According to a second example, the local DNS server (12) ) on which the DIP server module (15c) is installed manages a population of end users with heterogeneous network connectivity. In this case, the DIP client module (15a) generates DNS DIP request messages, the format of which is shown in FIG. 10, for the DIP server (15c).

In Figure 10, the EDNSO DATA field is carried in the "Additional section" portion of the DNS request according to the specifications of IETF RFC 2671 (Extension Mechanisms for DNS (EDNSO).) The OPT RR field for the 'DIP' protocol 'according to the invention contains the field RDATA which indicates (on 16 bits) the identifier (ID) of the DNS request which is at the origin of the request DNS DIP.

The client module DIP (15a) manages in memory (15d ') a table for associating a DNS query generated by the local DNS server (12a) with the request DIP. The (DIP client) 15a updates the structure 15d '(it then goes to the step E68 of FIG. 4). Upon receiving the DIP type DNS request, the DIP server (15c) performs (step 70) first a search in its local database (15d) of DIP records corresponding to the received DIP request. If one places oneself in the case of the first example above, the DIP server (15c) searches in its local database (15d) for DIP records corresponding to the FQDN identifier of the local DNS server (12a). If one takes the case of the second example above, the DIP server (15c) searches in its local database (15d) for DIP records corresponding to the end user source of the DNS query whose identifier is indicated in the field RDATA (on 16 bits). The DIP server module then generates a DIP-type DNS response corresponding to the received DIP request, i.e. a DNS response containing zero, one or more DIP records found in the local database (15d). The format of the DNS DIP response is according to the example considered (first or second) according to FIG. 11 (first example) or according to FIG. 12 (second example). The generated DNS DIP response is then sent to the DIP client module (15a) via an optimal path determined by routing means. In the DIP response messages whose format is shown in Figures 11 and 12, the RDATA field contains zero, one or more DIP records containing at least the following fields: - Domain name (DN) of the network entity concerned ( defined above). - Network connectivity type (defined above). - Use preference of the type of network connectivity (defined above). - Use priority of the type of network connectivity (defined above). - User weight of the type of network connectivity (defined above). - Port number (defined above).

The DNS extension field (EDNSO) for DIP (Figure 12) contains the identifier (ID) of the DNS request that generated the DIP request message. This identifier is copied from the corresponding DIP request (FIG. 9 or 10). 2.2. Non-DNS Implementation (M1-V2 i2) FIGS. 13 and 14 respectively represent two examples of connectivity information obtaining request formats, according to a non-DNS protocol implementation, applicable to the second variant of the first embodiment. FIG. 15 represents the format of a connectivity information obtaining response, according to a non-DNS protocol implementation, applicable to the second variant of the first embodiment.

In this implementation, the DIP client module (15a) generates (step E67, FIG. 4), destined for the DIP server module (15c), one or more DIP type DNS request (s) whose format is defined below, according to the two examples (first and second) described above (2.1 DNS implementation). According to the first example, that is to say, when the local DNS server (12) on which the DIP server module (15c) is installed manages a population of end users with network connectivity of the same type, the client module DIP (15a) generates, to the DIP server module (15c), DIP request messages (excluding DNS) whose format is shown in FIG. 13. According to the second example, that is to say when the DNS server local (12) on which is installed the DIP server module (15c) manages a population of end users with heterogeneous network connectivity, the client module DIP (15a) generates DIP request messages (15c) to the DIP server (out DNS) whose format is shown in Figure 14. The header of the message is common to the DIP message type or response type. As a result, it contains the following fields: - Sequence ID: This field is coded on 16 bits. It is necessary for the identification of a DIP transaction (request / response). All responses have the same sequence number as the corresponding request. - Flags: - Flag 'QR': this field is coded on 1 bit. It indicates the type of the message (QR = 0 if Question, QR = 1 if Answer); - Flag 'AA': This field is coded on 1 bit. It indicates whether the DIP response comes from an authoritative name server or not. - Flag 'TC': Flag TC: This field is coded on 1 bit. It indicates whether the DIP response is truncated or not. - Flag 'Z': This field is coded on 1 bit. He is reserved. - RCODE (Return Code): This field is 4-bit coded and is used only in a DIP response. It can contain one of the following values: - 0: to indicate success, that is, one or more DIP responses were found. - 1: to indicate that the domain is well managed by the TLD server (16) but that no DIP response record corresponding to the DATA field has been found. - 2: to indicate that a system problem has occurred in the DIP server module (15c), which could not process the DIP request. - 3: to indicate that no domain corresponding to the DATA field has been found. - 4: to indicate that the DIP message is non-coherent. - 5-15: reserved values. - Checksum: this field is coded on 8 bits. It is necessary for the integrity management of DIP exchanges. Its content is calculated by applying a hashing algorithm on the entire DIP message (header (without checksum) and body). On receipt of a DIP message, the receiving entity recalculates the checksum using the same hash algorithm and compares the result with the contents of the checksum field. If the DIP message is corrupted, it is silently deleted. The body of a DIP message depends on the type of the DIP message (request or response). The body of a request type DIP message (Figures 13 and 14) contains the following fields: - TYPE: This field is coded on 16 bits. It indicates the type of the request. Only one type is defined in this version which is the DIP type. - TTL: this field is coded on 32 bits. It indicates the time of validity (Time To Live) of a DIP message. It is used for caching DIP messages. - DATA LENGTH: This field is coded on 16 bits. It indicates the size of the DATA field. - DATA: this field is of variable size. It indicates the FQDN or DNS of the local DNS server (12) as part of the first example (Figure 13), and the identifier (ID) of the DNS query that originated the DIP query as part of the second example (Figure 14). A DIP request is sent (Figure 4, step E67) by default on a User Datagram Protocol / Internet Protocol (UDP) packet to the DIP server (15c). UDP is used to avoid latency issues related to establishing a TCP connection. Alternatively, a DIP request may be sent using Transmission Control Protocol / Internet Protocol (TCP / IP), particularly at step E67 '(FIG. 4), to the DIP server (15c).

Finally, when sending each DIP request, the client module DIP (15a) updates the data structure (table 15d ') by: - inserting the sequence number of the DNS query which is at the origin of the generation of the DIP request; - triggering a timer; updating the variable N whose value is indicative of the number of attempts to send to the device 15c (DIP server); - creating a copy of the generated DIP request, which is stored in a buffer memory. The corresponding line of the table (15d ') is purged if one of the following conditions occurs: - when the timer expires and the maximum number of attempts to send to the DIP server (15c) is reached; - upon receipt of a valid DIP response (ie, undistorted, unduplicated, with an error code indicating success).

The client module DIP (15a) manages in memory (15d ') a table for associating a DNS query generated by the local DNS server (12a) with the request DIP. The (DIP client) 15a updates the structure 15d '(it then goes to the step E68 of FIG. 4). Upon receipt of the DIP request, the DIP server (15c) checks the integrity of the DIP request in (step 70) by calculating the checksum of the message, by applying the same hash algorithm as that used by the client module DIP ( 15a), on the header and the body of the received DIP request, and then comparing the calculated value with the value of the checksum present in the header of the received DIP request. If the DIP request is invalid then the DIP server 15c deletes it "silently" that is to say without transmitting a response message. In a variant, the DIP server (15c) deletes the invalid DIP request and generates an empty response type DIP message whose return code is equal to 3. In this case, the value of the sequence number is the same as that of the DIP request to which the response message matches. On the contrary, if the DIP request is valid then the DIP server (15c) searches its local database (15d) of DIP records corresponding to the FQDN identifier of the local DNS server (12a), which identifier is indicated. in the DATA field of the DIP request. The DIP server then generates a DIP response containing zero, one or more DIP records found in the local database (15d). The format of the DIP response is shown in Figure 5. Finally, the DIP response is sent to the DIP client module (15a). In the transmitted DIP response, the DATA field (Figure 15) includes zero, one or more DIP records containing at least the following fields: - Domain Name (DN) of the relevant network entity (defined above). - Network connectivity type (defined above). - Use preference of the type of network connectivity (defined above). - Use priority of the type of network connectivity (defined above). - User weight of the type of network connectivity (defined above). - Port number (defined above).

With reference to FIGS. 16 and 17, a second embodiment of the invention will now be described, according to which the client module DIP (15a) is installed in the local DNS server (12) or even in the DNS resolver (11). ) of the client terminal (1), while the DIP server module (15c) is installed in the authoritative DNS server (14) which manages the server (18) to which the user wishes to access via his terminal (1).

Fig. 16 shows a network environment according to this second embodiment. In Fig. 16, the DIP client module 15c is shown as being installed in the local DNS server 12. Therefore, in this embodiment, the authoritative DNS server 14 receives from the local DNS server 12, a DNS request message of the "DIP" type according to the invention, in particular to obtain network information on the types of network connectivity of a remote server such as the server 18. FIG. 17 is a flowchart illustrating a method for obtaining information network connectivity according to the second embodiment of the invention. The method begins with step E60 in which the local DNS server 12 receives a DNS request from the user terminal (application 11) to access the server 18. The local DNS server (12a) identifies (step E61) then from the DNS query the FQDN corresponding to the server 18. In this embodiment, when the DIP client module (15a) is merged with the local DNS server (entity 12a), the process continues with the step E65. As a variant, when the client module DIP (15a) is not confused with the local DNS server (entity 12a), but connected thereto by a reliable and latency-free network, for example a network using optical fiber transmission, then we go to step E65 'during which the local DNS server (12a) sends the client DIP (15a) a message containing the sequence number of the DNS request to cause the generation of a DIP request, and the FQDN identifier of the server 18. We then go to step E65.

It will be noted here that in the network environment according to this second embodiment, the network obtaining method according to the invention can also be implemented in the context of an inverse DNS resolution, that is to say the process of determining, for a given network resource (here the server 18), an FQDN from a network address (IPv4 or Ipv6). In this case, in step E61, the local DNS server (12a) identifies from a DNS query of inverse resolution, the network address of the server 18. Similarly, when the client module DIP (15a) does not is not confused with the local DNS server (entity 12a), but connected thereto by a reliable and latency-free network such as a network using fiber optic transmission, then in step E65 'the local DNS server (12a) ) sends to the client DIP (15a) a message containing the sequence number of the reverse DNS request intended to cause the generation of a DIP request, as well as in this case the network address of the server 18. At step E65, the DIP client (15a), having obtained the FQDN as well as the domain name (DN) of the server 18, consults its cache memory 15b in order to search for DIP records according to the invention containing network information concerning the server 18; the searched DIP records are those containing as FQDN identifier or as domain name (DN), those obtained in step E61. When the original DNS request is a reverse resolution request, the searched DIP records are those corresponding to the network address (IPv4 or IPv6) of the server 18 obtained in step E61.

If at least one DIP record corresponding to the server 18 is found in the cache memory 15b, proceed to step E66, during which the DIP client module 15a obtains the DIP records found by reading and stores them in the buffer 15b ' . Then we go to step E73. However, in the aforementioned implementation according to which the client module DIP (15a) is not confused with the local DNS server (entity 12a), step E66 is moved to step E71 'described below. On the other hand, if in step E65 no DIP record corresponding to the FQDN or to the domain name (DN) of the server 18 (or corresponding to the server network address 18 in the event of an inverse DNS resolution) has been found in the cache memory 15b, we go to step E67.

In step E67, in order to obtain such DIP records according to the invention, the DIP client module 15a generates one or more requests ("DIP request") for the DIP server module 15c according to the invention. The process of obtaining DIP records according to this second embodiment can be implemented according to two variant embodiments, which are identical to those described above in the context of the first embodiment (first variant "Ml -V1" ): DNS implementation (M1-V1_i1) and non-DNS implementation (M1-V1_i2), in relation with Figures 5 and 6, and Figures 7 and 8 respectively. These two variants are therefore not reproduced in this part of the description .

Note that in the case where we consider an inverse DNS resolution, the FQDN field of the header of the DIP request (Figure 5, DNS implementation) and the DATA field of the DIP request body (Figure 7, implementation out DNS) contains the network address (IP address) of the server 18.

Returning to FIG. 17, in step E68, if the DIP client module 15a receives from the DIP server 15c one (or more) response ("DIP response") following the sending of one or more requests DIP, it checks their integrity, according to the embodiments of step E67 described below. If the received DIP response is valid, then the DIP client module 15a proceeds to step E69.

If, conversely, the received DIP response is not valid, then, according to the implementation exposed, a variable N initialized before a predetermined positive value, used as a counter of attempts to send DIP requests to the DIP server 15c, is tested. If the value of the variable N is not equal to zero, then the variable is decremented by 1, then it returns to the step E67 or E67 '. On the other hand, if the value of the variable is equal to zero, then the DIP client module 15a assigns a return code of the DIP response message a value of '4' indicating a non-coherent message. The DIP client module 15a then proceeds to step E69. In step E69, the DIP client module 15a processes each of the received DIP responses. For this purpose, each of the DIP response messages is processed according to the return code indicated in the header of the DIP response message. The DIP client module 15a processes each DIP response message according to its return code (RC) as follows: - If RC = 0 ("Success"), this means that DIP records containing network information relating to at least the server 18 have been obtained. The DIP client module 15a then proceeds to step E71, during which the DIP client module 15a updates the cache memory 15b with the valid DIP records obtained (step E69). The process ends with a return code equal to zero. Then we go to step E73. If the RC # 0 ("Empty or Incoherent Response"), this means that the DIP client 15a could not obtain network information on the server 18. The DIP client 15a then proceeds to step E72 during which no update of the cache 15b is performed. The process ends with a nonzero return code. Then we go to step E73. In an implementation according to which the DIP client module 15a is not confused with the entity 12a of the local DNS server, but in the network vicinity of the latter, so that it can be considered that these two entities are connected by a network reliable and latency-free (for example a network using fiber optic transmission), the DIP client 15a then moves from step E71 or step E72 to step E71 '. In step E71 ', the DIP client module 15a sends to the local DNS server (12a) a message containing the sequence number of the DNS request causing the generation of the DIP request, the FQDN of the server 18 (or its network address, in the case of reverse DNS resolution), as well as the DIP record (s) obtained. The local DNS server (12a) then proceeds to step E73 during which it updates, if necessary, a cache memory with the information contained in the DIP records received in step E71 '.

Step E73 represents the end of the method, according to the invention, of obtaining network information concerning, in this embodiment, in particular the remote server 18 to which the user terminal (1) tries to access. Depending on the use case considered, this DIP network information may be used either by the local DNS server (12a) or by other network entities, for various purposes, for example to: - adapt the DNS responses to the constraints of the network. one or more network entities such as a remote content server (server 18); - enable, disable or adapt various mechanisms or services in the ISP network, such as address translation, taking into account the specificities and constraints of server entities (server 18) on the network , etc.15

Claims (16)

REVENDICATIONS1. A method of processing a DNS request issued by a first network node (12; 1) during an access attempt by a client application (11) to a remote server (18) over an IP network, comprising steps of: - receiving (E60) said DNS request by a second network node (14; 12); obtaining (E61-E64) from the DNS query of a DNS identifier associated with a third network node (1,12; 18); - searching (E65, E67-E70) from the obtained DNS identifier, at least one record having a predefined format and containing network connectivity information relating to at least said third network node (1,12; 18); - if at least one record has been found, retrieving (E68, E69, E71) at least one record, and using (E73) by the second network node (14; 12) connectivity information contained in said at least one recording to at least adapt the processing of said DNS request according to said connectivity information. The method according to claim 1, wherein the step of searching from the obtained DNS identifier of at least one record containing network connectivity information relating to the third network node comprises: sending by a client module (15a) installed in the second network node (14; 12) to a server module (15c) installed in a fourth network node (16; 14) of a specific request message containing at least said identifier DNS, to obtain at least one record relating to the third network node (1,12; 18); - Searching by said server module (15c) records corresponding to said DNS identifier and sending to the client module of a specific response message containing the result of the search for records. The method of claim 2, wherein said first node is a local DNS server (12) used by a client application (11), the second network node is an authoritative DNS server (14) for the domain associated with the remote server ( 18), and the third node is a user terminal (1) in which the client application (11) or the local DNS server (12) is executed. The method of claim 2 combined with claim 3, wherein said fourth network node is a TLD DNS server (16). The method of claim 2 combined with claim 3, wherein said fourth network node is the local DNS server (12). The method of claim 2, wherein said first node is a user terminal (1), the second network node is a local DNS server (12) used by the user terminal (1), and the third node is the remote server (18). The method of claim 6, wherein said fourth network node is an authoritative DNS server (14) for the domain associated with the remote server (18). 10 The method according to any one of claims 2 to 7, wherein said request message is a data structure organized in a format comprising at least the following elements: a header containing at least one sequence number; A message body containing at least: a field (DATA) containing said DNS identifier. The method of claim 8, wherein said response message is a data structure organized in a format comprising at least the following elements: a header containing at least one sequence number, this sequence number being identical to that of the corresponding request message, and a return code indicating a record search result; a message body containing at least: a field (RDATA) containing said DNS identifier and at least one record, if at least one record has been found. 25 The method according to any of claims 1 to 9, wherein a record corresponding to a network node is a data structure organized in a format comprising at least the following fields: a first field containing a DNS identifier relative to said node network; A second field containing data representative of at least one type of network connectivity available for joining said network node; a third field containing a datum representative of a usage preference of one type of network connectivity among several types of network connectivity for joining said node. 35 The method according to any one of claims 1 to 10, wherein said DNS identifier associated with the third network node is at least one domain name obtained by the second node (14) from a network address associated with the third node. network (1,12; 18). A system for processing a DNS request issued by a first network node (12; 1) during an access attempt by a client application (11) to a remote server (18) over an IP network, comprising means for receiving said DNS request by a second network node (14; 12); means for obtaining, from the DNS query, a DNS identifier associated with a third network node (1,12; 18); means for obtaining, from the obtained DNS identifier, at least one record having a predefined format and containing network connectivity information relating to at least said third network node (1,12; 18); means for processing by the second network node (14; 12) connectivity information contained in at least one record, to at least adapt the processing of said DNS request according to said connectivity information. The system of claim 12 wherein said means for obtaining at least one record from the DNS identifier comprises: - a client module (15a) installed in the second node (14; 12) configured for generating and sending to a server module (15c) a specific request message containing at least said DNS identifier, for obtaining at least one record relating to the third network node (1,12; 18); said server module (15c) installed in a fourth network node (16; 14), configured to receive said request message and then search for records corresponding to said DNS identifier, and send to the client module a specific response message containing a result of the search for records. 14. Client module (15a) installed in a network node, implemented in a system according to one of claims 12 or 13. 15. Server module (15c) installed in a network node, implemented in a system according to one of claims 12 or 13. 16. Computer program implemented in a network node, said program comprising code instructions whose execution by a processor of the network node causes the implementation of at least the search step from a obtained DNS identifier, at least one record having a predefined format and containing network connectivity information relating to a network node, according to a method of processing a DNS query according to any one of claims 1 to 11.