Brevet FR3023098A1 — publié le 20160101

Domaine technique L'invention a trait de manière générale au domaine des communications de type client-serveur dans un réseau de communication basé sur le protocole IP (Internet Protocol). Elle concerne en particulier un procédé et un système de traitement d'une demande de résolution d'un nom d'un serveur, émise par une application cliente installée sur un terminal client, sur un réseau de communication. 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 du protocole IP. Une adresse réseau du type IPv4 est codée sur quatre octets (32 bits). 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, afin de faciliter aux utilisateurs la recherche de ressources informatiques sur l'Internet 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 Domain), 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 ("."). 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é". Les adresses IPv6 étant plus complexes que les adresses IPv4, le système DNS a été enrichi par des extensions "DNS Extensions to support IP version 6" qui sont décrites dans les documents RFC 1886 et 3596. Ces documents RFC décrivent le support de l'enregistrement de type AAAA (correspondant à une adresse IPv6) ainsi que les modifications nécessaires à apporter aux enregistrements DNS pour le support de l'IPv6 (tels que les enregistrements MX, etc.). Par conséquent, dans le contexte de la transition d'IPv4 vers IPv6 qui vise au remplacement progressif du protocole IPv4 par IPv6 sur Internet, 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. Deux approches sont alors possibles pour permettre une communication entre un équipement réseau ne disposant que d'adresses IPv6 et un équipement réseau ne disposant que d'adresses IPv4 : la "double pile" (dual-stack) et la "traduction de protocoles". 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. Concernant la traduction de protocoles, le mécanisme NAT64 (Network Address Translation 64), décrit par les spécifications RFC (Request For Comments) 6146 et 6052 publiés par l'IETF (Internet Engineering Task Force), permet à un équipement client IPv6 de joindre un équipement serveur IPv4. La traduction de protocoles par NAT64 (Network Address Translation 64) s'appuie sur l'utilisation du système DNS ou bien de son extension DNS64 décrite dans le document RFC 6147. Grâce au système de nommage DNS, un équipement serveur IPv4 peut être représenté par une adresse IPv6, même si le service fourni par cet équipement n'est pas compatible IPv6. L'adresse IPv6 affectée à l'équipement serveur IPv4 a pour rôle d'acheminer le trafic IPv6 d'un équipement client IPv6 vers une passerelle de traduction de protocoles NAT64. Cette dernière se charge de la traduction du trafic IPv6 de l'équipement client en trafic IPv4 compréhensible par l'équipement serveur IPv4. L'adresse IPv6 qui sert à identifier l'équipement serveur IPv4 dans le système de nommage peut être gérée statiquement par le système DNS, ou bien elle est créée ou synthétisée dynamiquement par le système DNS64. La traduction de protocoles est très utile aux fournisseurs de contenus ainsi qu'aux fournisseurs de solutions d'informatique en nuage (cloud computing), car elle permet à un service IPv4 d'être joignable par des équipements clients IPv6, même si l'infrastructure de service elle-même n'est pas compatible IPv6. Cependant, cette approche présente des limites. En effet, étant donné que les systèmes d'exploitation sont configurés généralement pour privilégier l'IPv6, un équipement client "double pile" préfèrera l'adresse IPv6 d'un équipement serveur IPv4, si ce dernier est représenté dans le système de nommage par les deux types d'adresses (IPv4 et IPv6). Il en résultera qu'un client "double pile" génèrera un trafic essentiellement IPv6 qui sera acheminé vers une passerelle de traduction protocolaire, alors même qu'un chemin IPv4 natif, c'est-à-dire ne nécessitant pas de traduction protocolaire, existe. Cela résulte, d'une part, en une possible dégradation de service pour le client "double pile". En effet, la traduction protocolaire offre un service "au mieux" (best effort) qui s'accompagne d'une perte d'informations, liées en particulier à la qualité de service (QoS). D'autre part, cela implique une charge de trafic supplémentaire sur la passerelle de traduction protocolaire, ce qui accroit les coûts et investissements pour le fournisseur de service ou l'opérateur. Ainsi, dans le contexte actuel de transition IPv4 et IPv6, la résolution d'un nom de domaine demandée par une application cliente pour atteindre un serveur distant peut aboutir à l'obtention par celle-ci de plusieurs adresses, 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 de domaine, 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). Exposé de l'invention La présente invention vise à améliorer notamment la situation exposée ci-dessus en proposant selon un premier aspect un procédé de traitement d'une demande de résolution d'un nom d'un serveur, émise par une application cliente installée sur un terminal client, sur un réseau de communication. Conformément à l'invention, ce procédé comprend des étapes de : a) - obtention par une première entité réseau d'un ensemble de messages DNS suite à la demande de résolution ; b) - obtention par la première entité réseau d'informations de connectivité réseau relatives au moins au terminal client ou au serveur, et génération d'un code, dit de marquage, représentatif des informations de connectivité réseau précitées ; c) - traitement par la première entité réseau de l'ensemble de messages DNS en fonction du code de marquage, et envoi en conséquence d'un ensemble de messages DNS, dits marqués, à une seconde entité réseau ; d) - traitement par la seconde entité réseau dudit ensemble de messages DNS marqués, afin de délivrer à l'application cliente au moins une réponse DNS adaptée en fonction desdites informations de connectivité réseau. L'obtention par la première entité réseau d'informations de connectivité réseau relatives au moins au terminal client ou au serveur distant auquel le terminal client tente d'accéder, permet d'agir, via le code de marquage susmentionné, soit sur les requêtes DNS (générées par exemple par un module résolveur du terminal après réception de la demande de résolution), soit directement sur les réponses DNS générées par le traitement des requêtes DNS précitées (par exemple par un serveur DNS autoritaire), de manière à ce que les réponses DNS effectivement reçues par l'application cliente du terminal soient adaptées, selon l'implémentation, aux contraintes de connectivité IP du terminal client, au trafic IP échangé entre l'application cliente et le serveur, ainsi qu'aux contraintes de connectivité du serveur distant. Selon un premier mode de réalisation de l'invention, à l'étape a) susmentionnée l'ensemble de messages DNS est un ensemble de requêtes DNS générées suite à la réception par un module de résolution DNS de la demande de résolution de nom ; et à l'étape b), les informations de connectivité réseau incluent au moins une information de type et de préférence d'usage d'interface IP active pour ledit terminal client. Selon ce mode de réalisation, ce sont les requêtes DNS qui subissent un traitement spécifique pour provoquer l'obtention de réponses DNS adaptées notamment aux contraintes réseau du terminal client, qui sont définies par au moins une information de type et de préférence d'usage d'interface IP active pour le terminal client. Selon une première variante de réalisation du premier mode de réalisation, l'étape c) de traitement de l'ensemble de requêtes DNS inclut l'insertion du code de marquage dans chaque requête de l'ensemble de requêtes DNS, à l'intérieur d'un champ déterminé du corps de la requête, formant ainsi un ensemble de requêtes marquées. En pratique selon une caractéristique de réalisation, ce champ est un champ RDATA du corps de la requête conformément à l'extension EDNSO du protocole DNS. Dans cette variante de réalisation, l'étape de traitement d) comprend la lecture du code de marquage contenu dans chaque requête de l'ensemble de requêtes marquées, puis la recherche d'enregistrements DNS conformes aux informations de connectivité obtenues à partir du code de marquage. Si au moins un tel enregistrement est trouvé, au moins une réponse DNS est générée, cette réponse contenant l'enregistrement. Cette (au moins une) réponse DNS ensuite envoyée à destination de l'application cliente. Ainsi, grâce au marquage des requêtes DNS selon les contraintes de connectivité réseau du terminal client, les réponses DNS sont par exemple sélectionnées en fonction de leur adéquation avec les contraintes réseau du terminal client. Selon une deuxième variante de réalisation du premier mode de réalisation, l'étape c) de traitement inclut le filtrage de l'ensemble de requêtes DNS en fonction du code de marquage. Selon cette variante, aucune information n'est insérée dans le corps des requêtes DNS, les requêtes DNS subissent seulement un filtrage, par exemple celles correspondant à une interface IP associée à un degré de préférence d'usage faible sont supprimées avant envoi à la seconde entité réseau, afin d'obtenir des réponses DNS conformes aux préférences d'usage d'interface IP du terminal client. Selon diverses implémentations de ce premier mode de réalisation, la première entité réseau est située dans le terminal client ou dans un serveur DNS, local vis-à-vis de l'application cliente, et ladite seconde entité réseau est située dans un serveur DNS autoritaire pour le domaine associé au serveur. Selon un second mode de réalisation de l'invention, à l'étape a) l'ensemble de messages DNS est un ensemble de réponses DNS générées par la première entité réseau, suite à la réception d'un ensemble de requêtes DNS générées par un module de résolution DNS suite à la réception de la demande de résolution de nom ; et, à l'étape b), les informations de connectivité réseau sont caractéristiques d'un type d'adresse IP identifiant le serveur, contenue dans chaque réponse DNS de l'ensemble de réponses. Selon ce second mode de réalisation, l'étape c) de traitement, par la première entité réseau de chaque réponse DNS, comprend l'insertion du code de marquage à l'intérieur d'un champ déterminé du corps de la réponse, formant ainsi un ensemble de réponses marquées, puis l'envoi de l'ensemble de réponses DNS marquées à la seconde entité réseau. Dans ce second mode de réalisation, ce sont ainsi seulement les réponses DNS qui subissent un marquage selon l'invention de manière à contenir des informations de connectivité réseau relatives au serveur distant, et une fois ces réponses DNS transmises au terminal client, l'application cliente pourra avantageusement confronter ces informations de connectivité liées au serveur distant avec ses propres contraintes de connectivité, afin de choisir au moins une adresse IP contenue dans une réponse DNS, pour communiquer avec le serveur distant dans des conditions optimales en termes de qualité de service et de performances réseau. En pratique, dans ce mode de réalisation, le champ précité est un champ RDATA du corps de la réponse conformément à l'extension EDNSO du protocole DNS. Selon une caractéristique de réalisation de ce mode de réalisation, l'étape de traitement d) effectué par la seconde entité réseau comprend : - l'obtention d'informations indicatives de préférence de connectivité réseau pour le terminal client ; - la comparaison du code de marquage contenu dans chaque réponse de l'ensemble de réponses marquées avec les informations indicatives de préférence de connectivité réseau pour le terminal client, puis la sélection des réponses DNS satisfaisant aux informations indicatives de préférence de connectivité réseau pour le terminal client. Selon diverses implémentations de ce second mode de réalisation, la première entité réseau est située dans un serveur DNS autoritaire pour le domaine associé au serveur, et la seconde entité réseau est située dans le terminal client, par exemple dans l'application cliente, ou dans un serveur DNS, local vis-à-vis de l'application cliente. Selon un deuxième aspect, l'invention concerne un système de traitement d'une demande de résolution d'un nom d'un serveur, émise par une application cliente installée sur un terminal client, sur un réseau de communication, ce système comprenant : - au moins une première entité réseau comportant : - un module d'obtention d'un ensemble de messages DNS suite à la demande de résolution ; - un module d'obtention d'informations de connectivité réseau relatives au moins audit terminal client ou au serveur, et de génération d'un code, dit de marquage, représentatif de ces informations de connectivité réseau ; et - un module de traitement de l'ensemble de messages DNS en fonction du code de marquage, afin d'obtenir un ensemble de messages DNS, dit marqués ; - au moins une seconde entité réseau comportant : - un module de réception dudit ensemble de messages DNS marqués, en provenance de cette au moins une première entité réseau ; et - un module de traitement de l'ensemble de messages DNS marqués, afin de délivrer à l'application cliente au moins une réponse DNS adaptée en fonction des informations de connectivité réseau. Selon un troisième aspect, l'invention concerne une première entité réseau telle que définie ci-dessus, mise en oeuvre dans un système de traitement d'une demande de résolution d'un nom d'un serveur, selon l'invention. Selon un quatrième aspect, l'invention concerne une seconde entité réseau telle que définie ci-dessus, mise en oeuvre dans un système de traitement d'une demande de résolution d'un nom d'un serveur, selon l'invention. En pratique, les moyens constitutifs de l'invention qui sont compris dans les différentes entités (appelés également noeuds) réseau susmentionnées, et en particulier les modules mis en oeuvre dans une "première" ou une seconde "entité" selon l'invention, telles que décrits succinctement plus haut, 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 l'entité réseau considérée. Par conséquent, selon un cinquième aspect, la présente invention vise aussi un programme d'ordinateur mis en oeuvre par une entité réseau sur un réseau de communication, ce programme comprenant des instructions de code pour la mise en oeuvre des étapes a), b), c) et/ou d) d'un procédé de traitement d'une demande de résolution d'un nom d'un serveur, tel que défini plus haut, lorsque ce programme est exécuté par un processeur équipant l'entité réseau considérée. 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 l'utilisation d'un système de traitement d'une demande de résolution d'un nom d'un serveur, d'une première ou d'une seconde entité réseau module client, ainsi que d'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 de traitement d'une demande de résolution d'un nom d'un serveur, 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; - 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é de traitement d'une requête d'accès à un serveur distant selon le premier mode de réalisation de l'invention ; - les figures 5 et 6 représentent respectivement le format d'une requête DNS standard et le format d'une requête DNS marquée, conformément au protocole DNS, applicables au premier mode de réalisation de l'invention; - la figure 7 représente un environnement réseau selon une première variante d'un deuxième mode de réalisation de l'invention ; - la figure 8 représente un environnement réseau selon une seconde variante du deuxième mode de réalisation de l'invention ; - la figure 9 est un organigramme illustrant un procédé de traitement d'une requête d'accès à un serveur distant selon le deuxième mode de réalisation ; et - la figure 10 représente le format d'une réponse DNS, applicable au deuxième mode de réalisation de l'invention. Description détaillée de l'invention On donne ci-après des explications supplémentaires concernant le système DNS décrit notamment dans les spécifications RFC 1034 et 1035 de l'IETF. Comme mentionné précédemment, 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 Domain), 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 ("."). 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 l'Internet, 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 de domaine 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 de domaine, 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 de domaine (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 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. La figure 1 représente un environnement réseau dans lequel la présente invention peut être mise en oeuvre. Dans cet environnement, 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 FQDN associé au serveur 18, qu'elle transmet à un module lla de résolution (resolver) de nom de domaine installé sur le terminal. Le module de résolution 11a est chargé d'obtenir au moins une adresse IP associée au serveur 18, que l'application cliente 11 devra utiliser pour échanger des données avec le serveur. Une fois la ou les adresses IP du serveur 18 envoyées au terminal d'utilisateur 1, le module de résolution 11a met en mémoire cache 11c les adresses IP obtenues avant de les envoyer à l'application 11, qui les utilisera dans l'ordre de leur réception, afin de communiquer avec le serveur 18. 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é 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 exemple), etc. A la figure 1, l'entité 12 représente un équipement réseau réalisant au moins une fonction de commutation permettant l'acheminement de paquets reçus en entrée via un réseau tel 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é à une 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 communique d'abord localement avec le module de résolution 11a afin d'obtenir les adresses IP du serveur distant 18. A cette fin, une mémoire cache 11c est d'abord consultée. La mémoire cache 11c enregistre temporairement, en effet, des réponses DNS obtenues précédemment, selon une durée de validité TTL (rime To Live) prédéfinie, permettant ainsi d'optimiser les performances réseau. Si l'information recherchée (adresses réseau) ne figure pas dans la mémoire cache 11c, le module de résolution 11a génère des blocs d'information DNS pour déclencher la résolution du nom du serveur 18 afin d'obtenir une ou plusieurs adresses réseau. Les blocs d'information DNS pour la résolution du nom du serveur 18 sont envoyés à destination du module serveur DNS 12a de l'équipement 12 qui joue par conséquent dans cet exemple, le rôle de serveur DNS local pour le terminal client 1. Le module DNS local 12a dispose également pour optimiser les performances réseau d'une mémoire cache 12c dans lequel sont stockées des réponses DNS précédentes, émises par des serveurs distants tels le serveur 18, selon une durée de validité (TTL) prédéfinie. Ainsi, lorsque les informations (adresses réseau) relatives au serveur 18, demandé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 un serveur de noms autoritaire 14, pour les obtenir. Après avoir obtenu les adresses réseau du serveur de noms autoritaire, le dispositif de routage 12b fait alors suivre les paquets de données correspondants 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 traduction 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 un module serveur DNS standard 14a, responsable du traitement des requêtes DNS, et une base de données 14c contenant des 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). Par ailleurs, le serveur DNS autoritaire 14 peut comporter en outre un module serveur DNS64 14a'. Le fonctionnement du module serveur DNS64 (autoritaire) 14a' est décrit dans le document RFC 6147. Le module DNS64 14a' a pour fonction de générer dynamiquement une adresse IPv6 représentant un serveur IPv4 18, à partir de l'adresse IPv4 de celui-ci, ainsi qu'au moins un Préfix IPv6 identifiant une passerelle NAT64 dans le réseau Internet. La configuration DNS64 est gérée par un module base de données 14c'. Dans le cadre de la présente description : - on désigne par "adresse IP native" une adresse IP correspondant à une interface IP active sur une entité serveur IP (par exemple l'entité 18). Cette adresse peut être IPv4 ou IPv6 ; - on désigne par "adresse IP fictive", une adresse IP représentant le serveur IP 18, mais ne correspondant pas à une interface IP active sur le serveur IP 18. Dans un contexte NAT64, cette adresse est une adresse IPv6 représentant un serveur IPv4, via une passerelle NAT64. Le fonctionnement du serveur DNS64 autoritaire 14a' est le suivant. A la réception d'un bloc d'information de type requête DNS IPv6, le module serveur DNS autoritaire standard (14a) est d'abord interrogé pour obtenir le ou les enregistrements DNS correspondant au serveur 18. Si aucun enregistrement DNS n'est obtenu (IPv4 ou IPv6), ou bien si au moins un enregistrement DNS IPv6, contenant une adresse IPv6 native, est obtenu, alors le serveur DNS64 autoritaire envoie la réponse DNS obtenue au module 12a. Si au moins un enregistrement DNS IPv4 est obtenu, mais qu'aucun enregistrement DNS IPv6 n'est obtenu (correspondant à au moins une adresse IPv6 "native"), alors : au moins une adresse IPv6 "fictive", représentant le serveur 18, est synthétisée à partir de l'adresse IPv4 obtenue de celui-ci, ainsi que du Préfix IPv6 de la passerelle NAT64 ; un bloc d'information DNS de type réponse DNS IPv6, contenant au moins l'enregistrement DNS IPv6 synthétisé, est généré et est transmis au module serveur DNS local 12a. Les enregistrements DNS IPv4 sont aussi envoyés au module 12a par le serveur DNS dans un bloc d'information DNS de type réponse DNS IPv4. Comme mentionné plus haut, l'environnement réseau représenté à la figure 1, comprend un équipement de routage 19 connecté au réseau dans lequel se situe le serveur 18, via l'équipement de routage 17. Les équipements de routage 17 et 19 sont destinés à acheminer des paquets de données jusqu'au serveur 18, en se basant sur des règles de routage ou de traduction d'adresses standard (NAT IPv4), ou sur des règles de traduction d'adresses conformes au standard NAT64 (décrit dans le document RFC 6146) qui vise à traduire des paquets IPv6 en provenance d'un client IPv6 en paquets IPv4 compréhensibles par un serveur IPv4. La passerelle NAT64 est représentée à la figure 1 soit par une entité routeur 19, située dans le réseau de l'opérateur de l'entité serveur 18, soit par un module de traduction 17b d'un équipement de routage 17, dont le rôle est de traduire tout paquet IPv6 reçu à destination de serveur 18, en un paquet IPv4 compréhensible par l'entité serveur IPv4 18, et inversement. L'environnement réseau comprend également un serveur de noms proxy 13 de l'environnement du terminal client, et un serveur de noms proxy 16 de l'environnement du serveur DNS autoritaire 14. Les serveurs de noms (DNS) proxy 13 et 16, comprennent respectivement au moins un module (13a, 16a) capable d'intercepter et de traiter des blocs d'information DNS. Conformément à l'invention, l'environnement réseau représenté à la figure 1 comprend par ailleurs un module 15 configuré pour obtenir et adapter des blocs d'informations DNS aux contraintes réseau relatives aux échanges client-serveur dans cet environnement. Selon l'invention, le dispositif 15 d'obtention de blocs d'informations DNS adaptées aux contraintes du réseau de l'application cliente 11 et du serveur 18, comporte en particulier deux modules fonctionnels distincts : un module de marquage de blocs d'informations DNS et un module de traitement de blocs d'informations DNS. Les modules précités peuvent être répartis selon les modes de réalisation choisis sur des machines différentes, ce qui est illustré sur la figure 1, par trait pointillé englobant plusieurs modules d'entités distinctes (1, 12, 13, 14, 16). ler mode de réalisation On va à présent décrire un premier mode de réalisation de l'invention. Les figures 2 et 3 représentent respectivement un environnement réseau selon une première variante et une seconde variante de ce premier mode de réalisation. Selon ce premier mode de réalisation de l'invention, le dispositif de traitement d'une requête d'accès à un serveur distant (18) par une application cliente (11), comprend un module de marquage de requêtes DNS (15a) et un module de traitement de réponses DNS (15b). Selon ce premier mode de réalisation, le module de marquage (15a) est situé dans le réseau de l'entité cliente, c'est-à-dire soit dans le terminal utilisateur 1 (figure 2), soit dans le serveur DNS local 12 ou dans l'entité serveur proxy DNS local 13a (figure 3), et le module de traitement (15b) est situé dans le serveur DNS autoritaire 14 ou dans le serveur de noms proxy 16 associé. Selon ce premier mode de réalisation de l'invention, la mise en oeuvre du procédé est déclenchée par la réception par une entité cliente DNS (11a, 12a ou 13), d'une requête pour la résolution du nom du serveur 18, cette requête étant initiée par l'application cliente 11 dans le terminal client 1. Dans ce premier mode de réalisation, Afin de réduire le délai du marquage d'un bloc d'information DNS de type requête par la fonction de marquage fournie par le module de marquage (15a), une opération préalable de création d'informations de marquage est effectuée par le module de marquage (15a). Cette opération de création d'informations de marquage consiste à créer pour chaque interface IP active du terminal 1 un enregistrement dont le format est décrit plus-bas. Ces informations utiles pour la fonction de marquage sont stockées dans une mémoire cache 15c, dont le contenu est géré au niveau du terminal client 1 ou dans le serveur DNS local 12 (selon la variante considérée du premier mode de réalisation). La mémoire cache 15c est structurée par un ou par plusieurs enregistrements décrivant au moins une interface IP active du terminal 1 et comportant chacun les champs suivants : un type, un identifiant, un état, une préférence d'usage du type de l'interface, ainsi qu'une durée de validité (Time to Live (TTL)). Les champs précités sont détaillés ci-après. Type de l'interface IP : ce champ correspond au type de la pile IP de l'interface IP. Il est codé sur deux bits. La valeur '10' indique une pile IPv4, la valeur '01' indique une pile IPv6 et la valeur '11' indique une "double pile" (dual stack). Identifiant de l'interface IP : ce champ correspond à l'identifiant réseau de l'interface IP. Il contient un identifiant de l'interface réseau associé comme par exemple son adresse IP (IPv4 ou IPv6). Etat fonctionnel de l'interface IP : ce champ indique si l'interface est fonctionnelle ou non. Il est codé sur 1 seul bit. La valeur '0' indique que l'interface IP est fonctionnelle. La valeur '1' indique que l'interface IP est non fonctionnelle - par exemple, en raison d'un problème physique ou logiciel sur le réseau auquel l'interface réseau est rattachée (3G, Ethernet, etc.) tel qu'une panne concernant la passerelle par défaut ou concernant le lien entre le terminal et la passerelle par défaut, etc. Préférence d'usage de l'interface IP : ce champ indique la préférence d'usage de l'interface. La valeur d'une préférence d'usage '0' indique que l'utilisateur du terminal client ne souhaite pas utiliser cette interface, momentanément. Ce champ est codé sur 8 bits. Durée de validité : ce champ correspond à la durée de vie ou Time to Live (TTL) de l'enregistrement dans le cache (15c). Par défaut, la valeur de ce champ est la même pour tous les enregistrements contenus dans le cache. L'utilisateur peut néanmoins modifier la valeur du TTL d'un enregistrement donné, par exemple, en le mettant à '0' pour forcer ainsi la mise à jour de l'ensemble du cache. A titre d'exemple, on considère un terminal disposant d'une seule interface réseau, et ayant obtenu d'un opérateur d'accès Internet deux adresses IP : une du type IPv4 publique et une autre de type IPv6 globale. A un instant donné, les enregistrements stockés dans le cache 15c pourront être : : interface de type IPv4 fonctionnelle et que le terminal client 1 utilise. Cet enregistrement est valable pour une durée d'encore 5 secondes. et : interface de type IPv6, non fonctionnelle (par exemple en raison de problème sur la passerelle par défaut), et que l'administrateur du terminal client ne souhaite pas utiliser momentanément. Cet enregistrement est valable pour encore 5 secondes. La mémoire cache (15c) du module de marquage (15a) est alimentée par une fonction de collecte de l'état fonctionnel de chaque interface IP du terminal client (1), notée : Collect IP Interface Status ( ip interface). Selon l'invention, cette fonction effectue, à intervalles de temps réguliers, des tests visant à vérifier l'état fonctionnel de chaque interface IP du terminal client (1), et met à jour le contenu de la mémoire cache (15c) en indiquant l'état fonctionnel de chaque interface réseau du terminal client. En pratique, la fonction précitée vérifie d'abord si une interface IP est active, puis vérifie ensuite si le réseau sous-jacent est fonctionnel. En effet, pour un terminal client, il suffit par exemple que la passerelle par défaut d'une interface IP soit en panne, pour que celle-ci devienne inutile, alors même que l'interface IP du terminal est active. La figure 4 est un organigramme illustrant un procédé de résolution d'un nom de serveur selon le premier mode de réalisation de l'invention, selon la première variante (étapes E40-E46) et selon la seconde variante (étapes spécifiques E41a-E46a, les autres étapes étant similaires). Première variante du 1' mode de réalisation (M1-V1) En liaison avec la figure 4, on va d'abord décrire un procédé de traitement de résolution d'un nom de serveur selon la première variante mentionnée plus haut, illustrée par la figure 2, et selon laquelle le module de marquage des blocs d'informations DNS (15a) est situé dans le module résolveur 11a du terminal client 1. A l'étape E40, le module résolveur 11a incluant le module de marquage 15a, reçoit une demande de résolution du nom du serveur 18 en adresses réseau, par exemple via une requête connue de type Get Host by Name O. En réponse à cette requête, le module 11a consulte d'abord son cache local 11c. Si aucune réponse DNS correspondant à la requête reçue n'est trouvée dans le cache 11c, alors le module résolveur 11a génère des blocs d'information DNS de type requête pour la résolution du nom du serveur 18. On notera ici qu'un module résolveur d'un système d'exploitation (OS) récent génère habituellement un bloc d'information DNS de type requête DNS IPv4 pour obtenir une ou plusieurs adresses IPv4 associées au serveur 18, et un bloc d'information DNS de type requête DNS IPv6, pour obtenir une ou plusieurs adresses IPv6 pour le serveur 18. A l'étape E41, chaque bloc d'information DNS de type requête généré est transféré au le module 15a de marquage de blocs d'informations DNS. A l'étape E42, le module de marquage des blocs d'informations DNS (15a) consulte son cache 15c afin d'obtenir des informations valides (dont le TTL est différent de zéro), indiquant le type de chaque interface IP fonctionnelle sur le terminal client 1. Pour cela, selon l'invention, la fonction suivante est utilisée : Get IP Interface Status O. Si la fonction Get IP Interface Status () détermine que le cache 15c contient au moins un enregistrement dont la durée de vie (TTL) est égale à zéro, alors à l'étape E44, la mise à jour du cache 15c est forcée par l'exécution de la fonction Collect IP Interface Status( ip interface), provoquant la mise à jour du cache 15c avec indication de l'état fonctionnel de chaque interface réseau du terminal client 1. Dans le cas contraire (aucun enregistrement n'a une durée de vie égale à zéro), on passe à l'étape E43. A cette étape, une fonction notée : Generate DNS Marking (cache) est exécutée afin d'obtenir un résumé de l'information valide obtenue du cache 15c et de générer à partir de ce résumé un code qui va servir pour le marquage des requêtes DNS L'exécution de la fonction Generate DNS Marking précitée provoque d'abord la sélection du type et de la préférence d'usage de chaque enregistrement représentant une interface IP fonctionnelle (dont la valeur du champ "Etat fonctionnel de l'interface IP" est à 0, voir plus haut). Puis, les redondances entre ces enregistrements sont éliminées et pour chaque ensemble d'enregistrements fonctionnels du cache 15c, un seul code de marquage est généré. Chaque code contient au plus trois couples d'information : un premier décrivant l'état des interfaces IPv4, un deuxième décrivant l'état des interfaces IPv6 et un troisième décrivant l'état des interfaces "double pile". La valeur du code généré par la fonction Generate DNS Marking est codée sur 32 bits. A titre d'exemple, si le cache 15c du module de marquage contient les enregistrements suivants : - - - Alors, la fonction Generate DNS Marking génèrera le code suivant : ( , ) Le code ci-dessus indiquera au module (15b) de traitement des requêtes DNS marquées, qu'il faut renvoyer prioritairement un bloc d'information de type réponse DNS IPv4, la valeur '2' (associée à l'adresse IPv4) dans le code indiquant une plus grande préférence. Dans le cas particulier d'une valeur de préférence égale entre plusieurs adresses, par exemple, pour un code généré ( , ), le module de traitement enverra des blocs d'information de type réponse DNS IPv4 et IPv6. Enfin, si le code de marquage est ( ), alors le module de traitement retournera uniquement des réponses IPv6. Toujours à la figure 4, à l'étape E45, le module de marquage (15a) active une fonction de marquage de requête DNS, notée Apply Marking (DNS Request, Code) utilisant le code de marquage obtenu à l'étape précédente (E43), afin de marquer chaque bloc d'information DNS de type requête. A cet effet cela, la fonction Apply Marking utilise les extensions DNS EDNSO (Extension Mechanisms for DNS (EDNSO) - RFC 2671), pour inscrire le code dans la requête DNS, comme illustré par la figure 6. Les figures 5 et 6 représentent respectivement le format d'une requête DNS standard et le format d'une requête DNS marquée, conformément au protocole DNS, applicables au premier mode de réalisation de l'invention; Selon une implémentation particulière (notée var10), le module 15a n'effectue aucun filtrage des requêtes DNS qui ont une moindre préséance (precedence en anglais). L'avantage de cette approche est une meilleure fiabilité du service. En effet, les requêtes DNS IPv4 et IPv6 n'étant pas envoyées dans les mêmes paquets IP, si l'interface fonctionnelle préférée subit une quelconque dégradation, par exemple suite à la mobilité de l'utilisateur, ou bien si le bloc d'information de type requête DNS dont la préséance est la plus grande, est perdue dans le réseau, alors que le bloc d'information de type requête DNS de moindre préséance arrive à destination, cela n'empêchera pas la communication de s'établir via une interface IP fonctionnelle moins préférée, tout en évitant un quelconque délai de résolution DNS supplémentaire. Selon une autre implémentation (notée var11) alternative avec la précédente, à l'étape E45, la fonction _Apply_Marking (DNS Request, Code) exécutée par le module 15a utilise le code de marquage obtenu à l'étape E43 pour filtrer c'est-à-dire supprimer les blocs d'information DNS de type requête qui ont un niveau de préséance le plus faible. Par exemple, si un terminal client 1 est "double pile" mais est configuré pour "préférer" communiquer avec des serveurs (18) en utilisant la pile IPv4, alors la fonction _Apply_Marking filtrera les requêtes DNS IPv6. Dans un autre exemple, un terminal client 1 peut être configuré pour "préférer" utiliser l'IPv6 pour communiquer avec un serveur « double pile », sans pour autant accepter de passer par des passerelles du type NAT64. Dans ce cas, si par exemple le serveur 18 se trouve être joignable en IPv4 natif, et en IPv6 via NAT64, alors, en supprimant les requêtes DNS IPv4, l'implémentation var11 privilégiera un chemin non natif par rapport au chemin IPv4 natif. Dans ce cas d'usage particulier, l'implémentation selon la variante var10 permettra d'obtenir une communication de meilleure qualité. A l'étape E46, le module de marquage des blocs d'informations DNS (15a), confondue, dans l'exemple de réalisation exposé ici, avec l'entité 11a génère en fonction du code de marquage le ou les blocs d'information DNS de type requête et les envoie à destination de l'entité serveur DNS local 12a. Selon une variante d'implémentation selon laquelle le module de marquage 15a n'est pas confondu avec le module résolveur 11a, le module 15a intercepte d'abord les requêtes DNS générées par le module résolveur 11a, puis effectue un marquage de chaque requête DNS et fournit chaque bloc d'information DNS marqué directement au système d'exploitation (OS) du terminal client 1. La requête DNS est ensuite envoyée par l'OS du terminal client vers l'entité serveur DNS local 12 (module 12a). Par ailleurs, selon une implémentation particulière, le module serveur DNS local 12a envoie le ou les blocs d'information DNS reçus de type requête, marqués, sans les modifier, à destination de l'entité serveur DNS autoritaire 14, sans filtrage des requêtes de moindre préséance. Selon une autre implémentation possible, si le module 11a a utilisé le code de marquage pour supprimer les requêtes DNS de moindre préséance, alors le module serveur DNS local (12a) achemine à destination de l'entité serveur DNS autoritaire 14, un ou plusieurs blocs d'information DNS de type requête, standard(s), c'est-à-dire n'incluant pas d'extension EDNSO. Selon une autre implémentation possible de cette première variante du premier mode de réalisation de l'invention, le module serveur DNS local 12a consulte le marquage des blocs d'information DNS de type requête pour la résolution d'un même serveur 18, supprime les requêtes de moindre préséance et envoie à l'entité serveur DNS autoritaire 14, un ou plusieurs blocs d'information DNS standards de type requête, c'est-à-dire n'incluant pas d'extension EDNSO. L'envoi des blocs d'information DNS de type requête à destination de l'entité serveur DNS autoritaire 14 est illustré par l'étape E47 détaillée plus bas dans la description. Seconde variante du 1 er mode de réalisation (M1-V2) Toujours en liaison avec la figure 4, on va décrire les étapes, notées E41a-E46a, spécifiques à la seconde variante mentionnée plus haut, illustrée par la figure 3, et selon laquelle le module de marquage des blocs d'informations DNS (15a) est situé soit dans l'entité serveur DNS local 12 (module résolveur 12a) ou dans l'entité serveur proxy DNS local 13, de la partie réseau de l'entité cliente. Comme exposé plus haut, à l'étape E40, suite à la réception d'une demande de résolution du nom du serveur 18, le module résolveur 11a du terminal 1 consulte d'abord son cache local 11c. Si aucune réponse DNS correspondant à la requête reçue n'est trouvée dans le cache local, alors le module résolveur 11a génère des blocs d'information DNS de type requête pour la résolution du nom du serveur 18 en une ou en plusieurs adresses réseau. A l'étape E41a, le module 11a achemine chaque bloc d'information DNS de type requête généré à l'étape précédente, à destination de l'entité DNS local 12 (module 12a). Comme déjà mentionné, dans cette variante le module de marquage des blocs d'informations DNS (15a) est situé comme illustré par la figure 3, soit dans le module serveur DNS local 12a, soit dans le module proxy DNS local 13a. Une structure en mémoire15d, est gérée par le module de marquage 15a. Cette structure en mémoire correspondant soit à la mémoire référencée 12d lorsque le module de marquage est situé dans le serveur DNS local 12, soit à la mémoire référencée 13c lorsque le module de marquage 15a est situé dans le serveur proxy DNS local 13. Cette mémoire, 12d ou 13c selon le cas, contient notamment pour chaque terminal client (1) des enregistrements, définissant pour chaque terminal client (1), la liste de ses interfaces IP, la pile ou type des interfaces IP actives et fonctionnelles (IPv4 ou IPv6), la préférence d'usage par type d'interface, ainsi qu'une valeur de durée de validité (TTL). A l'étape E42a, le module de marquage des blocs d'informations DNS (15a) associe d'abord la requête au terminal client qui l'a généré, par exemple, en utilisant l'adresse mac ou ip source du paquet transportant la requête DNS. Ensuite, le module 15a exécute un certain nombre de fonctions pour obtenir les préférences IP du terminal en question. Tout d'abord, le module 15a consulte la mémoire cache (12d ou 13c) afin d'obtenir des informations valides indiquant le type de chaque interface IP fonctionnelle pour le terminal client 1 considéré. A cette fin, une fonction Get IP Interface Status (id terminal) est exécutée. Suite à l'exécution de la fonction précitée : si le terminal n'est pas identifié par au moins un enregistrement dans la structure en mémoire 12d ou 13c, ou bien, si le terminal est identifié par au moins un enregistrement dans la structure en mémoire 12d ou 13c, mais qu'il existe au moins un enregistrement dont le TTL est égal à 0 dans la structure en mémoire alors une mise à jour du cache est déclenchée, à l'étape E44a, par l'intermédiaire d'une fonction Collect IP Interface Status( id client). L'exécution de cette fonction provoque la mise à jour de la mémoire cache (12d ou 13c), avec indication des interfaces du terminal client, ainsi que des préférences d'usage de la ou des interface(s) réseau fonctionnelles du terminal client 1 (identifié par le paramètre '_id client). Dans le cas contraire (aucun enregistrement n'a une durée de vie égale à zéro), on passe à l'étape E43a au cours de laquelle le module client 15a obtient des informations de préférence d'usage de la ou des interface(s) IP fonctionnelles du terminal client 1. Selon une première implémentation, une fonction cliente exécutée dans le module 15a interroge une fonction serveur exécutée dans le terminal client 1, selon une relation client- serveur. Plus précisément, il s'agit pour la fonction cliente de la fonction Collect IP Interface Status( id client), et pour la fonction serveur, de chaque terminal, de la fonction Generate DNS Marking O. La fonction cliente Collect IP Interface Status utilise un identifiant id client pour interroger le terminal en question et obtenir ses préférences IP grâce à la fonction locale Generate DNS Marking O. L'identifiant du client id client est soit l'adresse IP soit l'adresse physique d'une interface d'un terminal ayant généré au moins une requête DNS à destination du serveur DNS local 12. Comme exposé plus haut en relation avec la première variante (M1-V1), le code de marquage obtenu par la fonction cliente suite à l'interrogation d'un terminal client contient au plus trois couples d'information : un premier décrivant l'état des interfaces IPv4, un deuxième décrivant l'état des interfaces IPv6 et un troisième décrivant l'état des interfaces "double pile". Dans le cas particulier, où le module de marquage 15a est situé dans l'entité proxy DNS 13, le module 15a utilise une fonction d'interception des blocs d'information de type requête DNS pour obtenir pour chaque requête DNS l'identifiant du client à l'origine de cette requête DNS. Selon une seconde implémentation applicable, par exemple, à un contexte de clients résidentiels, la structure en mémoire (12d ou 13c) peut être alimentée manuellement par un utilisateur du terminal client 1 via une interface web fournie par un routeur-serveur DNS local 12. Ce routeur 12 étant alors confondu avec une passerelle résidentielle (désignée également box en anglais). Une fois le cache 12d ou 13c mis à jour, le module 15a passe ensuite à l'étape E43a. Dans le cas contraire (si le terminal est identifié avec des enregistrements valides, c.-à- d. dont la durée de vie est différente de zéro), on passe à l'étape E43a au cours de laquelle le module client 15a obtient des informations de préférence d'usage de la ou des interface(s) IP fonctionnelles du terminal client 1. Le module 15a passe ensuite à l'étape E45a. A l'étape E45a, selon une implémentation particulière, le module de marquage 15a applique à un bloc d'information DNS de type requête, une extension DNS EDNSO comme illustré à la figure 6. Selon une autre implémentation possible, le module de marquage 15a utilise le code de marquage obtenu à l'étape précédente (E44a) pour filtrer c'est-à-dire éliminer les blocs d'information DNS de type requête qui ont la priorité la plus faible. A l'étape E46a, le module 15a de marquage des blocs d'informations DNS transmet chaque bloc d'information DNS de type requête (marqué ou standard, selon l'implémentation), au module serveur DNS local 12a. Les étapes suivantes E47-E50 représentées à la figure 4, sont applicables aux deux variantes de réalisation décrites ci-dessus (M1-V1, Ml-V2). A l'étape E47, chaque bloc d'information DNS de type requête, généré à l'étape précédente (E46, E46a), est transmis à destination de l'entité serveur DNS autoritaire 14. Dans le mode de réalisation choisi et présenté, le serveur DNS autoritaire 14 comporte soit un module serveur DNS autoritaire standard 14a, soit un module serveur DNS autoritaire 14a enrichi d'un module serveur DNS64 autoritaire 14a'. Selon une première implémentation (notée IM1), le module 15b de traitement des blocs d'informations DNS (15b) selon l'invention est situé dans l'entité serveur DNS autoritaire 14, sur laquelle est instanciée un module serveur autoritaire DNS 14a et un module serveur autoritaire DNS64 14a' (voir figures 2 et 3). Toujours à l'étape E47, le module de traitement 15b active une fonction Read Code (DNS Request) afin d'obtenir à partir des extensions EDNSO de chaque bloc DNS de type requête reçu, les informations de préférence relatives au terminal client 1 (type d'interfaces IP fonctionnelles, préférences du terminal). A l'étape E48, lorsque le module 15b de traitement des blocs d'informations DNS est confondu avec le module serveur autoritaire DNS64 14a', il active une fonction Apply DNS Code (DNS Request, Code), afin d'obtenir des blocs d'information de type réponse DNS, adaptés au code de marquage obtenu de l'étape précédente (E47). Pour cela, le module de traitement 15b consulte une base de données DNS 14c ainsi que celle (14c') associée au l'entité 14a' afin d'obtenir un ou plusieurs enregistrements DNS adaptés aux contraintes du terminal client 1 via une fonction notée : Search DNS Code (DNS Request, Code) Si aucun enregistrement DNS satisfaisant au code de marquage ('Code'), n'est obtenu, et si les préférences associées au terminal client 1 permettent à ce dernier d'utiliser une ou plusieurs adresse(s) IP Fictive(s) (c'est-à-dire non native(s)), alors le module de traitement 15b en synthétise au moins une. Selon ce premier mode de réalisation de l'invention, la particularité de la fonction précitée est qu'elle est configurée pour privilégier toujours des enregistrements portant l'identité native de l'entité serveur 18, lorsque celle-ci correspond aux préférences et besoins du terminal client 1. Ainsi, selon une premier exemple, si le code de marquage obtenu est ( , ), la fonction Search DNS Code (DNS Request, Code) est configurée pour en déduire que le terminal client 1 est "double pile", mais qu'il "préfère" obtenir une réponse DNS de type IPv4, et ne retient par conséquent que l'enregistrement DNS IPv4. Dans ce cas, même si le serveur 18 est nativement "double pile" ou bien si celui-ci est accessible via une passerelle NAT64, seules ses adresses IPv4 natives seront envoyées au terminal client 1 incorporées dans un ou plusieurs blocs d'information de type réponse DNS IPv4. Selon un second exemple, si le code correspond à l'enregistrement : ( , ), la fonction Search DNS Code (DNS Request, Code) est configurée pour en déduire que le terminal client 1 dispose d'une "double pile", et qu'il "souhaite" obtenir des réponses DNS de type IPv4 et des réponses DNS de type IPv6. Ainsi, si le serveur 18 est IPv4 mais qu'il est représenté en plus par une ou plusieurs adresses IPv6 fictives dans la base de donnée DNS ou via DNS64, alors seules les adresses natives IPv4 seront envoyées au terminal client 1 "double pile", via un ou plusieurs blocs d'information de type réponse DNS I Pv4. Selon un troisième exemple, si le code correspond à l'enregistrement : ( , ), la fonction Search DNS Code (DNS Request, Code) est configurée pour en déduire que le terminal client 1 dispose d'une "double pile", et qu'il "souhaite" obtenir des réponses DNS de type IPv4 et des réponses DNS de type IPv6, avec une préférence pour les adresses IPv6 natives. Ainsi, si le serveur 18 est IPv4 mais qu'il est représenté en plus par une ou plusieurs adresses IPv6 fictives dans la base de donnée DNS ou via DNS64, alors seules les adresses natives IPv4 seront envoyées au terminal client 1 "double pile", via un ou plusieurs blocs d'information de type réponse DNS IPv4, préférant ainsi les chemins natifs à la traversée de passerelles NAT (NAT64 dans cet exemple). Selon un quatrième exemple, si le code obtenu correspond à l'enregistrement suivant : ( ), la fonction Search DNS Code (DNS Request, Code) est configurée pour en déduire que le terminal client 1 a uniquement une pile IPv6 fonctionnelle et qu'il est possible de lui envoyer un bloc d'information DNS de type réponse avec des adresses IPv6 fictives. Dans ce cas, si le serveur 18 est IPv4 mais qu'il est représenté par une ou plusieurs adresses IPv6 fictives dans la base de donnée DNS (14c) ou via DNS64, alors, ces adresses IPv6 seront envoyées au terminal client 1, via un ou plusieurs blocs d'information de type réponse DNS IPv6. Selon une deuxième implémentation (notée IM2), le module 15b de traitement des blocs d'informations DNS n'est pas situé sur l'entité serveur DNS autoritaire 14 mais sur une entité serveur proxy DNS 16 localisée en amont de l'entité 14. Dans ce cas, à l'étape E48, le module 15b (confondu avec le module 16a sur la figure 3) intercepte chaque bloc d'information DNS de type requête, puis active une fonction Read Code (DNS Request), afin d'obtenir à partir des extensions EDNSO des blocs d'information DNS de type requête, les informations de préférence du terminal client 1 correspondant à la requête DNS (type d'interfaces IP fonctionnelles, préférences du terminal client). Le module 15b active ensuite la fonction Apply DNS Code (DNS Request, Code), afin d'obtenir au moins un bloc d'information de type requête DNS, adapté au code de marquage obtenu. Pour cela, le module de traitement 15b active la fonction Search DNS Code (DNS Request, Code) afin d'obtenir au moins un enregistrement DNS adapté aux contraintes du terminal client 1. Cette fonction est configurée pour opérer comme suit, en fonction du code obtenu : Si le terminal client 1 est de type IPv6, alors le module de traitement 15b envoie le ou les blocs d'information de type requête DNS, au serveur DNS64 autoritaire (14a'). Il autorise ainsi, en cas de besoin, la synthèse d'adresses IPv6 fictives pour établir une communication entre le terminal client 1 et le serveur 18. Si le terminal client 1 est de type "double pile" ou IPv4, alors le module de traitement 15b transmet la ou les requêtes DNS directement au serveur DNS autoritaire (14a) et non pas au serveur DNS64 autoritaire. Ainsi, il n'autorise pas la synthèse d'adresses IPv6 fictives et préfère de ce fait pour les terminaux double pile les chemins natifs à la traduction. L'avantage de cette seconde implémentation (IM2) est que le module de traitement 15b est simple à implémenter car il n'agit que sur les requêtes DNS et non sur des réponses DNS. Par conséquent, il ne requiert pas de structure en mémoire complexe pour associer des couples (requêtes DNS, code) avec des réponses DNS. Selon cette implémentation, il est possible d'interroger directement le serveur DNS autoritaire (14a), sans consulter le serveur DNS64 autoritaire (14a'). A l'étape E49, le serveur autoritaire 14 génère un ou plusieurs blocs d'information DNS de type réponse et les transmet au serveur DNS local 12 (module 12a). Enfin, à l'étape E50, le module DNS local 12a reçoit le ou les blocs d'information DNS de type réponse DNS. Il les stocke en mémoire 12c avant de les transmettre au module résolveur 11a du terminal client 1. Ce dernier les stocke en mémoire 11c avant de les transmettre à l'application cliente 11. Les réponses DNS obtenues par l'application 11 sont adaptées aux contraintes du terminal client 1. 2ème Mode de réalisation On va à présent décrire un second mode de réalisation de l'invention selon deux variantes de réalisation (notées M2-V1 et M2-V2). Les figures 7 et 8 représentent respectivement un environnement réseau selon la première variante et un environnement réseau selon la seconde variante, de ce second mode de réalisation. La figure 9 est un organigramme illustrant un procédé de résolution d'un nom de serveur selon le deuxième mode de réalisation, applicable aux deux variantes précitées. Enfin, la figure 10 représente le format d'une réponse DNS, applicable à ce deuxième mode de réalisation. Selon ce second mode de réalisation de l'invention, le système de traitement d'une demande de résolution d'un nom d'un serveur par une application cliente, comprend un module (15a) de marquage de réponses DNS (blocs d'informations DNS de type réponse) et un module (15b) de traitement des réponses DNS marquées. Pour les deux variantes considérées, le module 15a de marquage est localisé dans le serveur DNS autoritaire 14. Selon les variantes considérées, le module 15b de traitement des réponses marquées est localisé soit dans le résolveur 11a (voir figure 7), soit dans un le serveur DNS local 12a ou bien dans un serveur DNS proxy 13 situé en amont du serveur DNS 12a (voir figure 8). Selon le deuxième mode de réalisation, la mise en oeuvre du procédé selon l'invention est déclenchée par la réception par une entité serveur DNS (14a, 14a'), d'une requête pour la résolution d'un nom du serveur (18) en une ou en plusieurs adresses réseau. Cette requête est initiée par le serveur DNS local 12 (module 12a), pour le compte d'une application cliente 11, ayant émise une requête d'accès à destination de ce serveur (18). A la figure 9, le processus de traitement d'une demande de résolution DNS selon l'invention débute par l'étape E90 au cours de laquelle le serveur DNS autoritaire 14 reçoit une demande de résolution du nom du serveur 18, sous la forme de blocs d'information DNS de type requête DNS IPv4 et/ou IPv6. Selon une première configuration, l'entité serveur 14 contient un serveur DNS autoritaire14a, et selon une autre configuration, l'entité serveur 14 comporte en plus du serveur DNS autoritaire 14a, un module serveur DNS64 standard 14a'. Les étapes suivantes E91-E97 représentées à la figure 9, sont applicables aux deux variantes de réalisation décrites ci-dessus (M2-V1, M2-V2). A l'étape E91, en réponse aux requêtes DNS reçues, l'entité serveur 14 tente d'obtenir des réponses DNS. Selon la première configuration, l'entité 14 contient un serveur DNS autoritaire standard 14a. Celui-ci consulte sa base de données 14c à la recherche d'enregistrements DNS IPv4 ou IPv6 correspondant au serveur 18. Selon une deuxième configuration, l'entité 14 contient en plus du serveur DNS autoritaire standard 14a, un serveur DNS64 autoritaire 14a'. Celui-ci traite les requêtes DNS comme suit : Pour chaque requête DNS IPv4 reçue, la requête DNS IPv4 est traitée par le serveur DNS standard 14a. Pour chaque requête DNS IPv6 reçue, le serveur DNS64 14a' consulte le serveur DNS 14a, lequel consulte sa base de données 14c à la recherche d'enregistrement DNS représentant le serveur 18. Si au moins un enregistrement DNS est obtenu, alors, selon le cas, le serveur DNS64 14a' génèrera: o Une réponse DNS6 IPv6 contenant au moins un enregistrement DNS IPv6 incluant une adresse IPv6 « native » du serveur 18 « double pile » ; o Une réponse DNS6 IPv6 contenant au moins un enregistrement DNS IPv6 incluant une adresse IPv6 « fictive » du serveur 18 IPv4. Cette adresse est synthétisée par le serveur DNS64 comme décrit plus haut. Selon l'invention, selon la configuration choisie (comme exposé ci-dessus), le module de marquage 15a peut être confondu soit avec le serveur DNS autoritaire 14a, soit avec le serveur DNS64 14a'. A l'étape E91, lors de l'obtention de réponses DNS associée(s) à une requête DNS, le module de marquage 15a inscrit dans une structure en mémoire 15d (confondue avec la structure 14d sur la figure 7) une information "Type" définie ci-après. La structure de données en mémoire 14d se compose des champs suivants : Un champ contenant un identifiant de la requête DNS traitée, obtenu par copie de l'identifiant de la requête DNS traitée. Il est codé sur 16 bits. Un champ contenant un identifiant de l'enregistrement DNS, dans l'ordre de son obtention par le module 14 (14a ou 14a' selon la configuration). Ce champ est codé sur 4 bits. Selon une implémentation, on peut prévoir que ce champ contienne l'adresse IP contenue dans l'enregistrement DNS obtenu. Un champ indiquant le "Type" de l'enregistrement. Le Type d'un enregistrement dans la structure 14d indique le type de l'adresse IP contenue dans cet enregistrement DNS. Ce champ est codé sur 2 bits comme suit: 00 : "Authentique", "Non partagée" 01 : "Authentique", "partagée" : "Fictive", "Non partagée" 11 : "Fictive", "partagée" A l'étape E92, le serveur DNS autoritaire 14 (le module 14a ou le module 14a' selon la 10 configuration choisie) achemine le bloc d'information de type réponse DNS au module de marquage 15a. On peut également prévoir que le module de marquage 15a intercepte le bloc d'information de type réponse DNS. A l'étape E93, le module de marquage des blocs d'informations DNS 15a vérifie qu'il existe au moins un enregistrement dans le bloc d'information de type réponse DNS en cours de traitement. Si la réponse DNS n'est pas vide, c'est-à-dire qu'elle contient au moins un enregistrement DNS de type IPv4 ou bien de type IPv6, alors le module 15a passe à l'étape E94. Dans le cas contraire, à l'étape E95, la réponse DNS vide ne subit aucun marquage. Le module 15a passe à l'étape E97. A l'étape E94, la réponse DNS n'étant pas vide, le module 15a active la fonction locale Generate DNS Response Marking (DNS Request ID), dont l'exécution provoque la consultation du cache 14d afin d'obtenir le type des adresses IP contenues dans le ou les enregistrement(s) DNS d'une réponse DNS associée à une requête DNS. La fonction Generate DNS Response Marking est configurée pour identifier d'abord, dans la mémoire 14d la requête DNS initiale, par le champ identifiant de la requête DNS(DNS Request ID) (voir étape E91 plus haut). Ensuite, la fonction précitée obtient, dans l'ordre de leur lecture, le Type de chaque enregistrement DNS inclus dans la réponse. Les informations obtenues constituent un code de marquage des réponses DNS utilisé à l'étape suivante (E96). Ainsi par exemple, le code "0010" obtenu pour une réponse DNS indique que la réponse DNS contient deux enregistrements DNS: Le premier enregistrement DNS contient une adresse IPv4 publique, "Authentique" "Non partagée" Le deuxième enregistrement DNS contient une adresse IPv6 globale "Fictive", "Non partagée", synthétisée par le module DNS64 (14a'). A l'étape E96 le module de marquage (15a) active la fonction de marquage Apply Marking (DNS Response, Code) dont l'exécution provoque l'application à chaque bloc d'information de type réponse DNS, le code obtenu à l'étape E94. Ce code indique le type de chaque enregistrement inclus dans la réponse DNS, dans l'ordre de leur insertion dans la réponse DNS. A cette fin, la fonction Apply Marking insère le code précité dans le champ RDATA de l'extension EDNSO appliquée à la réponse DNS, comme représenté à la figure 10. L'envoi des blocs d'information DNS de type requête à destination de l'entité serveur DNS local 12 est illustré par l'étape E97. A l'étape E97, chaque bloc d'information de type réponse DNS généré à l'étape précédente (E96, E96a) est transmis à destination de l'entité serveur DNS local 12 (module 12a). A l'étape E98, l'ensemble de blocs d'information de type réponse DNS est reçu par le module serveur DNS local 12a. Si la réponse DNS reçue est vide alors elle est non marquée. Cette réponse est acheminée telle qu'elle par le serveur DNS local 12a à destination de l'application 11. Sinon, il existe au moins une réponse DNS non vide et marquée. Le traitement des réponses DNS marquées est alors mis en oeuvre. - Traitement des réponses DNS marquées Comme dit précédemment, dans les variantes de réalisation exposées, le module 15b de traitement des blocs d'informations de type réponse DNS est situé, selon une première variante (M2-V1) dans le module résolveur DNS local (11a) (voir figure 7), et selon une deuxième variante (M2-V2) dans le module DNS local 12a ou proxy 13 (voir figure 8). Première variante du 2ème mode de réalisation (M2-V1) Selon la première variante M2-V1du traitement des réponses marquées, le module 15b de traitement des blocs d'informations de type réponse DNS est situé dans le module résolveur DNS local (11 a), comme illustré par la figure 7. Dans ce cas, à l'étape E98, le module serveur DNS local 12a mémorise les réponses DNS reçues dans la structure en mémoire 12c. Le module 12a transmet ensuite chaque bloc d'information reçu de type réponse DNS marquée, sans modification, au terminal client (1). A l'étape E99, les blocs d'information DNS marquées sont reçus par l'entité 11 a du terminal client 1. Ils sont d'abord stockés en mémoire cache 11c. Ensuite, ils sont traités par le module de traitement des blocs d'informations DNS (15b), confondu avec le module résolveur (11 a). Selon cette première variante du deuxième mode de réalisation de l'invention (M2-V1), le module de traitement 15b gère dans une structure en mémoire 15c, l'état des interfaces IP fonctionnelles du terminal client 1. Cette structure de données 15c, décrite plus haut, indique pour chaque interface IP active, son type, son identifiant, son état, la préférence d'usage de l'interface ainsi qu'une durée de validité (Time to Live - TTL). Afin d'obtenir les préférences IP du terminal client 1, le module de traitement 15b exécute la fonction locale Get IP Interface Status Summary (). Cette fonction vérifie d'abord si le cache 15c contient au moins un enregistrement dont la durée de vie (TTL) est égale à zéro. Si c'est le cas, alors la mise à jour du cache 15c est forcée par l'exécution de la fonction Collect IP Interface Status( ip interface). Dans le cas contraire (si aucun enregistrement n'a une durée de vie égale à zéro), on passe à l'étape E100. A cette étape, une fonction notée : Generate Terminal IP Preference () est exécutée afin d'obtenir un résumé de l'information valide obtenue du cache 15c. Cette fonction résume le contenu du cache 15c en un code qui va indiquer les préférences IP instantanées du terminal client 1. L'exécution de la fonction Generate Terminal IP Preference précitée provoque d'abord la sélection du type et de la préférence d'usage de chaque enregistrement représentant une interface IP fonctionnelle (dont la valeur du champ "Etat fonctionnel de l'interface IP" est à 0, voir plus haut). Puis, les redondances entre ces enregistrements sont éliminées et pour chaque ensemble d'enregistrements fonctionnels du cache 15c, un seul code de marquage est généré. Chaque code contient au plus trois couples d'information : un premier décrivant l'état des interfaces IPv4, un deuxième décrivant l'état des interfaces IPv6 et un troisième décrivant l'état des interfaces "double pile". La valeur du code généré par la fonction Generate Terminal IP Preference est codée sur 32 bits. A titre d'exemple, si le cache 15c du module de marquage contient les enregistrements suivants : - - - Alors, la fonction Generate DNS Request Marking g énèrera le code suivant : ( , ) On passe ensuite à l'étape E101 au cours de laquelle, le module de traitement 15b active la fonction Apply Marking (DNS Response, Code1, Code2) pour adapter les enregistrements DNS contenus dans la ou les réponse(s) DNS reçue(s) aux contraintes du terminal client 1. Pour cela, il utilise le code indiqué dans le marquage des réponses DNS (champ RDATA), ainsi que le code indiquant l'état des interfaces IP fonctionnelles du terminal 1 afin de fournir à l'application cliente (11) seulement la ou les adresses IP "utiles" du serveur 18, c'est-à-dire, celles qui sont adaptées aux contraintes du réseau du terminal client 1. Ainsi, si le code indiquant les préférences IP du terminal client 1 est ( , ), et que la réponse obtenu contient deux enregistrements DNS : - Un premier enregistrement DNS qui comprend une adresse IPv4 authentique non partagé - Un deuxième enregistrement DNS qui comprend une adresse IPv6 fictive non partagé alors, la fonction Apply Marking indiquera à l'application cliente 11 uniquement l'adresse IPv4 du serveur 18. Elle supprime la réponse DNS contenant une adresse IPv6 fictive. Dans un autre exemple, si le code indiquant les préférences IP du terminal client 1 est ( , ), et que la réponse obtenu contient deux enregistrements DNS : Un premier enregistrement DNS qui comprend une adresse IPv4 authentique non partagé Un deuxième enregistrement DNS qui comprend une adresse IPv6 authentique non partagé alors cela signifie que le terminal 1 est configuré pour accepter de manière équivalente les réponses DNS IPv4 et les réponses DNS IPv6. Le module de traitement 15b retourne alors à l'application cliente (11) les adresses IPv4 et IPv6. Dans un troisième exemple, si le code indiquant les préférences IP du terminal client 1 est ( ), et que la réponse obtenu contient deux enregistrements DNS : - Un premier enregistrement DNS qui comprend une adresse IPv4 authentique non partagé - Un deuxième enregistrement DNS qui comprend une adresse IPv6 fictive non partagé alors le module de traitement 15b retourne à l'application cliente (11) l'adresse IPv6 fictive. Enfin, à l'étape E102, l'application cliente (11) obtient du module 11a, confondu avec le module 15b une ou plusieurs adresses IP associées à l'entité serveur 18, adaptées aux contraintes du réseau du terminal 1. Deuxième variante du 2ème mode de réalisation (M2-V2) Selon la deuxième variante M2-V2 du traitement des réponses marquées, le module 15b de traitement des blocs d'informations de type réponse DNS est situé dans le module serveur DNS local 12a ou bien dans le module proxy DNS 13, comme illustré par la figure 8. Une structure en mémoire 15d, est gérée par le module 15b. Cette structure en mémoire correspond soit à la mémoire référencée 12d lorsque le module de marquage 15b est situé dans le serveur DNS local 12, soit à la mémoire référencée 13c lorsque le module de marquage 15b est situé dans le serveur proxy DNS local 13. Cette mémoire, 12d ou 13c selon le cas, contient notamment pour chaque terminal client (1) des enregistrements, définissant pour chaque terminal client (1), les interfaces IP, la pile ou type des interfaces IP actives et fonctionnelles (IPv4 ou IPv6), la préférence d'usage par type d'interface, ainsi qu'une valeur de durée de validité (TTL). A l'étape E98a, le module de traitement des blocs d'informations DNS (15b) associe d'abord la réponse obtenu au terminal client qui a généré la requête DNS associée. Pour cela, le module 15b maintient au préalable une structure en mémoire associant chaque bloc d'information DNS au terminal qui l'a généré (structure 15e). Ensuite, à l'étape E99a, le module 15b exécute un certain nombre de fonctions pour obtenir les préférences IP du terminal client ayant généré la requête DNS en question. Tout d'abord, le module 15b consulte la mémoire cache (12d ou 13c) afin d'obtenir des informations valides indiquant le type de chaque interface IP fonctionnelle pour le terminal client 1 considéré. A cette fin, une fonction Get IP Interface Status (id terminal) est exécutée. Le module 15b utilise en effet l'identifiant de la requête DNS pour obtenir l'identifiant du terminal qui a généré la requête DNS. Suite à l'exécution de la fonction précitée : si le terminal n'est pas identifié par au moins un enregistrement dans la structure en mémoire 12d ou 13c, ou bien, si le terminal est identifié par au moins un enregistrement dans la structure en mémoire 12d ou 13c, mais qu'il existe au moins un enregistrement dont le TTL est égal à 0 dans la structure en mémoire, alors une mise à jour du cache est déclenchée, par l'intermédiaire d'une fonction Collect IP Interface Status( id client). L'exécution de cette fonction provoque la mise à jour de la mémoire cache (12d ou 13c), avec indication des interfaces du terminal client, ainsi que des préférences d'usage de la ou des interface(s) réseau fonctionnelles du terminal client 1 (identifié par le paramètre '_id client). Selon une première implémentation, une fonction cliente exécutée dans le module 15b interroge une fonction serveur exécutée dans le terminal client 1, selon une relation client-serveur. Plus précisément, il s'agit pour la fonction cliente de la fonction Collect IP Interface Status( id client), et pour la fonction serveur, de chaque terminal, de la fonction Generate Client Terminal Preferences(), similaire à la fonction Generate DNS Request Marking O décrite plus haut. La fonction cliente Collect IP Interface Status utilise un identifiant id client pour interroger le terminal en question et obtenir ses préférences IP ainsi que la liste de ces interfaces IP, grâce à une fonction serveur sur le terminal client 1 que nous appelons Generate Client Terminal Preferences O. L'identifiant du client id client est soit l'adresse IP soit l'adresse physique d'une interface d'un terminal ayant généré au moins une requête DNS à destination du serveur DNS local 12. Le code de marquage obtenu par la fonction cliente suite à l'interrogation d'un terminal client contient au plus trois couples d'information : un premier décrivant l'état des interfaces IPv4, un deuxième décrivant l'état des interfaces IPv6 et un troisième décrivant l'état des interfaces "double pile". Dans le cas particulier, où le module 15b est situé dans l'entité proxy DNS 13, le module 15b utilise une fonction d'interception des blocs d'information de type requête DNS pour obtenir pour chaque requête DNS l'identifiant du terminal client à l'origine de cette requête DNS. Ensuite, il communique avec le terminal comme décrit ci-dessous pour obtenir la liste des interfaces IP du terminal ainsi que ses préférences IP. Selon une seconde implémentation applicable, par exemple, à un contexte de clients résidentiels, la structure en mémoire (12d ou 13c) peut être alimentée manuellement par un utilisateur du terminal client 1 via une interface web fournie par un routeur-serveur DNS local 12. Ce routeur 12 étant alors confondu avec une passerelle résidentielle (désignée également box en anglais). Une fois le cache 12d ou 13c mis à jour, le module 15b passe ensuite à l'étape E100a. Dans le cas contraire (si le terminal est identifié avec des enregistrements valides, c.-à- d. dont la durée de vie est différente de zéro), on passe à l'étape E100a au cours de laquelle le module 15b obtient des informations de préférence d'usage de la ou des interface(s) IP fonctionnelles du terminal client 1. A l'étape E100a, le module 15b stocke d'abord l'ensemble des réponses DNS marquées reçues dans la mémoire 12c. Ensuite, il active la fonction Apply Marking (DNS Response, Codel , Code2) pour adapter les enregistrements DNS contenues dans la ou les réponse(s) DNS aux contraintes du terminal client 1. Pour cela, il utilise le code indiqué dans le marquage des réponses DNS (champ RDATA), ainsi que le code indiquant l'état des interfaces IP fonctionnelles du terminal 1 afin d'indiquer au terminal client (11) uniquement la ou les réponses DNS reçues "utiles", c'est-à- dire, celles qui sont adaptées aux contraintes du réseau de celui-ci. Cette fonction est similaire à ce qui est décrit plus haut (E101). Le module 15b passe ensuite à l'étape E101a, où il envoie les enregistrements DNS utiles résultant de l'étape précédente E100a dans un ou plusieurs bloc(s) d'information de type réponse DNS, au terminal client 1. Enfin, à l'étape E102a, l'entité 11a reçoit une ou plusieurs adresses IP associées à l'entité serveur 18, adaptées aux contraintes du réseau du terminal 1. Elle les stocke en mémoire 11c avant de les livrer à l'application cliente (11).30 REVENDICATIONS1. Procédé de traitement d'une demande de résolution d'un nom d'un serveur (18), émise par une application cliente (11) installée sur un terminal client (1), sur un réseau de communication, le procédé étant caractérisé par des étapes de : a) - obtention par une première entité réseau (11,12 ; 14) d'un ensemble de messages DNS suite à ladite demande de résolution ; b) - obtention par la première entité réseau (11,12 ; 14) d'informations de connectivité réseau relatives au moins audit terminal client ou audit serveur (18), et génération d'un code, dit de marquage, représentatif desdites informations de connectivité réseau ; c) - traitement par ladite première entité réseau (11,12 ; 14) dudit ensemble de messages DNS en fonction dudit code de marquage, et envoi en conséquence d'un ensemble de messages DNS, dits marqués, à une seconde entité réseau (14 ; 11,12) ; d) - traitement par la seconde entité réseau (14 ; 11,12) dudit ensemble de messages DNS marqués, afin de délivrer à l'application cliente (11) au moins une réponse DNS adaptée en fonction desdites informations de connectivité réseau. 2. Procédé selon la revendication 1, dans lequel à l'étape a) ledit ensemble de messages DNS est un ensemble de requêtes DNS générées suite à la réception par un module (11a) de résolution DNS de ladite demande de résolution de nom, et dans lequel à l'étape b), lesdites informations de connectivité réseau incluent au moins une information de type et de préférence d'usage d'interface IP active pour ledit terminal client (1). 3. Procédé selon la revendication 2, dans lequel l'étape c) de traitement de l'ensemble de requêtes DNS inclut : - l'insertion du code de marquage dans chaque requête dudit ensemble de requêtes DNS, à l'intérieur d'un champ déterminé du corps de la requête, formant ainsi un ensemble de requêtes marquées. 4. Procédé selon la revendication 3, dans lequel l'étape de traitement d) comprend la lecture du code de marquage contenu dans chaque requête de l'ensemble de requêtes marquées, puis la recherche d'enregistrements DNS conformes auxdites informations de connectivité obtenues à partir dudit code de marquage, et si au moins un tel enregistrement est trouvé, génération d'au moins une réponse DNS contenant ledit enregistrement, puis envoi de ladite au moins une réponse DNS à destination de l'application cliente (11). 5. Procédé selon la revendication 3, dans lequel ledit champ déterminé est un champ RDATA du corps de la requête conformément à l'extension EDNSO du protocole DNS. 6. Procédé selon la revendication 2, dans lequel l'étape c) de traitement inclut le filtrage dudit ensemble de requêtes DNS en fonction du code de marquage. 7. Procédé selon l'une quelconque des revendications 2 à 6, dans lequel ladite première entité réseau est située dans le terminal client (1) ou dans un serveur DNS local (12) vis-à-vis de l'application cliente, et ladite seconde entité réseau est située dans un serveur DNS autoritaire (14) pour le domaine associé au serveur (18). 8. Procédé selon la revendication 1, dans lequel à l'étape a) ledit ensemble de messages DNS est un ensemble de réponses DNS générées par ladite première entité réseau (14), suite à la réception d'un ensemble de requêtes DNS générées par un module (11a) de résolution DNS suite à la réception de ladite demande de résolution de nom, et dans lequel à l'étape b), lesdites informations de connectivité réseau sont caractéristiques d'un type d'adresse IP identifiant ledit serveur (18) contenue dans chaque réponse DNS dudit ensemble. 9. Procédé selon la revendication 8, dans lequel, à l'étape de traitement c) par ladite première entité réseau (14) de chaque réponse DNS dudit ensemble, comprend l'insertion du code de marquage à l'intérieur d'un champ déterminé du corps de la réponse, formant ainsi un ensemble de réponses marquées, puis l'envoi dudit ensemble de réponses DNS marquées à ladite seconde entité réseau (11,12). 10. Procédé selon la revendication 9, dans lequel l'étape de traitement d) effectué par ladite seconde entité réseau (11,12) comprend : - l'obtention d'informations indicatives de préférence de connectivité réseau pour le terminal client ; - la comparaison du code de marquage contenu dans chaque réponse de l'ensemble de réponses marquées avec lesdites informations indicatives de préférence de connectivité réseau pour ledit terminal client (1), puis la sélection des réponses DNS satisfaisant auxdites informations indicatives de préférence de connectivité réseau pour ledit terminal client. 11. Procédé selon la revendication 8, dans lequel ledit champ déterminé est un champ RDATA du corps de la réponse conformément à l'extension EDNSO du protocole DNS. 12. Procédé selon l'une quelconque des revendications 8 à 11, dans lequel ladite première entité réseau est située dans un serveur DNS autoritaire (14) pour le domaine associéau serveur (18), et ladite seconde entité réseau est située dans ladite application cliente (11) ou dans un serveur DNS local (12) vis-à-vis de l'application cliente. 13. Système de traitement d'une demande de résolution d'un nom d'un serveur (18), émise par une application cliente (11) installée sur un terminal client, sur un réseau de communication, caractérisé en qu'il comprend : - au moins une première entité réseau (11,12 ; 14) comportant : - un module d'obtention d'un ensemble de messages DNS suite à ladite demande de résolution ; - un module d'obtention d'informations de connectivité réseau relatives au moins audit terminal client (1) ou audit serveur (18), et de génération d'un code, dit de marquage, représentatif desdites informations de connectivité réseau ; et - un module de traitement de l'ensemble de messages DNS en fonction du code de marquage, afin d'obtenir un ensemble de messages DNS, dit marqués ; - au moins une seconde entité réseau (14 ; 11,12) comportant : - un module de réception dudit ensemble de messages DNS marqués, en provenance de ladite au moins une première entité réseau (11,12 ; 14) ; et - un module de traitement de l'ensemble de messages DNS marqués, afin de délivrer à l'application cliente (11) au mo ins une réponse DNS adaptée en fonction desdites informations de connectivité réseau. 14. Entité réseau mise en oeuvre pour le traitement d'une demande de résolution d'un nom d'un serveur, émise par une application cliente installée sur un terminal client (1), sur un réseau de communication, ladite entité réseau comportant : - un module d'obtention d'un ensemble de messages DNS suite à ladite demande de résolution ; - un module d'obtention d'informations de connectivité réseau relatives au moins audit terminal client ou audit serveur, et de génération d'un code, dit de marquage, représentatif desdites informations de connectivité réseau ; et - un module de traitement de l'ensemble de messages DNS en fonction du code de marquage, afin d'obtenir un ensemble de messages DNS, dit marqués. 15. Entité réseau mise en oeuvre pour le traitement d'une demande de résolution d'un nom d'un serveur, émise par une application cliente installée sur un terminal client, sur un réseau de communication, ladite entité réseau comportant : - un module de réception d'un ensemble de messages DNS marqués, en provenance d'une entité réseau selon la revendication 14; et- un module de traitement de l'ensemble de messages DNS marqués, afin de délivrer à l'application cliente au moins une réponse DNS adaptée en fonction desdites informations de connectivité réseau. 16. Programme d'ordinateur mis en oeuvre par une entité réseau sur un réseau de communication, ledit programme comprenant des instructions de code pour la mise en oeuvre des étapes a), b), c) et/ou d) d'un procédé de traitement d'une demande de résolution d'un nom d'un serveur, conforme à l'une quelconque des revendications 1 à 12, lorsque ce programme est exécuté par un processeur équipant ladite entité réseau.10