FR 3018411 A1 20150911 FR 1451722 A 20140304 Procédé et système de traitement d'une requête DNS émise par un noeud réseau au cours d'une tentative d'accès par une application cliente à un serveur distant sur un réseau IP Domaine technique L'invention a trait de manière générale au domaine des télécommunications et plus précisément, les communications de type client-serveur dans un réseau de communication basé sur le protocole IP (Internet Protocol). L'invention concerne en particulier un procédé et un système de traitement d'une requête DNS émise par un noeud réseau au cours d'une tentative d'accès par une application cliente à un serveur distant sur un réseau IP. Etat de la technique Actuellement dans un réseau basé sur la pile de protocoles IP (Internet Protocol), désignée couramment par " réseau IP", tel que le réseau mondial Internet, chaque équipement connecté au réseau dispose d'au moins une adresse numérique qui permet de l'identifier de manière unique sur le réseau. Ces adresses sont actuellement de deux types "IPv4" et "IPv6". IPv4 correspond à la version 4 du protocole IP tandis qu'IPv6 correspond à la version 6 suivant du protocole IP. Une adresse réseau du type IPv4 est codée sur quatre octets (32 bits), par exemple 20 193.43.55.67. La croissance du nombre d'utilisateurs et de serveurs sur Internet s'accompagnant d'un épuisement des adresses IPv4 disponibles, cela conduit au développement de l'IPv6 permettant le codage d'une adresse IP sur 16 octets (128 bits). Par ailleurs, une entité réseau peut être identifiée par une ou plusieurs adresses réseau d'un même type, IPv4 ou IPv6. Elle peut aussi être identifiée simultanément par plusieurs 25 adresses IP de type différent. L'adresse réseau d'une entité réseau permet la détermination d'un chemin au travers du réseau permettant d'atteindre cette entité réseau. Des protocoles de routage, statiques ou dynamiques, permettent de déterminer un chemin entre deux entités connectées à un réseau telles que l'application cliente et le serveur de destination. L'Internet est formé actuellement d'un ensemble de réseaux interconnectés, les uns de 30 type IPv4, les autres de type IPv6 ou de type "double pile" (dual-stack). Les adresses IPv4 et IPv6 n'étant pas compatibles, la communication entre un équipement réseau ne disposant que d'adresses IPv6 et un équipement réseau ne disposant que d'adresses IPv4 constitue un problème. Deux approches sont alors possibles pour permettre une telle communication : la traduction de protocoles et la "double pile" (dual-stack), qui définissent des mécanismes dont 35 certains sont normalisés par l'IETF (Internet Engineering Task Force) et publiés sous forme de spécifications techniques appelées RFC (Request For Comments). Concernant la traduction de protocoles, on peut citer le mécanisme NAT64 (Network Address Translation 64) permettant à un équipement client IPv6 de joindre un équipement serveur IPv4. Concernant la "double-pile", un équipement ou noeud IP est dit "dual-stack" (DS) s'il embarque les deux piles protocolaires IPv4 et IPv6 et s'il est capable d'émettre, de recevoir et de traiter indifféremment des paquets IPv4 et IPv6. Par ailleurs, afin de faciliter la recherche de ressources informatiques sur l'Internet par les utilisateurs sans avoir à connaître l'adresse IP de ces ressources (serveur notamment), un système de nommage de ressources connu sous le nom de DNS (Domain Name System) a été créé. Le système DNS est décrit notamment dans les spécifications RFC 1034 et 1035 de l'IETF. Il repose sur trois composants essentiels : un espace de noms de domaines, un système de serveurs distribués, appelés serveurs de noms, et des programmes clients appelés "résolveurs" (resolvers en anglais). L'espace de noms de domaine (Domaine Name Space) possède une structure arborescente dans laquelle sont définis des domaines de niveau supérieur (appelés TLD, pour Top Level Domains), rattachés à un noeud racine (root node) représenté par un point. On appelle "nom de domaine" chaque noeud de l'arbre, chaque noeud possédant une étiquette (label) d'une longueur maximale de 63 caractères. L'ensemble des noms de domaine constitue ainsi un arbre inversé où chaque noeud est séparé du suivant par un point ("."). L'extrémité d'une branche est appelée hôte, et correspond à une machine ou une entité du réseau. Le nom d'hôte qui lui est attribué doit être unique dans le domaine considéré, ou le cas échéant dans le sous-domaine. A titre d'exemple le serveur web d'un domaine porte ainsi généralement le nom "www". Le terme "domaine" correspond formellement au suffixe d'un nom de domaine, c'est-à-dire l'ensemble des étiquettes des noeuds d'une arborescence, à l'exception de l'hôte. Le nom complet correspondant à l'ensemble des étiquettes des noeuds d'une arborescence, séparées par des points, et terminé par un point final, est appelé adresse FQDN (Fully Qualified Domain Name), c'est-à-dire "Nom de Domaine Totalement Qualifié". La profondeur maximale de l'arborescence est de 127 niveaux et la longueur maximale d'un nom FQDN est de 255 caractères. Ainsi un nom FQDN permet de repérer de façon unique une machine sur fInternet, et permet donc d'identifier un service fourni par un serveur sur le réseau. Par exemple, l'adresse "www.orange.fr" représente un nom FQDN. Les serveurs de noms (Name Servers) sont des machines permettant d'établir la correspondance entre un nom de domaine et une ou plusieurs adresses IP identifiant des machines ou équipements d'un réseau. Chaque domaine possède un serveur de noms appelé "serveur de noms primaire" (primary domain name server), et généralement un serveur de noms secondaire (secondary domaine name server), permettant de prendre le relais du serveur de noms primaire en cas d'indisponibilité de ce dernier. Chaque serveur de noms est déclaré dans un serveur de noms de domaine de niveau immédiatement supérieur, ce qui permet implicitement une délégation d'autorité sur les domaines. Le système DNS est une architecture distribuée, où chaque entité est responsable de la gestion de son nom de domaine. Un serveur qui dispose de toutes les informations concernant un domaine est désigné par serveur ayant autorité ou autoritaire (authoritative server) pour le domaine considéré. Le serveur de noms qui est autoritaire pour le domaine associé au noeud sous la racine (par exemple le noeud ".fr" dans l'adresse "www.orange.fr") est dit serveur de domaine de niveau supérieur ou "serveur TLD" ( Top Level Domain server). Enfin un serveur ayant autorité sur le domaine au dessus de domaine de plus haut niveau est appelé "serveur racine" (root server). Ainsi, un serveur de noms définit une zone, c'est-à-dire un ensemble de domaines sur lequel le serveur a autorité, il est alors dit "autoritaire" (authoritative) pour cette zone. Dans le système DNS, le mécanisme permettant d'obtenir une adresse IP (par exemple: 193.43.55.67) d'un équipement réseau (par exemple un serveur de contenus multimédias) considéré, à partir d'un nom FQDN attribué à cet équipement (par exemple : srv.mycompany.com) est désigné par "résolution de noms de domaine", le processus contraire (obtenir un nom de domaine à partir d'une adresse IP) étant désigné par "résolution inverse". Afin de pouvoir permettre de résoudre un nom FQDN, chaque machine cliente telle qu'un terminal d'utilisateur doit être équipée d'une application appelée résolveur (resolver) généralement intégrée dans le système d'exploitation de la machine. Lorsqu'une application cliente telle qu'un navigateur internet souhaite se connecter à un hôte connu par son nom FQDN (par exemple "www.orange.fr"), celle-ci va interroger un serveur de noms défini dans sa configuration réseau. Chaque machine connectée au réseau possède en effet dans sa configuration les adresses IP d'au moins un serveur de noms de son fournisseur d'accès. Ce serveur de noms est appelé usuellement "serveur de noms local". Ainsi, dans l'exemple de l'adresse "www.orange.fr" l'application cliente (navigateur internet par exemple) envoie une requête au serveur de noms local. Si celui-ci possède l'enregistrement dans son cache, il l'envoie à l'application cliente, dans le cas contraire il peut interroger un serveur TLD correspondant au domaine ".fr". Le serveur de noms TLD renvoie alors une liste d'adresses IP des serveurs de noms faisant autorité sur le domaine ".fr" afin de déterminer ensuite le serveur de nom faisant autorité sur le domaine ".orange". Le serveur de nom local interroge alors ce dernier afin d'obtenir l'adresse IP du serveur dont le nom FQDN est "www.orange.fr". Le mécanisme de résolution d'adresses tel qu'expliqué ci-dessus, repose sur un protocole de communication, le protocole DNS, comprenant la définition de messages DNS de différents types (requête, réponse en particulier) et d'informations (Resource Records - RR) associées à chaque nom de domaine, et enregistrées selon un format spécifique enregistrements DNS (ou Resource Records - RR) dans la base de données distribuée formée par l'ensemble des serveurs de noms de domaine. Le format des enregistrements DNS (RR) et des messages DNS est exposé en détail dans le document RFC 1035 de l'IETF, en particulier aux sections 3.2 et 4. Avec la transition IPv4 vers IPv6 évoquée plus haut, du protocole IP, l'interconnexion de réseaux IP de type IPv4 et IPv6, amène des équipements ou noeuds réseaux identifiés par des adresses IP de type IPv4 ou IPv6, ou par des adresses des deux types, à devoir communiquer entre eux. Parmi ces équipements, certains sont compatibles uniquement avec IPv4 (IPv4 only), d'autres sont compatibles uniquement avec IPv6 (IPv6 only), d'autres sont compatibles avec les deux types de protocole IP (dual stack). Dans ce contexte, la résolution d'un nom FQDN demandée par une application cliente pour atteindre un serveur distant peut aboutir à l'obtention par celle-ci de plusieurs adresses IP, IPv4 et IPv6, permettant de joindre le serveur distant. Il se pose alors le problème de la sélection par l'application cliente de l'adresse IP parmi des adresses IPv4 et IPv6 retournées par un serveur de noms, afin de rendre possible ou d'optimiser la communication entre l'application cliente et le serveur distant, sur le plan de qualité de service (QoS) et de la qualité de l'expérience utilisateur (QoE ou qualité perçue). Le document RFC 6724 de l'IETF décrits deux algorithmes de sélection d'adresse pour la version 6 du protocole internet (IPv6), un pour la sélection de l'adresse source (adresse de l'équipement client initiant la communication) l'autre pour la sélection de l'adresse de destination (adresse de l'équipement serveur). Concernant en particulier la sélection de l'adresse de destination, ce document préconise, dans le cas où l'entité serveur est accessible par l'intermédiaire de plusieurs adresses réseau de type différent (IPv4 et IPv6), que l'entité cliente sélectionne préférentiellement les adresses IPv6 si celle-ci dispose elle-même d'une adresse IPv6 (adresse source). Ce critère de sélection vise à favoriser l'abandon progressif d'IPv4 sur Internet, mais ne tient pas compte de performances meilleures pouvant être obtenues le cas échéant par l'établissement d'une communication uniquement IPv4 avec l'entité serveur, lorsque l'entité cliente dispose d'une adresse IPv4 en plus de l'adresse IPv6. D'autre part, dans le cas où l'entité serveur est accessible par l'intermédiaire de plusieurs adresses réseau de même type (par exemple IPv4), il est alors préconisé que l'entité cliente utilise les adresses IP obtenues par résolution DNS selon l'ordre dans lequel elles figurent dans les enregistrements (RR) contenus dans la réponse DNS. Ainsi, si une première tentative de communication échoue avec une adresse IP donnée, l'entité cliente effectue une nouvelle tentative avec l'adresse IP suivante et ainsi de suite. Le nombre maximum de tentatives d'établissement de communication avec l'entité serveur est fixé par l'application cliente. On comprendra qu'avec cette dernière méthode de sélection, plus le nombre de tentatives effectives d'établissement de communication augmente et plus la qualité d'expérience utilisateur est dégradée. Le document RFC 6555 de l'IETF définit des exigences pour des algorithmes de sélection d'adresses destinés à des hôtes clients de type dual-stack, afin d'améliorer l'expérience utilisateur. En particulier, il est proposé dans ce document d'enregistrer dans une mémoire cache de l'entité cliente le résultat de chaque connexion tentée vers un serveur en utilisant l'adresse IPv4 ou l'adresse IPv6 associée au serveur. Lors d'une nouvelle tentative de connexion avec le serveur, si la dernière tentative utilisant l'une des deux adresses (IPv4 ou IPv6) s'est soldée par un échec, alors l'application cliente devra préférer l'autre adresse pour la nouvelle tentative. La méthode de sélection proposée dans le document précité permet de réduire le nombre de tentatives simultanées de connexions IPv4 ou IPv6 effectuées par un client dual- stack vers un serveur dual-stack, mais nécessite la mise à jour des applications clientes et des systèmes d'exploitation, et ne garantit pas une meilleure qualité d'expérience client une fois la connexion établie ; en effet, il se peut par exemple qu'une connexion IPv4 ou IPv6 établie rapidement peut ensuite se révéler insatisfaisante du point de vue du débit observé lors de l'échange de données entre le client et le serveur (par exemple un document multimédia téléchargé en streaming). Dans un autre exemple, un terminal Dual Stack qui sélectionne la connexion IPv6 en raison de sa rapidité, peut ensuite observer une dégradation de l'expérience utilisateur liée à l'absence de certaines fonctions du service, qui ne seraient disponibles qu'en IPv4. Ainsi, aucune des méthodes de sélection d'adresses réseau exposées ci-dessus ne semble suffisamment efficace pour garantir une bonne qualité d'expérience utilisateur. Autrement dit, les méthodes actuelles de traitement de requête DNS - pour la résolution de noms de domaine (résolution DNS) ou d'adresse réseau (résolution DNS inverse) -, dans un contexte de coexistence d'adresses IPv4 et IPv6, notamment suite à une tentative de connexion d'un terminal d'utilisateur à un serveur sur un réseau IP, souffrent de performances variables qui pénalisent la qualité d'expérience utilisateur. Exposé de l'invention La présente invention vise à améliorer la situation exposée ci-dessus en proposant selon un premier aspect, un procédé de traitement d'une requête DNS émise par un premier noeud réseau au cours d'une tentative d'accès par une application cliente à un serveur distant sur un réseau IP. Conformément à l'invention ce procédé comprend des étapes de : - réception de ladite requête DNS par un second noeud réseau ; - obtention à partir de la requête DNS d'un identifiant DNS associé à un troisième noeud réseau ; - recherche à partir de l'identifiant DNS obtenu, d'au moins un enregistrement ayant un format prédéfini et contenant des informations de connectivité réseau relatives au moins au troisième noeud réseau ; - si au moins un enregistrement a été trouvé, récupération d'au moins un enregistrement, et utilisation par le second noeud réseau des informations de connectivité contenues dans au moins un enregistrement pour notamment adapter le traitement de la requête DNS en fonction de ces informations de connectivité. L'obtention selon l'invention d'informations de connectivité réseau, au cours du traitement d'une requête DNS, permet d'améliorer significativement ce traitement en permettant notamment, selon le cas d'usage considéré, d'adapter les mécanismes réseau impliqués dans le traitement DNS, comme l'adaptation des réponses DNS ou bien la sélection du meilleur chemin réseau ou bien la traduction de paquets IP (IPv4 vers IPv4 ou IPv4 vers IPV6 et inversement), en fonction des contraintes de l'application cliente et/ou du terminal utilisateur, ou du serveur distant auquel tente d'accéder l'application cliente. Selon une caractéristique particulière de l'invention, l'étape précitée de recherche, à partir de l'identifiant DNS obtenu, d'au moins un enregistrement contenant des informations de connectivité réseau relatives au troisième noeud réseau, comprend : - l'envoi par un module client installé dans le second noeud réseau à destination d'un module serveur installé dans un quatrième noeud réseau, d'un message de requête spécifique contenant au moins l'identifiant DNS, en vue d'obtenir au moins un enregistrement relatif au troisième noeud réseau ; - la recherche par le module serveur d'enregistrements correspondant à l'identifiant DNS et l'envoi à destination du module client d'un message de réponse spécifique contenant le résultat de la recherche d'enregistrements. Une telle mise en oeuvre de l'étape de recherche d'enregistrement contenant des informations de connectivité réseau, sous forme d'un mécanisme client/serveur avec un module client et un module serveur qui peuvent être implémentés sur des entités ou noeuds réseaux distincts, permet de pouvoir adapter aisément cette implémentation en fonction des cas d'usages de traitement de requête DNS, que l'on veut optimiser. Selon un premier mode de réalisation de l'invention, le procédé est mis en oeuvre dans un environnement réseau dans lequel le premier noeud est un serveur DNS local utilisé par une application cliente, le second noeud réseau est un serveur DNS autoritaire pour le domaine associé au serveur distant, et le troisième noeud est un terminal d'utilisateur dans lequel est exécutée l'application cliente ou le serveur DNS local. Selon une première variante du premier mode de réalisation précité, le quatrième noeud réseau est un serveur DNS TLD (Top Level Domain). Selon une seconde variante du premier mode de réalisation précité, le quatrième noeud réseau est le serveur DNS local. Selon un deuxième mode de réalisation de l'invention, le procédé est mis en oeuvre dans un environnement réseau dans lequel le premier noeud est un terminal d'utilisateur, le second noeud réseau est un serveur DNS local utilisé par le terminal d'utilisateur, et le troisième noeud est le serveur distant. Selon une caractéristique de ce deuxième mode de réalisation, le quatrième noeud réseau est un serveur DNS autoritaire pour le domaine associé au serveur distant. Selon des caractéristiques d'implémentation du procédé de l'invention qui sont communes aux deux modes de réalisation : - Un message de requête selon l'invention est une structure de données organisée selon un format comprenant au moins les éléments suivants : - une entête contenant au moins un numéro de séquence ; - un corps de message contenant au moins : un champ contenant l'identifiant DNS. - Un message de réponse selon l'invention est une structure de données organisée selon un format comprenant au moins les éléments suivants : - une entête contenant au moins : un numéro de séquence, ce numéro de séquence étant identique à celui du message de requête correspondant, et un code de retour indiquant un résultat de recherche d'enregistrements ; - un corps de message contenant au moins : un champ contenant l'identifiant DNS et au moins un enregistrement, si au moins un enregistrement a été trouvé. - Un enregistrement selon l'invention correspondant à un noeud réseau considéré est une structure de données organisée selon un format comportant au moins les champs suivants : - un premier champ contenant un identifiant DNS relatif au noeud réseau ; - un second champ contenant une donnée représentative d'au moins un type de connectivité réseau disponible pour joindre le noeud réseau ; - un troisième champ contenant une donnée représentative d'une préférence d'usage d'un type de connectivité réseau parmi plusieurs types de connectivité réseau pour joindre le noeud. En pratique, selon une caractéristique de réalisation de l'invention, l'identifiant DNS associé au troisième noeud réseau est au moins un nom de domaine obtenu par le second noeud à partir d'une adresse réseau associée au troisième noeud réseau. Un tel nom de domaine peut être notamment un Nom de Domaine (DN) ou un FQDN. Corrélativement, selon un second aspect, l'invention concerne un système de traitement d'une requête DNS émise par un premier noeud réseau au cours d'une tentative d'accès par une application cliente à un serveur distant sur un réseau IP, comprenant : - des moyens de réception de ladite requête DNS par un second noeud réseau ; - des moyens d'obtention à partir de la requête DNS d'un identifiant DNS associé à un troisième noeud réseau ; - des moyens d'obtention à partir de l'identifiant DNS obtenu, d'au moins un enregistrement ayant un format prédéfini et contenant des informations de connectivité réseau relatives au moins au troisième noeud réseau ; - des moyens de traitement par le second noeud réseau des informations de connectivité contenues dans au moins un enregistrement, pour en particulier adapter le traitement de la requête DNS en fonction des informations de connectivité. En particulier, selon une caractéristique de réalisation du système selon l'invention, les moyens d'obtention d'au moins un enregistrement à partir de l'identifiant DNS, comprennent : - un module client installé dans le second noeud, configuré pour générer et envoyer à destination d'un module serveur un message de requête spécifique contenant au moins l'identifiant DNS, en vue d'obtenir au moins un enregistrement relatif au troisième noeud réseau; - le module serveur, installé dans un quatrième noeud réseau, configuré pour recevoir le message de requête puis rechercher des enregistrements correspondant à l'identifiant DNS, et envoyer à destination du module client un message de réponse spécifique contenant un résultat de la recherche d'enregistrements. Par conséquent, la présente invention a aussi pour objet un module client installé dans un noeud réseau, mis en oeuvre dans le système précité, ainsi qu'un module serveur installé dans un noeud réseau, mis en oeuvre dans un système précité, selon l'invention. En pratique, les moyens constitutifs de l'invention qui sont compris dans les différents noeuds réseau susmentionnés, et en particulier les modules client et serveur selon l'invention, tels que décrits succinctement plus haut - et dont le fonctionnement permet de mettre ne oeuvre notamment l'étape de recherche à partir d'un identifiant DNS obtenu, d'au moins un enregistrement ayant un format prédéfini et contenant des informations de connectivité réseau relatives à un noeud réseau -, sont essentiellement implémentés sous forme logicielle c'est-à-dire un ou plusieurs programmes informatiques stockés dans une ou plusieurs mémoires, de type RAM (Random Access Memory), ROM (Read Only Memory) ou de type magnétique (disque dur par exemple), et exécutés par un processeur incorporé dans le noeud réseau considéré. Par conséquent, selon un dernier aspect, la présente invention vise aussi un programme d'ordinateur mis en oeuvre dans un ou plusieurs noeuds réseau, ce programme comprenant des instructions de code dont l'exécution par un processeur informatique provoque la mise en oeuvre de tout ou partie des étapes d'un procédé de traitement d'une requête DNS, selon l'invention. Enfin, l'invention vise aussi un support d'enregistrement d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon l'invention. Un tel support d'enregistrement peut être constitué par n'importe quelle entité ou dispositif capable de stocker un tel programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement amovible tel qu'une clé USB ou un moyen d'enregistrement magnétique, tel qu'un disque dur. D'autre part, un module logiciel selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Les avantages procurés par un système de traitement d'une requête DNS, un module client ou un module serveur, ainsi qu'un programme d'ordinateur, selon l'invention, tels que brièvement exposés ci-dessus, sont identiques ou contribuent à ceux mentionnés plus haut en relation avec le procédé de traitement d'une requête DNS selon l'invention, et ne seront par conséquent pas rappelés ici. Brève description des figures D'autres caractéristiques et avantages de la présente invention ressortiront de la description détaillée qui suit, laquelle fait référence aux dessins annexés dans lesquels : - la figure 1 représente la topographie d'un environnement réseau dans lequel la présente invention est mise en oeuvre selon un premier mode de réalisation ; - la figure 2 représente un environnement réseau selon une première variante d'un premier mode de réalisation de l'invention ; - la figure 3 représente un environnement réseau selon une seconde variante du premier mode de réalisation de l'invention ; - la figure 4 est un organigramme illustrant un procédé d'obtention d'informations de connectivité réseau, selon le premier mode de réalisation de l'invention ; - les figures 5 et 6 représentent respectivement le format d'une requête et d'une réponse d'obtention d'informations de connectivité, selon une implémentation conforme au protocole DNS, applicable à la première variante du premier mode de réalisation ; - les figures 7 et 8 représentent respectivement le format d'une requête et d'une réponse d'obtention d'informations de connectivité, selon une implémentation hors protocole DNS, applicable à la première variante du premier mode de réalisation ; - les figures 9 et 10 représentent respectivement deux exemples de formats de requêtes d'obtention d'informations de connectivité, selon une implémentation conforme au protocole DNS, applicable à la seconde variante du premier mode de réalisation ; - les figures 11 et 12 représentent respectivement deux exemples de formats de réponses d'obtention d'informations de connectivité, selon une implémentation conforme au protocole DNS, applicable à la seconde variante du premier mode de réalisation ; - les figures 13 et 14 représentent respectivement deux exemples de formats de requêtes d'obtention d'informations de connectivité, selon une implémentation hors protocole DNS, applicable à la seconde variante du premier mode de réalisation ; - la figure 15 représente le format d'une réponse d'obtention d'informations de connectivité, selon une implémentation hors protocole DNS, applicable à la seconde variante du premier mode de réalisation ; - la figure 16 représente un environnement réseau selon un second mode de réalisation de l'invention ; et - la figure 17 est un organigramme illustrant un procédé d'obtention d'informations de connectivité réseau, selon le second mode de réalisation de l'invention. Description détaillée de l'invention La figure 1 représente la topographie d'un environnement réseau dans lequel la présente invention est mise en oeuvre selon un premier mode de réalisation. A la figure 1, une application cliente 11, installée sur un terminal d'utilisateur 1 doit établir une communication avec un serveur distant 18. Pour communiquer avec le serveur 18, l'application cliente 11 utilise le nom de domaine associé au serveur 18, qu'elle transmet à un module (non représenté) de résolution (resolver) de nom de domaine installé sur le terminal, lequel module de résolution est chargé d'obtenir la ou les adresse(s) IP associées au serveur 18 et que l'application cliente 11 devra utiliser pour échanger des données avec le serveur. Une fois les adresses IP associées au serveur 18 renvoyées au terminal d'utilisateur 1, un module de sélection d'adresses réseau sur le terminal 1 est chargé de déterminer l'adresse IP associée au serveur 18 que l'application cliente 11 doit utiliser pour établir une communication. On précise ici que l'on entend : - par "application cliente" (11), toute application logicielle installée sur un équipement communiquant, tel que par exemple, un navigateur web, un client FTP (File Transfer Protocol), un client de messagerie, etc. ; - par "équipement communiquant" tout dispositif informatique tel que par exemple un terminal d'utilisateur (1) tel qu'un ordinateur, un téléphone mobile, ou une tablette numérique, utilisé(e) par un utilisateur pour accéder à un service sur Internet, ou sur un réseau d'entreprise, ou un équipement intermédiaire d'un réseau ; - par "serveur distant" (18), toute entité réseau offrant un service réseau sur Internet, tel qu'un serveur web, un serveur de messagerie, un serveur de contenus multimédias (vidéo par ex.), etc. De retour à a figure 1, l'entité 12 est un équipement réseau réalisant au moins une fonction de commutation permettant l'acheminement de paquets reçus en entrée au travers de réseaux tels que l'Internet. L'équipement 12 comprend notamment un module serveur DNS 12a, responsable de la résolution des noms associés à des serveurs de destination pour le compte de terminaux utilisateurs tels que le terminal 1, et un module 12b responsable du routage du trafic réseau en provenance de ou destiné à l'application cliente 11. Selon les environnements considérés, l'entité 12 peut être confondue avec un routeur Internet dédié à un ou plusieurs utilisateurs finaux. Ce routeur Internet peut être par exemple intégré de manière classique au sein d'une passerelle résidentielle (désignée usuellement par "box" en anglais). Lors d'une tentative de connexion de l'application cliente 11 au serveur distant 18, l'application cliente 11 échange par conséquent avec le module 12a de l'équipement 12, qui joue le rôle de serveur DNS local pour le terminal 1, des blocs d'information DNS pour la résolution du nom du serveur 18 en une ou plusieurs adresses réseau. Le module 12a optimise les performances du réseau en réduisant le nombre d'échange de blocs d'information DNS échangés avec le réseau, en gérant une mémoire cache 12c dans lequel sont stockées des réponses DNS précédentes, selon une durée de validité TTL (Time To Live) prédéfinie. Le serveur de nom local 12a comprend également une base de données 12d dans laquelle sont stockés des enregistrements DNS correspondant aux terminaux des utilisateurs du réseau sur lequel est connecté le terminal utilisateur 1. Lorsque les informations (adresses réseau) relatives au serveur 18, recherchées par l'application cliente 11, ne sont pas obtenues à partir des enregistrements DNS stockés temporairement dans le cache 12c du serveur DNS local 12a, celui-ci communique avec une entité 14, serveur de noms autoritaire, pour l'obtenir. Si ce dernier ne peut fournir les informations demandées, il échange des blocs d'information DNS avec un serveur DNS racine, 13, pour les obtenir. Le dispositif de routage 12b fait alors suivre les paquets de données vers le serveur 18 en se basant sur des règles de routage, statiques ou dynamiques. En variante, le dispositif de routage 12b peut aussi utiliser des règles de translation d'adresses NAT (Network Address Translation) pour permettre le routage des paquets de données entre l'application cliente 11 et le serveur 18. Le serveur de noms autoritaire 14 comprend en particulier l'entité 14a qui est responsable du traitement des requêtes DSN, et une base de données 14c contenant les associations entre les adresses réseau de serveurs tels que le serveur 18 et leur nom de serveur ou "Fully Qualified Domain Name" (FQDN). Les adresses réseau gérées dans la base de données 14c peuvent être du type IPv4 ou IPv6 et chacune est associée au nom du serveur correspondant (FQDN). Conformément à l'invention, l'entité serveur DNS autoritaire 14a dispose également d'une mémoire cache 14c', dont la structure permet de stocker des associations entre une adresse réseau (de type IPv4 ou de type IPv6) et un FQDN. Ces associations représentent des entités tels que le serveur DNS local 12 et sont issues des échanges entre le serveur 14 et des entités telles que le serveur DNS local 12 lors d'opérations de résolution d'adresses précédentes. Le serveur DSN autoritaire 14 dispose également d'une structure de mémoire tampon (buffer) 14d, afin de stocker temporairement des adresse réseau de type IPv4 ou IPv6 et le cas échéant, des associations entre une adresse réseau et un FQDN. L'environnement réseau représenté à la figure 1, comprend aussi un équipement de routage 17 connecté au réseau dans lequel se situe le serveur 18, et destiné à acheminer des paquets de données jusqu'au serveur 18, en se basant sur des règles de routage ou des règles de traduction d'adresses (NAT). L'environnement réseau comprend également un serveur de noms TLD, 16, comprenant au moins un module (16a) serveur de noms de domaine Top Level et une base de données DNS locale (16b) destinée à la gestion des différents enregistrements DNS correspondant aux serveurs DNS tels que le serveur DNS local 12. Conformément à l'invention, l'environnement réseau représenté à la figure 1, comprend un dispositif d'obtention d'informations de connectivité réseau relatives à certains noeuds ou équipements réseau situé dans l'environnement de la figure 1. Selon les modes de réalisation envisagés, les informations obtenues peuvent concerner l'application cliente 11, le ou les terminaux 1 de l'utilisateur final, ou encore le serveur distant 18. Plus généralement, le système décrit permet à tout dispositif informatique ou équipement intermédiaire d'obtenir des informations de connectivité réseau relatives à certains noeuds ou équipements réseau. Ce dispositif d'obtention est référencé par le chiffre 15 sur les figures. Selon le mode de réalisation décrit et illustré, il comporte plusieurs modules fonctionnels distincts, répartis sur des machines différentes. Un tel dispositif d'obtention d'informations de connectivité réseau permet ainsi de fournir des informations permettant, selon le cas d'usage, à l'entité 12 ou 14, ou à des entités équivalentes dans le réseau, d'adapter des mécanismes réseau comme le traitement DNS, la sélection du meilleur chemin réseau, ou la traduction de paquets IP, aux contraintes de l'entité 1, 12 ou 18. Par exemple, l'entité 14 peut adapter sa réponse DNS décrivant l'entité serveur 18 aux contraintes de connectivité réseau IPv4 ou IPv6 de l'entité 1. Par informations réseau concernant une entité réseau considérée, obtenues par le dispositif 15, il faut comprendre des données concernant les propriétés réseau de l'entité réseau concernée. Ces données réseau sont organisées sous la forme d'un ou plusieurs enregistrements, appelés dans le cadre de la présente description "enregistrements DIP" (Distributed Identity Protocol). Un ou plusieurs enregistrements DIP peuvent représenter une même entité réseau. En pratique, selon l'implémentation décrite, le dispositif 15 d'obtention d'informations de connectivité comprend un module client et un module serveur, appelés respectivement client DIP et serveur DIP dans le cadre de la présente description. Selon un mode de réalisation donné à titre d'exemple, un tel enregistrement DIP selon l'invention comprend notamment les champs suivants : Nom de l'entité réseau : ce champ correspond au FQDN de l'entité réseau. Ce champ a une taille variable. Nom du domaine (DN) : ce champ correspond au nom du domaine (DN) de l'entité réseau lorsque celle-ci gère plusieurs autres entités réseau différentes ayant le même type de connectivité réseau. Ce champ a une taille variable. Durée de validité : ce champ correspond au Time To Live (TTL) de l'enregistrement dans le cache 15b. Sa valeur est dictée par le module serveur DIP. Ce champ est codé sur 32 bits. Classe : ce champ correspond à la classe réseau pour laquelle l'enregistrement est applicable. Par défaut, ce champ correspond à la classe Internet. Ce champ est codé sur 16 bits. Type de l'enregistrement : ce champ correspond au type de l'information stockée dans une mémoire cache du serveur DIP (15b). Par défaut, ce champ correspond au type "DIP" qui doit être enregistré auprès de l'IANA. Ce champ est codé sur 16 bits. Type de connectivité réseau : ce champ correspond aux types ou familles de connectivité réseau disponibles pour joindre l'entité réseau identifiée par le champ FQDN, ou bien pour joindre les entités réseau gérées sous le domaine identifié par le champ DN. Les caches (15b) du client DIP et (15d) du serveur DIP stockent autant d'enregistrements DIP qu'il y a de types de connectivité réseau par entité réseau. Ce champ est codé sur deux bits comme suit : a) '00' : IPv4 non partagée, b) '01' : IPv4 partagée, c) '10' : IPv6, d) '11' : Dual Stack. Préférence d'usage de type de connectivité réseau : ce champ correspond à la préférence d'usage d'un type de connectivité réseau. Il est nécessaire du fait qu'une entité réseau peut disposer de plusieurs types de connectivité réseau (IPv4, IPv4 partagée, IPv6 ou Dual Stack). Ce champ est codé sur 8 bits. Il contient une valeur décimale indiquant la préférence d'usage d'un enregistrement DIP. Priorité d'usage de type de connectivité réseau : ce champ correspond à la préférence relative d'usage d'un type donné de connectivité réseau. Il est nécessaire du fait qu'une entité réseau peut disposer de plusieurs types de connectivité réseau simultanément et de plusieurs adresses réseau de même type simultanément. Ce champ est codé sur 8 bits. Il contient une valeur décimale indiquant la priorité d'usage d'un enregistrement DIP. Poids d'usage de type de connectivité réseau : ce champ correspond au poids à donner à chaque préférence d'usage d'un type de connectivité réseau. A préférence égale, le type de connectivité auquel correspond le poids le plus important est prioritaire. Ce champ est utilisé uniquement si plusieurs enregistrements de priorité égale existent. Ce champ est codé sur au moins 8 bits. Numéro de port : ce champ correspond au numéro de port sur lequel un service est accessible, par type de connectivité réseau. Un service est identifié alors par le couple : FQDN et numéro de port. Ce champ est utilisé uniquement lorsque l'entité identifiée par le champ FQDN est un serveur. Ce champ est codé sur 16 bits. Comme indiqué précédemment, le dispositif d'obtention d'informations de connectivité selon l'invention comporte plusieurs modules fonctionnels distincts qui sont répartis sur des machines différentes. En particulier, selon l'implémentation choisie, le dispositif d'obtention d'informations de connectivité (15) peut inclure des modules instanciés sur le serveur DNS autoritaire 14 et sur le serveur DNS TLD 16, ou bien sur le serveur DNS autoritaire 14 et sur le serveur DNS Local 12. Dans les modes de réalisation exposés ci-après, le dispositif 15 d'obtention d'informations réseau, selon l'invention, comprend un module client (client DIP) 15a et un module serveur (serveur DIP) 15c. En relation avec les figures 2 et 3 on va à présent décrire un environnement réseau selon un premier mode de réalisation de l'invention, selon une première (figure 2) et une seconde variante (figure 3). Dans ce premier mode de réalisation la mise en oeuvre du procédé selon l'invention est déclenchée par la réception par le serveur DNS 14a d'un bloc d'information DNS de type requête, pour la résolution du nom du serveur 18 en une ou en plusieurs adresses réseau. Selon le premier mode de réalisation présenté, le module client DIP 15a est situé dans le serveur DNS autoritaire 14 ou à une proximité telle que la communication entre le client DIP 15a et le serveur DNS 14 puisse se faire sans perte ni latence (réseau hautement performant). Selon la première variante de ce mode de réalisation, illustrée à la figure 2, le module serveur DIP 15c est situé dans le serveur DNS TLD 16. Comme représenté à la figure 2, le module client DIP 15a gère une mémoire cache 15b dans laquelle sont stockées des informations réseau relatives notamment au serveur DNS local 12a. Cependant, le cache 15b peut aussi contenir des informations réseau sur l'application cliente 11 et concernant les terminaux (1) de l'utilisateur ou des serveurs tels que le serveur 18. Les informations réseau stockées dans le cache 15b représentent des propriétés réseau de l'entité réseau concernée. Ces données réseau sont organisées sous la forme d'un ou plusieurs enregistrements DIP comme défini plus haut. Le module client DIP 15a utilise une mémoire volatile de type mémoire tampon, 15b'. Le buffer 15b' permet de stocker temporairement un ou plusieurs enregistrements DIP. Le module client DIP gère aussi une table d'association en mémoire 15d', permettant d'associer à une requête DNS générée par le serveur DNS local 12a à une requête DIP spécifique à l'invention, permettant d'obtenir des informations réseau utiles pour le traitement de la requête DNS. L'association entre une requête DNS et une requête DIP est effectuée grâce aux numéros de séquence respectifs. On peut également prévoir que la mémoire 15d' stocke en plus des numéros de séquence, un temporisateur, un nombre de tentatives (retries) d'envoi de requêtes DIP effectuées, ainsi qu'une copie de la requête DIP générée suite à la réception d'une requête DNS. Le module serveur DIP 15c - présent dans le serveur DNS TLD 16 selon la première variante du premier mode de réalisation (figure 2) et dans le serveur DNS local 12, selon la seconde variante (figure 3) - gère une mémoire 15d dans laquelle sont stockées des informations réseau, sous la forme d'enregistrements DIP dont la structure a été exposée plus haut. Comme déjà mentionné, les informations réseau stockées peuvent concerner selon l'implémentation un ou plusieurs serveurs DNS locaux 12a ou une ou plusieurs applications cliente (11), sur des terminaux (1) d'utilisateur, ou encore sur des serveurs de ressources tels que le serveur 18. En pratique, dans la première variante , le serveur DIP 15c est confondu avec le module résolveur (16a) du serveur DNS TLD. Le serveur DIP 15c gère une base de données 15d destinée à stocker des enregistrements contenant les données réseau selon l'invention ("données DIP"). Cette base de données 15d peut être confondue avec la base de données 16b propre au serveur DNS TLS, ou bien indépendante de cette dernière. La mémoire 15d est alimentée d'informations DIP selon l'invention, lors de l'enregistrement initial de chaque serveur DNS local (12) auprès du serveur DNS TLD 16. Le Registraire (Registrar en anglais) Internet qui est responsable du serveur DNS 16, peut proposer la souscription à un service de fourniture d'enregistrements DIP selon l'invention, soit par défaut, soit sous la forme d'une option gratuite ou payante. Le "service DIP" permet ainsi aux utilisateurs finaux utilisant le serveur DNS local (12) d'obtenir une meilleure qualité d'expérience Internet, lors d'accès à des serveurs (18) offrant des services sur Internet (par exemple la fourniture de contenus). Selon la seconde variante, illustrée à la figure 3, le module serveur DIP 15c est situé dans l'entité 12. Cette dernière comprend le module 12a correspondant au serveur de nom proprement dit. Le serveur DNS local 12a comporte également une base de données 12d dans laquelle il stocke les enregistrements DNS correspondant aux terminaux (1) des utilisateurs finaux. Dans l'implémentation choisie, le module serveur DIP 15c est confondu avec le module 12a du serveur DNS local. Le serveur DIP 15c gère la base de données (mémoire) 15d dans laquelle sont stockés les enregistrements contenant les données réseau DIP selon l'invention, comme défini plus haut. La base de données 15d peut être confondue avec la base de données 12d propre au serveur DNS local 12, ou bien indépendante de cette dernière. La base de données 15d est dans tous les cas alimentée préalablement en informations réseau selon l'invention c'est-à-dire en "enregistrements DIP", ces enregistrements concernant en particulier des utilisateurs finaux considérés dans leur ensemble ou de manière individuelle. Dans ce cas, l'opérateur local peut proposer la souscription au "service DIP" selon l'invention, soit par défaut, soit sous la forme d'une option gratuite ou bien payante. L'opérateur local peut par ailleurs collecter les informations réseau selon l'invention (DIP) dans le réseau de manière automatique, ou bien les ajouter préalablement à la demande de l'utilisateur final qui a souscrit à l'option DIP afin de bénéficier d'une meilleure expérience utilisateur Internet. La figure 4 est un organigramme illustrant un procédé d'obtention d'informations de connectivité réseau, selon le premier mode de réalisation de l'invention. Le procédé commence par l'étape E60 au cours de laquelle, le serveur DNS autoritaire 14 reçoit une requête DNS de la part du serveur DNS local 12a afin d'obtenir l'adresse réseau du serveur 18. A l'étape E61, le module 14a du serveur DNS autoritaire identifie l'adresse réseau source de la requête DNS reçue à l'étape E60 et la mémorise dans la mémoire tampon 14d. A l'étape E62, le module 14a du serveur DNS autoritaire consulte sa mémoire cache 14c' pour déterminer l'identifiant FQDN du serveur DNS local 12 correspondant à l'adresse réseau, en pratique une adresse IP, identifiée à l'étape E61. Si la mémoire cache 14c' contient l'identifiant FQDN du serveur DNS local (12), alors on passe à l'étape E63, au cours de laquelle, le serveur DNS autoritaire (module 14a) lit l'identifiant FQDN du serveur DNS local 12 et met à jour la mémoire tampon 14d. Le serveur DNS autoritaire (14a) exécute alors l'étape E65. En revanche, si à l'étape E62, le cache 14c' ne contient pas l'identifiant FQDN du serveur DNS local (12), on passe à l'étape E64 au cours de laquelle le serveur DNS autoritaire (14) obtient l'identifiant FQDN du serveur DNS local (12) en effectuant une résolution inverse de l'adresse réseau du serveur DNS local. A cette fin, une interrogation est effectuée auprès du domaine Internet "in-addr.arpa", si l'adresse réseau utilisée par le serveur DNS local est de type IPv4, ou bien le domaine Internet "ipv6.arpa", si l'adresse réseau utilisée par le serveur DNS local est de type IPv6. Le serveur DNS autoritaire (module 14a) met ensuite à jour, d'une part, le cache 14c' avec l'adresse réseau du serveur DNS local 12 et l'identifiant FQDN associé, et d'autre part, la mémoire tampon (buffer 14d) avec l'association adresse réseau du serveur DNS local (12) et l'identifiant FQDN. Le serveur DNS autoritaire (14a) passe alors à l'étape E65. Cependant, dans une implémentation particulière où le module client DIP 15a n'est pas confondu avec le serveur DNS autoritaire (module 14a), le serveur DNS autoritaire passe de l'étape E64 ou E63, selon le cas, à l'étape E65' au cours de laquelle le serveur DNS autoritaire (14a) envoie au client DIP (15a), via un réseau fiable et sans latence (par exemple un réseau utilisant la transmission par fibre optique), un message contenant le numéro de séquence de la requête DNS afin de provoquer la génération d'une requête DIP, ainsi que l'identifiant FQDN du serveur DNS local (12a). On passe alors à l'étape E65. A l'étape E65, le client DIP (15a), ayant obtenu le FQDN ainsi que le nom de domaine (DN) du serveur DNS local (12), consulte sa mémoire cache 15b afin de rechercher des enregistrements DIP selon l'invention contenant des informations réseau concernant le serveur DNS local (12) ; les enregistrements DIP recherchés sont ceux contenant comme identifiant FQDN ou comme nom de domaine (DN), ceux obtenus à l'étape E63 ou à l'étape E64. Si au moins un enregistrement DIP est trouvé dans la mémoire cache 15b, on passe à l'étape E66, au cours de laquelle le module client DIP 15a obtient les enregistrements DIP trouvés par lecture et les stocke dans le buffer 15b'. On passe ensuite à l'étape E73. Toutefois, dans l'implémentation précitée selon laquelle le module client DIP 15a n'est pas confondu avec le serveur DNS autoritaire (module 14a), on passe de l'étape E66 à l'étape E71' décrite plus bas. Au contraire, si à l'étape E65 aucun enregistrement DIP correspondant au FQDN ou au nom de domaine (DN) du serveur DNS local (12) n'a été trouvé dans la mémoire cache 15b, on passe à l'étape E67 (ou E67'). A cette étape, afin d'obtenir de tels enregistrements DIP selon l'invention, le module client DIP 15a génère une ou plusieurs requêtes ("requête DIP") à destination du module serveur DIP 15c selon l'invention. L'obtention d'enregistrements DIP selon l'invention est mise en oeuvre selon deux variantes de réalisation correspondant respectivement au cas où le serveur DIP 15c est confondu avec le serveur TLD 16a (figure 2) - variante "Ml-V1" - ou au cas où le serveur DIP 15c est confondu avec le serveur DNS local 12a (figure 3) - variante "M1-V2". Les étapes E67-E70 (et E67'-E70') sont détaillées plus bas dans la description en fonction de la variante de réalisation considérée (M1-V1, M1-V2). Si le module client DIP 15a reçoit de la part du serveur DIP 15c une (ou plusieurs) réponse ("réponse DIP") suite à l'envoi d'une ou plusieurs requêtes DIP, il vérifie (étape E68) leur intégrité, conformément aux variantes de réalisation de l'étape E67 décrites plus bas. Si la réponse DIP reçue est valide, alors le module client DIP 15a passe à l'étape E69. Si à l'inverse la réponse DIP reçue n'est pas valide, alors, selon l'implémentation exposée, une variable N initialisée préalablement à une valeur positive prédéterminée, utilisée comme compteur de tentatives d'envoi de requêtes DIP à destination du serveur DIP 15c, est testée. Si la valeur de la variable N n'est pas égale à zéro, alors la variable est décrémentée de 1, puis on retourne à l'étape E67 ou E67'. En revanche si la valeur de la variable est égale à zéro, alors le module client DIP 15a positionne un code de retour du message de réponse DIP à la valeur '1' indiquant un message non cohérent. Le module client DIP 15a passe alors à l'étape E69. A l'étape E69, le module client DIP 15a traite chacune des réponses DIP reçues. A cette fin, chacun des messages de réponse DIP est traité en fonction du code de retour indiqué dans l'entête du message de réponse DIP, conformément aux variantes de réalisation décrites plus bas dans la description (variante Ml-V1 et variante Ml-V2). Quelle que soit la variante considérée, le module client DIP 15a traite chaque message de réponse DIP en fonction de son code de retour (return code, RC) comme suit : - Si RC = 0 ("Succès"), cela signifie que des enregistrements DIP contenant des informations réseau relatives à au moins le serveur DNS local 12a ont été obtenus. Le module client DIP 15a passe alors à l'étape E71 au cours de laquelle le module client DIP 15a met à jour le cache 15b avec les enregistrements DIP valides obtenus à l'étape E69, et purge également les enregistrements DIP stockés dans le cache 15b, dont la durée de vie (TTL) a expiré. Le processus se termine alors avec un code de retour égal à zéro. Le client DIP 15a passe ensuite à l'étape E73. - Si le RC # 0 ("Réponse Vide ou Incohérente"), cela signifie que le client DIP 15a n'a pas pu obtenir des informations réseau sur le serveur DNS local 12a. Le client DIP 15a passe alors à l'étape E72 au cours de laquelle aucune mise à jour de la mémoire cache 15b n'est effectuée. Le processus se termine avec un code de retour différent de zéro. On passe ensuite à l'étape E73. Dans une implémentation selon laquelle le module client DIP 15a n'est pas confondu avec le serveur DNS autoritaire 14a, mais relié à ce dernier par un réseau fiable et sans latence, par exemple un réseau utilisant la transmission par fibre optique, le client DIP 15a passe alors de l'étape E71 ou de l'étape E72, à l'étape E71'. A l'étape E71', le module client DIP 15a envoie au serveur DNS autoritaire 14a un message contenant le numéro de séquence de la requête DNS à l'origine de la génération de la requête DIP, le FQDN du serveur DNS local (12a), ainsi que le ou les enregistrements DIP obtenus. Le serveur DNS autoritaire (14a) passe ensuite à l'étape E73 au cours de laquelle il met à jour une mémoire cache avec les informations contenues dans les enregistrements DIP reçus à l'étape E71'. L'étape E73 représente la fin du procédé, selon l'invention, d'obtention d'informations réseau concernant notamment le serveur DNS local 12a et/ou le terminal d'utilisateur 1. Selon le cas d'usage considéré, ces informations réseau DIP peuvent être utilisées, soit par le serveur DNS autoritaire (14a), soit par d'autres entités réseau, à diverses fins, par exemple pour : - adapter les réponses DNS aux contraintes d'une ou plusieurs entités réseau comme le terminal utilisateur ; - activer, désactiver ou adapter divers mécanismes ou services dans le réseau du fournisseur d'accès Internet (ISP), en prenant en compte les spécificités et les contraintes des utilisateurs finaux, etc. On va à présent détailler l'obtention d'enregistrements DIP selon l'invention selon les deux variantes de réalisation précitées. La première variante, désignée dans le cadre du présent exposé par "M1-V1", correspond au cas où le serveur DIP 15c est confondu avec le serveur TLD 16a, et dont l'environnement réseau est illustré par la figure2. La seconde variante, désignée dans le cadre du présent exposé par "M1-V2", correspond au cas où le serveur DIP 15c est confondu avec le serveur DNS local 12a, et dont l'environnement réseau est illustré par la figure3. 1. Première variante du 1er mode de réalisation (M1-V1) Dans cette variante, le serveur DIP 15c est confondu avec le serveur TLD 16a comme illustré par la figure 2. On va détailler les étapes E67-E70 (E67'-E70') de la figure 4 selon cette variante (M1-V1) en envisageant deux implémentations : une implémentation s'inscrivant dans le cadre du protocole DNS (désignée par M1-V1_i1) et une implémentation hors DNS, c'est-à-dire indépendante du protocole DNS (désignée par M1-V1_i2). 1.1. Implémentation DNS (M1-V1 i1) Les figures 5 et 6 représentent respectivement le format d'une requête et d'une réponse d'obtention d'informations DIP de connectivité réseau, selon une implémentation conforme au protocole DNS, applicable à la première variante (M1-V1) du premier mode de réalisation. Dans cette implémentation, à l'étape E67 le module client 15a génère à destination du module serveur 15c une ou plusieurs requêtes DNS de type DIP dont le format est illustré par la figure 5. Des moyens de routage déterminent alors un meilleur chemin vers le serveur DIP 15c. Le client DIP 15a gère en mémoire 15d' une table permettant d'associer la requête DNS reçue du serveur DNS local (12a) à la requête DIP générée. Le client DIP 15a met à jour la table 15d'. A la réception de la requête DNS de type DIP par le module serveur DIP 15c, ce dernier, à l'étape E70, effectue d'abord une recherche dans sa base de données locale 15d afin de trouver des enregistrements DIP correspondant à l'identifiant FQDN du serveur DNS local 12a. Il génère ensuite une réponse DNS de type DIP, c'est-à-dire une réponse DNS contenant zéro, un ou plusieurs enregistrements DIP trouvés dans la base de données locale 15d, puis envoie enfin la réponse DNS DIP à destination du client DIP 15a. Des moyens de routage déterminent le meilleur chemin vers le client DIP 15a. Le format d'une réponse DNS DIP selon cette implémentation représenté à la figure 6. Ainsi, selon le format représenté, le champ RDATA contient zéro, un ou plusieurs enregistrements DIP contenant au moins les champs suivants tels que définis plus haut dans la description : - Nom du domaine (DN) de l'entité réseau ; - Type de connectivité réseau ; - Préférence d'usage du type de connectivité réseau ; - Priorité d'usage du type de connectivité réseau ; - Poids d'usage du type de connectivité réseau ; - Numéro de port. L'implémentation DNS (M1-V1_i1) requiert préalablement de réserver et d'enregistrer le type d'enregistrement DNS de type "DIP" auprès de l'IANA. Elle requiert d'autre part d'étendre le protocole DNS pour le support de la génération de requêtes DNS de type DIP, du stockage d'enregistrements DNS de type DIP, et de la génération de réponses DNS de type DIP. 1.2. Implémentation hors DNS (M1-V1_i2) Les figures 7 et 8 représentent respectivement le format d'une requête et d'une réponse d'obtention d'informations de connectivité, selon une implémentation hors protocole DNS, applicable à la première variante (M1-V1) du premier mode de réalisation. Dans cette seconde implémentation, à l'étape E67, le client DIP 15a génère à destination du serveur DIP 15c une (ou plusieurs) requête de type DIP, qui est acheminée par des moyens de routage vers le serveur DIP 15c. Cependant, à la différence de l'implémentation précédente (M1-V1_i2), la requête DIP est générée indépendamment du protocole DNS. La figure 7 représente le format d'une requête DIP hors protocole DNS, selon cette seconde implémentation. La figure 8 représente le format d'une réponse DIP hors protocole DNS, selon cette seconde implémentation. L'entête du message est commun aux messages DIP de type requête ou de type réponse. De ce fait, il contient les champs suivants: - Sequence ID (Numéro de séquence) : ce champ est codé sur 16 bits. Il est nécessaire pour l'identification d'une transaction DIP (requête/réponse). Toutes les réponses ont le même numéro de séquence que la requête correspondante. - Flags (drapeaux) : - Flag 'QR' : ce champ est codé sur 1 bit. Il indique le type du message (QR=0 si Question, QR=1 si Réponse) ; - Flag 'AA' : ce champ est codé sur 1 bit. Il indique si la réponse DIP provient d'un serveur de nom autoritaire ou non. - Flag 'TC' : Drapeau TC : ce champ est codé sur 1 bit. Il indique si la réponse DIP est tronquée ou non. - Flag 'Z' : ce champ est codé sur 1 bit. Il est réservé. - RCODE (Code de retour) : ce champ est codé sur 4 bits et il est utilisé uniquement dans une réponse DIP. Il peut contenir l'une des valeurs suivantes : - 0 : pour indiquer un succès, c'est-à-dire qu'une ou plusieurs réponses DIP ont été trouvées. - 1 : pour indiquer que le domaine est bien géré par le serveur TLD (16) mais qu'aucun enregistrement de réponse DIP, correspondant au champ DATA n'a été trouvé. - 2 : pour indiquer qu'un problème système est survenu au niveau du module serveur DIP (15c), lequel n'a pu traiter la requête DIP. - 3 : pour indiquer qu'aucun domaine correspondant au champ DATA n'a été trouvé. - 4 : pour indiquer que le message DIP est non cohérent. - 5-15: valeurs réservées. - Checksum : ce champ est codé sur 8 bits. Il est nécessaire à la gestion d'intégrité des échanges DIP. Son contenu est calculé en appliquant un algorithme de hachage sur tout le message DIP (entête (sans checksum) et corps). A la réception d'un message DIP, l'entité qui le reçoit recalcule le checksum en utilisant le même algorithme de hachage et compare le résultat au contenu du champ checksum. Si le message DIP est corrompu, il est supprimé silencieusement. Le corps d'un message de type DIP dépend du type du message DIP (requête ou réponse). Le corps d'un message DIP de type requête (figure 8) contient les champs suivants : - TYPE : ce champ est codé sur 16 bits. Il indique le type de la requête. Un seul type est défini dans cette version qui est le type DIP. - TTL : ce champ est codé sur 32 bits. Il indique le temps de validité (Time To Live) d'un message DIP. Il est utilisé pour la mise en mémoire cache les messages DIP. - DATA LENGTH : ce champ est codé sur 16 bits. Il indique la taille du champ DATA. - DATA : ce champ est de taille variable. Il indique le FQDN ou le DN du serveur DNS local (12). Une requête DIP est envoyée (figure 4, étape E67) par défaut sur un paquet UDP/IP (User Datagram Protocol/Internet Protocol), à destination du serveur DIP (15c). Le protocole UDP est utilisé afin d'éviter les problèmes de latence liés à l'établissement d'une connexion TCP. En variante, une requête DIP peut être envoyée en utilisant le protocole TCP/IP (Transmission Control Protocol/Internet Protocol), en particulier à l'étape E67' (figure 4), à destination du serveur DIP (15c). Enfin, lors de l'envoi de chaque requête DIP, le module client DIP (15a) met à jour la structure de données (table 15d') en : - insérant le numéro de séquence de la requête DNS qui est à l'origine de la génération de la requête DIP ; - déclenchant un temporisateur ; - mettant à jour la variable N dont la valeur est indicative du nombre de tentatives d'envoi à destination du dispositif 15c (serveur DIP) ; - créant une copie de la requête DIP générée, qui est stockée dans une mémoire tampon (buffer memory). La ligne correspondante de la table (15d') est purgée si l'une des conditions suivantes se réalise : - lorsque le temporisateur arrive à expiration et le nombre maximum de tentatives d'envoi à destination du serveur DIP (15c) est atteint ; - à la réception d'une réponse DIP valide (c'est-à-dire, non malformée, non dupliquée, avec un code d'erreur indiquant un succès). Ainsi en se référant à nouveau à la figure 4, une fois une requête DIP envoyée par le module client DIP 15a à destination du module serveur DIP (15c), le module client DIP passe à l'étape E68 déjà décrite. A la réception de la requête DIP, le serveur DIP (15c) vérifie l'intégrité de la requête DIP en (étape 70) en calculant le Checksum du message, par application du même algorithme de hachage que celui utilisé par le module client DIP (15a), sur l'entête et le corps de la requête DIP reçue, puis en comparant la valeur calculée à la valeur du checksum présente dans l'entête de la requête DIP reçue. Si la requête DIP est invalide alors le serveur DIP 15c la supprime "silencieusement" c'est-à-dire sans transmettre de message de réponse. En variante, le serveur DIP (15c) supprime la requête DIP invalide et génère un message DIP de type réponse vide dont le code de retour est égal à 3. Dans ce cas, la valeur du numéro de séquence est le même que celui de la requête DIP à laquelle le message de réponse correspond. Au contraire, si la requête DIP est valide alors le serveur DIP (15c) effectue une recherche dans sa base de données locale (15d) d'enregistrements DIP correspondant à l'identifiant FQDN du serveur DNS local (12a), lequel identifiant est indiqué dans le champ DATA de la requête DIP. Le serveur DIP génère ensuite une réponse DIP contenant zéro, un ou plusieurs enregistrements DIP trouvés dans la base de données locale (15d). Le format de la réponse DIP est représenté à la figure 8. Enfin, la réponse DIP est envoyée à destination du module client DIP (15a). Dans la réponse DIP transmise, le champ DATA (figure 8), inclut zéro, un ou plusieurs enregistrements DIP contenant au moins les champs suivants : - Nom du domaine (DN) de l'entité réseau concernée (défini plus haut). - Type de connectivité réseau (défini plus haut). - Préférence d'usage du type de connectivité réseau (défini plus haut). - Priorité d'usage du type de connectivité réseau (défini plus haut). - Poids d'usage du type de connectivité réseau (défini plus haut). - Numéro de port (défini plus haut). 2. Seconde variante du 1er mode de réalisation (M1-V2) Dans cette variante, le serveur DIP 15c est confondu avec le serveur DNS local 12a, comme illustré par la figure 3. On va détailler les étapes E67-E70 (E67'-E70') de la figure 4 selon cette variante (M1-V2) en envisageant deux implémentations : une implémentation s'inscrivant dans le cadre du protocole DNS (désignée par M1-V2_i1) et une implémentation hors DNS, c'est-à-dire indépendante du protocole DNS (désignée par Ml-V2_i2). 2.1. Implémentation DNS (M1-V2 il) Les figures 9 et 10 représentent respectivement deux exemples de formats de requêtes d'obtention d'informations de connectivité, selon une implémentation conforme au protocole DNS, applicable à la seconde variante du premier mode de réalisation. Les figures 11 et 12 représentent respectivement deux exemples de formats de réponses d'obtention d'informations de connectivité, selon une implémentation conforme au protocole DNS, applicable à la seconde variante du premier mode de réalisation. Dans cette implémentation, le module client DIP (15a) génère (étape E67, figure 4), à destination du module serveur DIP (15c) une ou plusieurs requête DNS de type DIP dont le format est défini ci-dessous. Selon un premier exemple, le serveur DNS local (12) sur lequel est installé le module serveur DIP (15c) gère une population d'utilisateurs finaux à connectivité réseau du même type. Dans ce cas, le module client DIP (15a) génère, à destination du module serveur DIP (15c), des messages de requête DNS DIP dont le format est représenté à la figure 9. Selon un second exemple, le serveur DNS local (12) sur lequel est installé le module serveur DIP (15c) gère une population d'utilisateurs finaux à connectivité réseau hétérogène. Dans ce cas, le module client DIP (15a) génère à destination du serveur DIP (15c) des messages de requête DNS DIP dont le format est représenté à la figure 10. A la figure 10, le champ EDNSO DATA est transporté dans la partie "Additional section" de la requête DNS conformément aux spécifications du RFC 2671 (Extension Mechanisms for DNS (EDNSO) de l'IETF. Le champ OPT RR pour le protocole 'DIP' selon l'invention contient le champ RDATA qui indique (sur 16 bits) l'identifiant (ID) de la requête DNS qui est à l'origine de la requête DNS DIP. Le module client DIP (15a) gère en mémoire (15d') une table permettant d'associer une requête DNS générée par le serveur DNS local (12a) à la requête DIP. Le (client DIP) 15a met à jour la structure 15d' (il passe alors à l'étape E68 de la figure 4). A la réception de la requête DNS de type DIP, le serveur DIP (15c) effectue (étape 70) d'abord une recherche dans sa base de données locale (15d) d'enregistrements DIP correspondant à la requête DIP reçue. Si l'on se place dans le cas du premier exemple ci-dessus, le serveur DIP (15c) recherche dans sa base de données locale (15d) des enregistrements DIP correspondant à l'identifiant FQDN du serveur DNS local (12a). Si l'on se place dans le cas du second exemple ci-dessus, le serveur DIP (15c) recherche dans sa base de données locale (15d) des enregistrements DIP correspondant à l'utilisateur final source de la requête DNS dont l'identifiant est indiqué dans le champ RDATA (sur 16 bits). Le module serveur DIP génère ensuite une réponse DNS de type DIP correspondant à la requête DIP reçue, c'est-à-dire une réponse DNS contenant zéro, un ou plusieurs enregistrements DIP trouvés dans la base de données locale (15d). Le format de la réponse DNS DIP est selon l'exemple considéré (premier ou second) conforme à la figure 11 (premier exemple) ou conforme à la figure 12 (second exemple). La réponse DNS DIP générée est alors envoyée au module client DIP (15a) via un chemin optimal déterminé par des moyens de routage. Dans les messages de réponse DIP dont le format est représenté aux figures 11 et 12, le champ RDATA, contient zéro, un ou plusieurs enregistrements DIP contenant au moins les champs suivant : - Nom du domaine (DN) de l'entité réseau concernée (défini plus haut). - Type de connectivité réseau (défini plus haut). - Préférence d'usage du type de connectivité réseau (défini plus haut). - Priorité d'usage du type de connectivité réseau (défini plus haut). - Poids d'usage du type de connectivité réseau (défini plus haut). - Numéro de port (défini plus haut). Le champ extension DNS (EDNSO) pour DIP (figure 12), contient l'identifiant (ID) de la requête DNS qui a engendré le message de requête DIP. Cet identifiant est copié à partir de la requête DIP correspondante (figure 9 ou 10). 2.2. Implémentation hors DNS (M1-V2 i2) Les figures 13 et 14 représentent respectivement deux exemples de formats de requêtes d'obtention d'informations de connectivité, selon une implémentation hors protocole DNS, applicable à la seconde variante du premier mode de réalisation. La figure 15 représente le format d'une réponse d'obtention d'informations de connectivité, selon une implémentation hors protocole DNS, applicable à la seconde variante du premier mode de réalisation. Dans cette implémentation, le module client DIP (15a) génère (étape E67, figure 4), à destination du module serveur DIP (15c) une ou plusieurs requête(s) DNS de type DIP dont le format est défini ci-après, selon les deux exemples (premier et second) exposés ci-dessus (2.1. Implémentation DNS). Selon le premier exemple, c'est-à-dire, lorsque le serveur DNS local (12) sur lequel est installé le module serveur DIP (15c) gère une population d'utilisateurs finaux à connectivité réseau du même type, le module client DIP (15a) génère, à destination du module serveur DIP (15c), des messages de requête DIP (hors DNS) dont le format est représenté à la figure 13. Selon le second exemple, c'est-à-dire lorsque le serveur DNS local (12) sur lequel est installé le module serveur DIP (15c) gère une population d'utilisateurs finaux à connectivité réseau hétérogène, le module client DIP (15a) génère à destination du serveur DIP (15c) des messages de requête DIP (hors DNS) dont le format est représenté à la figure 14. L'entête du message est commun aux messages DIP de type requête ou de type réponse. De ce fait, il contient les champs suivants: - Sequence ID (Numéro de séquence) : ce champ est codé sur 16 bits. Il est nécessaire pour l'identification d'une transaction DIP (requête/réponse). Toutes les réponses ont le même numéro de séquence que la requête correspondante. - Flags (drapeaux) : - Flag 'QR' : ce champ est codé sur 1 bit. Il indique le type du message (QR=0 si Question, QR=1 si Réponse) ; - Flag 'AA' : ce champ est codé sur 1 bit. Il indique si la réponse DIP provient d'un serveur de nom autoritaire ou non. - Flag 'TC' : Drapeau TC : ce champ est codé sur 1 bit. Il indique si la réponse DIP est tronquée ou non. - Flag 'Z' : ce champ est codé sur 1 bit. Il est réservé. - RCODE (Code de retour) : ce champ est codé sur 4 bits et il est utilisé uniquement dans une réponse DIP. Il peut contenir l'une des valeurs suivantes : - 0 : pour indiquer un succès, c'est-à-dire qu'une ou plusieurs réponses DIP ont été trouvées. - 1 : pour indiquer que le domaine est bien géré par le serveur TLD (16) mais qu'aucun enregistrement de réponse DIP, correspondant au champ DATA n'a été trouvé. - 2 : pour indiquer qu'un problème système est survenu au niveau du module serveur DIP (15c), lequel n'a pu traiter la requête DIP. - 3 : pour indiquer qu'aucun domaine correspondant au champ DATA n'a été trouvé. - 4 : pour indiquer que le message DIP est non cohérent. - 5-15: valeurs réservées. - Checksum : ce champ est codé sur 8 bits. Il est nécessaire à la gestion d'intégrité des échanges DIP. Son contenu est calculé en appliquant un algorithme de hachage sur tout le message DIP (entête (sans checksum) et corps). A la réception d'un message DIP, l'entité qui le reçoit recalcule le checksum en utilisant le même algorithme de hachage et compare le résultat au contenu du champ checksum. Si le message DIP est corrompu, il est supprimé silencieusement. Le corps d'un message de type DIP dépend du type du message DIP (requête ou réponse). Le corps d'un message DIP de type requête (figures 13 et 14) contient les champs suivants : - TYPE : ce champ est codé sur 16 bits. Il indique le type de la requête. Un seul type est défini dans cette version qui est le type DIP. - TTL : ce champ est codé sur 32 bits. Il indique le temps de validité (Time To Live) d'un message DIP. Il est utilisé pour la mise en mémoire cache les messages DIP. - DATA LENGTH : ce champ est codé sur 16 bits. Il indique la taille du champ DATA. - DATA : ce champ est de taille variable. Il indique le FQDN ou le DN du serveur DNS local (12) dans le cadre du premier exemple (figure 13), et l'identifiant (ID) de la requête DNS à l'origine de la requête DIP dans le cadre du second exemple (figure 14). Une requête DIP est envoyée (figure 4, étape E67) par défaut sur un paquet UDP/IP (User Datagram Protocol/Internet Protocol), à destination du serveur DIP (15c). Le protocole UDP est utilisé afin d'éviter les problèmes de latence liés à l'établissement d'une connexion TCP. En variante, une requête DIP peut être envoyée en utilisant le protocole TCP/IP (Transmission Control Protocol/Internet Protocol), en particulier à l'étape E67' (figure 4), à destination du serveur DIP (15c). Enfin, lors de l'envoi de chaque requête DIP, le module client DIP (15a) met à jour la structure de données (table 15d') en : - insérant le numéro de séquence de la requête DNS qui est à l'origine de la génération de la requête DIP ; - déclenchant un temporisateur ; - mettant à jour la variable N dont la valeur est indicative du nombre de tentatives d'envoi à destination du dispositif 15c (serveur DIP) ; - créant une copie de la requête DIP générée, qui est stockée dans une mémoire tampon (buffer memory). La ligne correspondante de la table (15d') est purgée si l'une des conditions suivantes se réalise : - lorsque le temporisateur arrive à expiration et le nombre maximum de tentatives d'envoi à destination du serveur DIP (15c) est atteint ; - à la réception d'une réponse DIP valide (c'est-à-dire, non malformée, non dupliquée, avec un code d'erreur indiquant un succès). Le module client DIP (15a) gère en mémoire (15d') une table permettant d'associer une requête DNS générée par le serveur DNS local (12a) à la requête DIP. Le (client DIP) 15a met à jour la structure 15d' (il passe alors à l'étape E68 de la figure 4). A la réception de la requête DIP, le serveur DIP (15c) vérifie l'intégrité de la requête DIP en (étape 70) en calculant le Checksum du message, par application du même algorithme de hachage que celui utilisé par le module client DIP (15a), sur l'entête et le corps de la requête DIP reçue, puis en comparant la valeur calculée à la valeur du checksum présente dans l'entête de la requête DIP reçue. Si la requête DIP est invalide alors le serveur DIP 15c la supprime "silencieusement" c'est-à-dire sans transmettre de message de réponse. En variante, le serveur DIP (15c) supprime la requête DIP invalide et génère un message DIP de type réponse vide dont le code de retour est égal à 3. Dans ce cas, la valeur du numéro de séquence est le même que celui de la requête DIP à laquelle le message de réponse correspond. Au contraire, si la requête DIP est valide alors le serveur DIP (15c) effectue une recherche dans sa base de données locale (15d) d'enregistrements DIP correspondant à l'identifiant FQDN du serveur DNS local (12a), lequel identifiant est indiqué dans le champ DATA de la requête DIP. Le serveur DIP génère ensuite une réponse DIP contenant zéro, un ou plusieurs enregistrements DIP trouvés dans la base de données locale (15d). Le format de la réponse DIP est représenté à la figurel5. Enfin, la réponse DIP est envoyée à destination du module client DIP (15a). Dans la réponse DIP transmise, le champ DATA (figure 15), inclut zéro, un ou plusieurs enregistrements DIP contenant au moins les champs suivants : - Nom du domaine (DN) de l'entité réseau concernée (défini plus haut). - Type de connectivité réseau (défini plus haut). - Préférence d'usage du type de connectivité réseau (défini plus haut). - Priorité d'usage du type de connectivité réseau (défini plus haut). - Poids d'usage du type de connectivité réseau (défini plus haut). - Numéro de port (défini plus haut). En relation avec les figures 16 et 17, on va à présent détailler un second mode de réalisation de l'invention, selon lequel le module client DIP (15a) est installé dans le serveur DNS local (12) voire dans le résolveur DNS (11) du terminal client (1), tandis que le module serveur DIP (15c) est installé dans le serveur DNS autoritaire (14) qui gère le serveur (18) auquel l'utilisateur souhaite accéder via son terminal (1). La figure 16 représente un environnement réseau selon ce second mode de réalisation. Sur la figure 16, le module client DIP 15c est représenté comme étant installé dans le serveur DNS local 12. Par conséquent, dans ce mode de réalisation, le serveur DNS autoritaire 14 reçoit en provenance du serveur DNS local 12, un message de requête DNS de type "DIP" selon l'invention, afin d'obtenir notamment des informations réseau sur les types de connectivité réseau d'un serveur distant tel que le serveur 18. La figure 17 est un organigramme illustrant un procédé d'obtention d'informations de connectivité réseau, selon le second mode de réalisation de l'invention. Le procédé commence par l'étape E60 au cours de laquelle, le serveur DNS local 12 reçoit une requête DNS de la part du terminal utilisateur (application 11) afin d'accéder au serveur 18. Le serveur DNS local (12a) identifie (étape E61) alors à partir de la requête DNS l'identifiant FQDN correspondant au serveur 18. Dans ce mode de réalisation, lorsque le module client DIP (15a) est confondu avec le serveur DNS local (entité 12a), le procédé se poursuit par l'étape E65. En variante, lorsque le module client DIP (15a) n'est pas confondu avec le serveur DNS local (entité 12a), mais relié à ce dernier par un réseau fiable et sans latence, par exemple un réseau utilisant la transmission par fibre optique, alors on passe à l'étape E65' au cours de laquelle le serveur DNS local (12a) envoie au client DIP (15a) un message contenant le numéro de séquence de la requête DNS afin de provoquer la génération d'une requête DIP, ainsi que l'identifiant FQDN du serveur 18. On passe alors à l'étape E65. On notera ici que dans l'environnement réseau conforme à ce second mode de réalisation, le procédé d'obtention réseau selon l'invention peut être également mis en oeuvre dans le cadre d'une résolution DNS inverse, c'est-à-dire le processus consistant à déterminer, pour une ressource réseau donnée (ici le serveur 18), un identifiant FQDN à partir d'une adresse réseau (IPv4 ou Ipv6). Dans ce cas, à l'étape E61, le serveur DNS local (12a) identifie à partir d'une requête DNS de résolution inverse, l'adresse réseau du serveur 18. De même, lorsque le module client DIP (15a) n'est pas confondu avec le serveur DNS local (entité 12a), mais relié à ce dernier par un réseau fiable et sans latence tel qu'un réseau utilisant la transmission par fibre optique, alors à l'étape E65' le serveur DNS local (12a) envoie au client DIP (15a) un message contenant le numéro de séquence de la requête DNS inverse destinée à provoquer la génération d'une requête DIP, ainsi que dans ce cas l'adresse réseau du serveur 18. A l'étape E65, le client DIP (15a), ayant obtenu le FQDN ainsi que le nom de domaine (DN) du serveur 18, consulte sa mémoire cache 15b afin de rechercher des enregistrements DIP selon l'invention contenant des informations réseau concernant le serveur 18 ; les enregistrements DIP recherchés sont ceux contenant comme identifiant FQDN ou comme nom de domaine (DN), ceux obtenus à l'étape E61. Lorsque la requête DNS d'origine est une requête de résolution inverse, les enregistrements DIP recherchés sont ceux correspondant à l'adresse réseau (IPv4 ou IPv6) du serveur 18 obtenue à l'étape E61. Si au moins un enregistrement DIP correspondant au serveur 18 est trouvé dans la mémoire cache 15b, on passe à l'étape E66, au cours de laquelle le module client DIP 15a obtient les enregistrements DIP trouvés par lecture et les stocke dans le buffer 15b'. On passe ensuite à l'étape E73. Toutefois, dans l'implémentation précitée selon laquelle module client DIP (15a) n'est pas confondu avec le serveur DNS local (entité 12a), on passe de l'étape E66 à l'étape E71' décrite plus bas. Au contraire, si à l'étape E65 aucun enregistrement DIP correspondant au FQDN ou au nom de domaine (DN) du serveur 18 (ou correspondant à l'adresse réseau de serveur 18 en cas de résolution DNS inverse) n'a été trouvé dans la mémoire cache 15b, on passe à l'étape E67. A l'étape E67, afin d'obtenir de tels enregistrements DIP selon l'invention, le module client DIP 15a génère une ou plusieurs requêtes ("requête DIP") à destination du module serveur DIP 15c selon l'invention. Le processus d'obtention d'enregistrements DIP selon ce second mode de réalisation peut être mis en oeuvre selon deux variantes de réalisation, qui sont identiques à celles décrites plus haut dans le cadre du premier mode de réalisation (première variante "Ml -V1") : implémentation DNS (M1-V1_i1) et implémentation hors DNS (M1-V1_i2), en relation avec respectivement les figures 5 et 6, et les figures 7 et 8. Ces deux variantes ne sont donc pas reproduites dans cette partie de la description. A noter que dans le cas où l'on considère une résolution DNS inverse, le champ FQDN de l'entête de la requête DIP (figure 5, implémentation DNS) et le champ DATA du corps de la requête DIP (figure 7, implémentation hors DNS) contient l'adresse réseau (adresse IP) du serveur 18. De retour à la figure 17, à l'étape E68, si le module client DIP 15a reçoit de la part du serveur DIP 15c une (ou plusieurs) réponse ("réponse DIP") suite à l'envoi d'une ou plusieurs requêtes DIP, il vérifie leur intégrité, conformément aux variantes de réalisation de l'étape E67 décrites plus bas. Si la réponse DIP reçue est valide, alors le module client DIP 15a passe à l'étape E69. Si à l'inverse la réponse DIP reçue n'est pas valide, alors, selon l'implémentation exposée, une variable N initialisée préalablement à une valeur positive prédéterminée, utilisée comme compteur de tentatives d'envoi de requêtes DIP à destination du serveur DIP 15c, est testée. Si la valeur de la variable N n'est pas égale à zéro, alors la variable est décrémentée de 1, puis on retourne à l'étape E67 ou E67'. En revanche si la valeur de la variable est égale à zéro, alors le module client DIP 15a affecte à un code de retour du message de réponse DIP la valeur '4' indiquant un message non cohérent. Le module client DIP 15a passe alors à l'étape E69. A l'étape E69, le module client DIP 15a traite chacune des réponses DIP reçues. A cette fin, chacun des messages de réponse DIP est traité en fonction du code de retour indiqué dans l'entête du message de réponse DIP. Le module client DIP 15a traite chaque message de réponse DIP en fonction de son code de retour (return code, RC) comme suit : - Si RC = 0 ("Succès"), cela signifie que des enregistrements DIP contenant des informations réseau relatives à au moins le serveur 18 ont été obtenus. Le module client DIP 15a passe alors à l'étape E71, cours de laquelle le module client DIP 15a met à jour la mémoire cache 15b avec les enregistrements DIP valides obtenus (étape E69). Le processus se termine avec un code de retour égal à zéro. On passe ensuite à l'étape E73. - Si le RC # 0 ("Réponse Vide ou Incohérente"), cela signifie que le client DIP 15a n'a pas pu obtenir des informations réseau sur le serveur 18. Le client DIP 15a passe alors à l'étape E72 au cours de laquelle aucune mise à jour de la mémoire cache 15b n'est effectuée. Le processus se termine avec un code de retour différent de zéro. On passe ensuite à l'étape E73. Dans une implémentation selon laquelle le module client DIP 15a n'est pas confondu avec l'entité 12a du serveur DNS local, mais à proximité réseau de ce dernier, de sorte que l'on puisse considérer que ces deux entités sont reliées par un réseau fiable et sans latence (par exemple un réseau utilisant la transmission par fibre optique), le client DIP 15a passe alors de l'étape E71 ou de l'étape E72, à l'étape E71'. A l'étape E71', le module client DIP 15a envoie au serveur DNS local (12a) un message contenant le numéro de séquence de la requête DNS à l'origine de la génération de la requête DIP, le FQDN du serveur 18 (ou son adresse réseau, s'il s'agit de résolution DNS inverse), ainsi que le ou les enregistrements DIP obtenus. Le serveur DNS local (12a) passe ensuite à l'étape E73 au cours de laquelle il met à jour le cas échéant une mémoire cache avec les informations contenues dans les enregistrements DIP reçus à l'étape E71'. L'étape E73 représente la fin du procédé, selon l'invention, d'obtention d'informations réseau concernant, dans ce mode de réalisation, notamment le serveur distant 18 auquel le terminal d'utilisateur (1) tente d'accéder. Selon le cas d'usage considéré, ces informations réseau DIP peuvent être utilisées, soit par le serveur DNS local (12a), soit par d'autres entités réseau, à diverses fins, par exemple pour : - adapter les réponses DNS aux contraintes d'une ou plusieurs entités réseau telles qu'un serveur de contenus (serveur 18) distant ; - activer, désactiver ou adapter divers mécanismes ou services dans le réseau du fournisseur d'accès Internet (ISP), comme la translation d'adresse, en prenant en compte les spécificités et les contraintes d'entités serveurs (serveur 18) sur le réseau, etc.15 REVENDICATIONS1. Procédé de traitement d'une requête DNS émise par un premier noeud réseau (12 ; 1) au cours d'une tentative d'accès par une application cliente (11) à un serveur distant (18) sur un réseau IP, comprenant des étapes de : - réception (E60) de ladite requête DNS par un second noeud réseau (14 ; 12) ; - obtention (E61-E64) à partir de la requête DNS d'un identifiant DNS associé à un troisième noeud réseau (1,12 ; 18) ; - recherche (E65, E67-E70) à partir de l'identifiant DNS obtenu, d'au moins un enregistrement ayant un format prédéfini et contenant des informations de connectivité réseau relatives au moins audit troisième noeud réseau (1,12; 18) ; - si au moins un enregistrement a été trouvé, récupération (E68, E69, E71) d'au moins un enregistrement, et utilisation (E73) par le second noeud réseau (14 ; 12) des informations de connectivité contenues dans ledit au moins un enregistrement pour au moins adapter le traitement de ladite requête DNS en fonction desdites informations de connectivité. 2. Procédé selon la revendication 1, dans lequel l'étape de recherche à partir de l'identifiant DNS obtenu, d'au moins un enregistrement contenant des informations de connectivité réseau relatives au troisième noeud réseau, comprend : - l'envoi par un module client (15a) installé dans le second noeud réseau (14;12) à destination d'un module serveur (15c) installé dans un quatrième noeud réseau (16 ; 14), d'un message de requête spécifique contenant au moins ledit identifiant DNS, en vue d'obtenir au moins un enregistrement relatif au troisième noeud réseau (1,12 ; 18) ; - la recherche par ledit module serveur (15c) d'enregistrements correspondant audit identifiant DNS et l'envoi à destination du module client d'un message de réponse spécifique contenant le résultat de la recherche d'enregistrements. 3. Procédé selon la revendication 2, dans lequel ledit premier noeud est un serveur DNS local (12) utilisé par une application cliente (11), le second noeud réseau est un serveur DNS autoritaire (14) pour le domaine associé au serveur distant (18), et le troisième noeud est un terminal d'utilisateur (1) dans lequel est exécutée l'application cliente (11) ou le serveur DNS local (12). 4. Procédé selon la revendication 2 combinée avec la revendication 3, dans lequel ledit quatrième noeud réseau est un serveur DNS TLD (16). 5. Procédé selon la revendication 2 combinée avec la revendication 3, dans lequel ledit quatrième noeud réseau est le serveur DNS local (12). 6. Procédé selon la revendication 2, dans lequel ledit premier noeud est un terminal d'utilisateur (1), le second noeud réseau est un serveur DNS local (12) utilisé par le terminal d'utilisateur (1), et le troisième noeud est le serveur distant (18). 7. Procédé selon la revendication 6, dans lequel ledit quatrième noeud réseau est un serveur DNS autoritaire (14) pour le domaine associé au serveur distant (18). 10 8. Procédé selon l'une quelconque des revendications 2 à 7, dans lequel ledit message de requête est une structure de données organisée selon un format comprenant au moins les éléments suivants : - une entête contenant au moins un numéro de séquence ; 15 - un corps de message contenant au moins : un champ (DATA) contenant ledit identifiant DNS. 9. Procédé selon la revendication 8, dans lequel ledit message de réponse est une structure de données organisée selon un format comprenant au moins les éléments suivants : 20 - une entête contenant au moins : un numéro de séquence, ce numéro de séquence étant identique à celui du message de requête correspondant, et un code de retour indiquant un résultat de recherche d'enregistrements ; - un corps de message contenant au moins : un champ (RDATA) contenant ledit identifiant DNS et au moins un enregistrement, si au moins un enregistrement a été trouvé. 25 10. Procédé selon l'une quelconque des revendications 1 à 9, dans lequel un enregistrement correspondant à un noeud réseau est une structure de données organisée selon un format comportant au moins les champs suivants : - un premier champ contenant un identifiant DNS relatif audit noeud réseau ; 30 - un second champ contenant une donnée représentative d'au moins un type de connectivité réseau disponible pour joindre ledit noeud réseau ; - un troisième champ contenant une donnée représentative d'une préférence d'usage d'un type de connectivité réseau parmi plusieurs types de connectivité réseau pour joindre ledit noeud. 35 11. Procédé selon l'une quelconque des revendications 1 à 10, dans lequel ledit identifiant DNS associé au troisième noeud réseau est au moins un nom de domaine obtenu par le second noeud (14) à partir d'une adresse réseau associée au troisième noeud réseau (1,12; 18). 12. Système de traitement d'une requête DNS émise par un premier noeud réseau (12 ; 1) au cours d'une tentative d'accès par une application cliente (11) à un serveur distant (18) sur un réseau IP, comprenant : - des moyens de réception de ladite requête DNS par un second noeud réseau (14 ; 12) ; - des moyens d'obtention à partir de la requête DNS d'un identifiant DNS associé à un troisième noeud réseau (1,12 ; 18) ; - des moyens d'obtention à partir de l'identifiant DNS obtenu, d'au moins un enregistrement ayant un format prédéfini et contenant des informations de connectivité réseau relatives au moins audit troisième noeud réseau (1,12; 18) ; - des moyens de traitement par le second noeud réseau (14 ; 12) des informations de connectivité contenues dans au moins un enregistrement, pour au moins adapter le traitement de ladite requête DNS en fonction desdites informations de connectivité. 13. Système selon la revendication 12, dans lequel lesdits moyens d'obtention d'au moins un enregistrement à partir de l'identifiant DNS, comprennent : - un module client (15a) installé dans le second noeud (14;12), configuré pour générer et envoyer à destination d'un module serveur (15c) un message de requête spécifique contenant au moins ledit identifiant DNS, en vue d'obtenir au moins un enregistrement relatif au troisième noeud réseau (1,12 ; 18) ; - ledit module serveur (15c) installé dans un quatrième noeud réseau (16 ; 14), configuré pour recevoir ledit message de requête puis rechercher des enregistrements correspondant audit identifiant DNS, et envoyer à destination du module client un message de réponse spécifique contenant un résultat de la recherche d'enregistrements. 14. Module client (15a) installé dans un noeud réseau, mis en oeuvre dans un système selon l'une des revendications 12 ou 13. 15. Module serveur (15c) installé dans un noeud réseau, mis en oeuvre dans un système selon l'une des revendications 12 ou 13. 16. Programme d'ordinateur mis en oeuvre dans un noeud réseau, ledit programme comprenant des instructions de code dont l'exécution par un processeur du noeud réseau provoque la mise en oeuvre d'au moins l'étape de recherche à partir d'un identifiant DNS obtenu, d'au moins un enregistrement ayant un format prédéfini et contenant des informations de connectivité réseau relatives à un noeud réseau, selon un procédé de traitement d'une requête DNS conforme à l'une quelconque des revendications 1 à 11.