EP2052526A2 - Serveur et procede pour gerer les noms de domaines dans un reseau - Google Patents

Serveur et procede pour gerer les noms de domaines dans un reseau

Info

Publication number
EP2052526A2
EP2052526A2 EP07766024A EP07766024A EP2052526A2 EP 2052526 A2 EP2052526 A2 EP 2052526A2 EP 07766024 A EP07766024 A EP 07766024A EP 07766024 A EP07766024 A EP 07766024A EP 2052526 A2 EP2052526 A2 EP 2052526A2
Authority
EP
European Patent Office
Prior art keywords
server
com
domain
nsl
partition
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP07766024A
Other languages
German (de)
English (en)
Inventor
Daniel Migault
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP2052526A2 publication Critical patent/EP2052526A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

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

Definitions

  • the present invention relates to the general domain of domain name servers in a telecommunication network.
  • This architecture introduces the notion of "domain”, to designate a group of machines on the network.
  • Figure 1 shows such an architecture.
  • the domains., .Fr, .corn, ft.com and rd.ft.com contain subdomains.
  • the domain ft.com has in this example three subdomains, namely www.ft.com, rd.ft.com and user.ft.com.
  • terminal domains The domains that appear underlined in Figure 1 are called "terminal domains".
  • a terminal domain - can represent one or more physical machines, this is for example the case of the terminal domain www.rd.ft.com;
  • a domain that includes at least one subdomain is associated with a "domain server", otherwise called "name server”.
  • This domain server has a zone file.
  • the domains are logically connected to one another, which makes it possible, by querying the name servers step by step, starting with the root server (in English "root server"), to obtain the DNS data of any domain.
  • information refers in particular to the Internet Protocol (IP) address of a domain, a text box, or any field (CNAME, 7) associated with a domain.
  • IP Internet Protocol
  • CNAME any field
  • update operations which are added to the traditional reading operations (directory function) considerably increase the number of transactions handled by these servers.
  • these transactions require synchronization operations of the master and slave servers, which also consume resources on the network.
  • domain name servers are hosting more and more data, and larger and larger areas.
  • the invention aims to respond to the problem mentioned above.
  • a domain server in a telecommunications network adapted to manage DNS queries relating to the domain comprising means for receiving, from a client device, a request to obtain a DNS data of this domain.
  • the server includes:
  • a zone file comprising at least one distribution rule defining a partition of all the subdomains of the domain into a plurality of sub-areas, the DNS data of each of the sub-areas being hosted by a server, called a "partition server",
  • zone designate all the data hosted within a server
  • domain designate the logical entity
  • the partition servers are "child servers" of the domain name server, otherwise designated by the expression "parent server”.
  • the invention thus makes it possible to host the data of a domain in a plurality of child servers that define a partition of the subdomains of this domain.
  • the parent server can keep part of the data of his domain. The skilled person will understand that it is not, as the
  • DNS already allows it, to manage the same zone in its entirety by several servers, but to fragment a domain in small zones more easily administrable by the servers of domain names.
  • the invention makes it possible in particular to separate the data management logic of a domain from its implementation.
  • the heart of the invention lies more precisely in the zone file read by the server. Also, the invention aims, according to a second aspect, a data structure constituted by a computer file that can be read by a domain server in a telecommunications network (1).
  • This file contains:
  • partition servers each of them hosting the DNS data of a sub-area.
  • the administrator of a zone defines a logical partition of a domain, which amounts to distributing the subdomains of this domain into different groups, each group being hosted either by a child server or by the parent server.
  • the computer file according to the invention mainly comprises a list of the identifiers of the partition servers (that is to say the child servers and possibly the parent server), and a distribution rule to identify a particular partition server adapted to provide the desired DNS data.
  • the useful information returned by the server to redirect its client can be of different types.
  • it can include at least one of:
  • the at least one distribution rule accompanied by the names or aliases of the partition servers, the name of the appropriate partition server, and
  • the invention also relates to a client computer system of a domain name server in a telecommunications network, comprising means for sending to said server a request to obtain a DNS data of this domain.
  • This client computer system comprises means for interpreting a regular expression received in response to the request, this interpretation enabling it to obtain the name of a partition server capable of responding to the request.
  • the client device can query this server to obtain the data sought, progressing step by step as is customary in the use of the DNS architecture.
  • the useful information further comprises the address of the partition server associated with at least one of the aforementioned elements.
  • the distribution rule for identifying the partition server is a regular expression
  • the domain name server includes means for interpreting this regular expression to obtain the address of the partition server and send the partition server to the client device.
  • a regular expression can be defined as a line of computer code defining the search for a pattern ("pattern" in English) within a string of characters.
  • This particularly advantageous feature greatly facilitates the task of users who do not have a client device according to the invention, suitable for interpreting regular expressions.
  • the invention relates to a method for managing DNS queries relating to a domain in a telecommunications network comprising a step of receiving, from a client device, a request to obtain a DNS data item of this domain.
  • the process comprises;
  • a step of reading a zone file comprising at least one rule defining a partition of all the subdomains of the domain in a plurality of sub-zones, the DNS data of each of the sub-zones being hosted by a server, called "partition server”,
  • the invention also relates to a method of obtaining a DNS data of a domain in a telecommunications network, this method comprising a step of sending a request to obtain the data.
  • This method comprises a step for interpreting a regular expression received in response to the request, and for obtaining, from this interpretation, the name of a partition server capable of responding to the request.
  • the different steps of the management method and the method of obtaining are determined by instructions of computer programs.
  • the invention also relates to computer programs on an information medium, these programs being capable of being implemented in a computer, in a domain name server or in a client device, these programs comprising instructions adapted to the implementation of a method of managing domain names or a method of obtaining data as briefly mentioned above.
  • These programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also relates to a computer-readable information medium or a domain name server, and comprising instructions of at least one computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium can be a transmissibie medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • Appendices 1 and 2 represent the main lines of a zone file of a father domain name server according to the invention in two embodiments;
  • Appendix 3 shows the main lines of a zone file of a child domain name server according to the invention in a preferred embodiment
  • FIG. 1, already described, represents an example of a tree of DNS domains known to those skilled in the art
  • FIG. 2 represents a telecommunications network comprising a parent domain name server according to the invention and two partition servers;
  • FIG. 3 represents, in flowchart form, the main steps of a domain name management method according to the invention in a preferred embodiment
  • FIG. 4 represents, in flowchart form, the main steps of a method for obtaining data according to the invention in a preferred embodiment.
  • FIG. 2 represents a telecommunications network 1 and an nsl domain name server managing a domain (or zone) zl.com.
  • this zone zl.com is divided into several sub-zones.
  • a distribution rule which in this example divides the subdomain names of the zl.com domain as follows:
  • FIG. 2 shows means 10 for receiving and sending data on the telecommunications network 1, these means being example constituted by a network card associated with drivers managing the http protocol (Hyper Text Transfer Protocol), and conventional processing means 20 of a computer, namely in particular a processor, a memory containing computer programs, and a random access memory to temporarily store the necessary variables of execution of these programs.
  • http protocol Hyper Text Transfer Protocol
  • the processing means of the server ns1 are adapted to execute the instructions of a computer program implementing the main steps ElO to E50 of the management method according to the invention shown in FIG. 3.
  • the means 20 for processing the client device CL1 are adapted to execute the instructions of a computer program implementing the main steps F10 to F30 of the method of obtaining DNS data according to the invention shown in FIG. figure 4.
  • step FlO of FIG. 4 the client CL1 sends (step FlO of FIG. 4), using the communication means 10, a request to the domain name server nsl of the IP address 10.193.161.50 to obtain the IP address of the subscript. domain.zl.com domain, also rated
  • This request may for example be of the type
  • This request is received in step E10 of FIG. 3 by the means 10 for receiving the nsl domain name server.
  • the DIG command does not include a type, it means that the data sought by the client is a data of type A, namely the IP address of domain domain2.zl.com.
  • the name processing means 20 of the server ns1 are adapted to read, during a step E20, the zone file FZ1. zone defining the zl.com zone management by this nsl server.
  • This zone file FZl.zone can for example be stored in a memory 30 of the server nsl. It can also be stored in another machine.
  • the main lines of this FZl.zone zone file are given in Appendix 1.
  • This file comprises in particular lines L9 and LlO having the identifiers nsl-partl and nsl-part2 partition servers that manage the DNS data zone zl.com.
  • lines L6 and L7 of the zone file FZl.zone include a distribution rule for, in this example, to redirect the client CLl: - to the server nsl-partl.zl.com for any request to obtain a data associated with a subdomain whose first letter is between "a" and "m", and - to the server nsl-part2.zl.com for others.
  • the "regexp" field contains a regular expression to which the request issued by the client must be substituted. This result is the next request to be issued by the client.
  • the regular expression is constituted by a test which then makes it possible to indicate the name of the server which hosts the data sought.
  • Appendix 2 comprises the main lines of a zone file FZlb.sys of the server nsl according to the invention in a second embodiment.
  • This zone file differs from the previous one in that the redirection indication is placed in the field "regexp", ie "replacement” field being empty.
  • NAPTR Noise Autority Pointer
  • the "service” field is defined in RFC 3403. This is a string of characters that allows the client to identify the processing that must be done by him.
  • the service D2NS is introduced in order to inform the client how the fields of the rule stated in the NAPTR field should be interpreted.
  • the NAPTR field would be the following one:
  • the NAPTR field would be for example the following:
  • the advantage of not including the name of the rule as a domain name is to guarantee that the set of rules will be at the root of the zone, and to avoid a misinterpretation of the domain name relating to the rule. .
  • the client can determine if the name referred to by the NS type field is a domain name or distribution rule.
  • the interest of including the rule as a domain name is to specify the name of the domain on which the next query will be made.
  • the following interrogation relates to the field with the type A.
  • the interrogation relates to the NAPTR type field.
  • the ns field of the server managing the partitions points to a domain name that must follow a query on a type A field. This is no longer the case in the zone files according to the invention.
  • the field ns refers to an NAPTR type field, in which the distribution rules (lines L6 and L7) are located.
  • the creation of a new type of field could be considered instead of using the NAPTR field as described in this embodiment.
  • the processing means of the server nsl are adapted to interpret (step E30) the regular expressions of the lines L6 and L7 to obtain, from the name domain2.zl.com, the nsl-partl name of the partition server that hosts the desired DNS data.
  • the processing means 10 of the server nsl are adapted to obtain, during a step E40, useful information to redirect the client CLl to the partition server nsl-partl .
  • This useful information can be of different types. It may for example include the rule of distribution l_6, L7.
  • the useful information obtained by the server nsl can also include the name (nsl-partl, zl.com) of the partition server.
  • alias of this server may be part of the useful information to redirect the CLl client to the partition server hosting the data. this field, namely in this case nslpart2.zLcom.
  • the useful redirection information also includes the IP address 10.193161.30 of a partition server, associated at least with one of the distribution rule L6, L7, the name nsl-part2 of the partition server. partition server or the server alias of this server.
  • a response comprising the useful information obtained during steps E30 and E40 is sent, during a step E50, by the server of name ns1 to the client CL1.
  • the quote CL1 receives this response during a step F20 shown in FIG. 4,
  • the response to the DIG query mentioned above can take one of the following forms;
  • QUERY status: IMOERROR, id: 21511 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: Domain, zl.com, IN
  • the processing means 20 of the client device CL1 are adapted to interpret, if necessary, the distribution rule L6, L7 contained in the response.
  • the client device CL1 determines by this interpretation that the name of the partition server containing the data sought is nsl-partl.
  • the useful redirection information contained in the response is handled by the CLl client which recognizes that it must query the nsl-partl.zl.com server for the IP address of the domain2.zl domain. com.
  • it transmits (step FlO) a request that is received, during a step ElO, by the communication means 20 of the son server nsl-partl.
  • zone file FZl-partl.zone that manages the partition of the nsl-partl server is given in Appendix 3.
  • the child server nsl-partl reads (step E20) the zone file FZl-partl.zone and obtains (step E40) the address 10.193.161.33 domain domain2.zl.com (see line L13 of Annex 3). This address is sent during the step E50 to the CLl client.
  • the zone file In the embodiment described here, the zone file
  • FZl.partl.zone of the nsl-partl child server also contains the information to redirect the CLl client if it has incorrectly interrogated the nsl-partl server, for example to obtain data associated with a subdomain name whose the letter begins, for example, with the letter "t".
  • the nsl-partl child server returns information that allows the CLl client to query the correct server, namely nsl-part2.
  • the response of the server nsl-partl is in this case of the form:
  • nsl IN NAPTR 100 50 «a» «D2NS» «! ⁇ [am] »nsl-partl .zl.com.
  • nsl IN NAPTR 100 50 "a""D2NS""S ⁇ [n-2]" nsl-part2.zl.com.
  • class type oorrddeerr pref flags service regexp replacement // LS nsl IN NAPTR 100 50 'a''D2NS''i ⁇ [am] insl-partl.zl.com.'"// L6 nsl IN NAPTR 100 50 « a » « "I ⁇ [ ⁇ -z] 'nsl part2 zl.com. ⁇ »IM

Abstract

Ce serveur de domaine comporte un fichier de zone comportant des règles de répartition qui définissent une partition de l'ensemble des sous-dossiers de ce domaine en une pluralité de sous-zones. Les données DNS de chacune de ces sous-zones sont hébergées par un serveur de partition, Ce serveur de domaine est apte à obtenir, à partir de fichiers de zone, une information permettant d'identifier Ie serveur de partition capable de répondre à une requête, émise par un client, en vue d'obtenir un dossier DNS.

Description

SERVEUR ET PROCEDE POUR GERER LES NOMS DE DOMAINES
DANS UN RESEAU
Arrière-plan de l'invention La présente invention se rapporte au domaine général des serveurs de noms de domaines dans un réseau de téiécommunication.
De façon connue, la gestion des noms de domaines dans un réseau est réalisée par l'architecture DNS (en anglais "Domain Name System") définie par le RFC 1034 (en anglais "Request For Comments") de I1IETF ("Internet Engineering Task Force").
Cette architecture introduit la notion de "domaine", pour désigner un regroupement de machines sur le réseau.
La Figure 1 représente une telle architecture. De façon connue les domaines ., .fr, .corn, ft.com et rd.ft.com contiennent des sous- domaines.
Par exemple Ie domaine ft.com comporte dans cet exemple trois sous-domaines, à savoir www.ft.com, rd.ft.com et user.ft.com.
Les domaines qui apparaissent soulignés sur la figure 1 sont appelés "domaines terminaux". De façon connue, un domaine terminal : - peut représenter une ou plusieurs machines physiques, c'est par exemple le cas du domaine terminal www.rd.ft.com ;
- mais aussi ne pas représenter de machine physique, c'est par exemple le cas du domaine terminal user.ft.com qui dans cet exemple est constitué par des informations personnelles de l'utilisateur "user". De façon connue, un domaine qui comporte au moins un sous- domaine est associé à un "serveur de domaine", autrement appelé "serveur de nom".
Ce serveur de domaine comporte un fichier de zone. De façon connue, les domaines sont liés entre eux de façon logique, ce qui permet en interrogeant les serveurs de noms de proche en proche, en commençant par le serveur racine (en anglais "root server"), d'obtenir les données DNS de n'importe quel domaine.
Dans ce document, le terme "informations" désigne notamment l'adresse IP (Internet Protocol) d'un domaine, une zone de texte, ou n'importe quel champ (CNAME,...) associé à un domaine. Avec la popularité croissante de l'Internet, les serveurs de noms de domaines sont de plus en plus difficiles à administrer.
En particulier, les opérations de mise à jour, qui s'ajoutent aux opérations traditionnelles de lecture (fonction d'annuaire), augmentent considérablement le nombre de transactions gérées par ces serveurs. Par ailleurs, ces transactions nécessitent des opérations de synchronisation des serveurs maîtres et esclaves, elles aussi consommatrices de ressources sur le réseau.
Au surplus, les serveurs de noms de domaines hébergent de plus en plus de données, et des zones de plus en plus grandes.
Auparavant, les noms de domaines n'avaient guère comme informations que des adresses IP, cette donnée n'excédant pas une vingtaine d'octets. Aujourd'hui, le DNS héberge des profils beaucoup plus volumineux (environ 200 octets), comme dans le cas des services ENUM (tels que décrits dans la RFC 2916 de l'IETF), par exemple.
Une solution connue à ce problème consiste à créer des sous- domaines, les serveurs de noms de ces sous-domaines ainsi créés hébergeant une partie des données qui étaient jusqu'alors hébergées par le domaine dont ils sont issus. Mais cette solution ajoute un niveau supplémentaire dans la hiérarchie des domaines, ce qui se traduit par une complication du nom de sous-domaine nouvellement créé,
Or cette complexité dans le nom du sous-domaine peut être perçue comme un inconvénient, notamment lorsque le nom de ce sous- domaine est utilisé à des fins commerciales ou publicitaires.
Objet de l'invention
L'invention vise à répondre au problème précité. A cet effet, elle propose, selon un premier aspect, un serveur de domaine dans un réseau de télécommunications adapté à gérer les requêtes DNS relatives au domaine, comportant des moyens pour recevoir, en provenance d'un dispositif client, une requête visant à obtenir une donnée DNS de ce domaine. Le serveur comporte :
- un fichier de zone comportant au moins une règle de répartition définissant une partition de l'ensemble des sous-domaines du domaine en une pluralité de sous-zones, les données DNS de chacune des sous-zones étant hébergée par un serveur, dit « serveur de partition »,
- des moyens pour obtenir, à partir du fichier de zone, une information suffisante, pour identifier le serveur de partition adéquat capable de répondre à la requête ; et
- des moyens pour envoyer l'information utile au dispositif client en réponse à la requête.
De manière générale, on parle de zone pour désigner l'ensemble des données hébergées au sein d'un serveur, et de domaine pour désigner l'entité logique. Néanmoins, les termes "zone" et "domaine" sont souvent interchangeables dans la littérature.
Dans la suite de ce document, on considérera qu'au sens de l'invention, les serveurs de partition sont des "serveurs fils" du serveur de nom de domaine, autrement désigné par l'expression "serveur père". L'invention permet ainsi d'héberger les données d'un domaine dans une pluralité de serveurs fils qui définissent une partition des sous- domaines de ce domaine.
Bien entendu, le serveur père peut conserver une partie des données de son domaine. L'homme du métier comprendra qu'il ne s'agit pas, comme le
DNS le permet déjà, de gérer une même zone dans son intégralité par plusieurs serveurs, mais de fragmenter un domaine en petites zones plus facilement administrables par les serveurs de noms de domaines.
Très avantageusement, l'invention permet notamment de dissocier la logique de gestion des données d'un domaine de sa mise en œuvre.
Le cœur de l'invention réside plus précisément dans le fichier de zones lu par le serveur. Aussi, l'invention vise, selon un deuxième aspect, une structure de données constituée par un fichier informatique susceptible d'être lu par un serveur de domaine dans un réseau (1) de télécommunications. Ce fichier comporte :
- des lignes définissant au moins une règle de répartition de l'ensemble des sous-domaines du domaine en une pluralité de sous-zones ;
- des lignes comportant des identifiants d'une pluralité de serveurs, dits « serveurs de partition », chacun d'entre eux hébergeant les données DNS d'une sous-zone. En pratique, l'administrateur d'une zone définit une partition logique d'un domaine, ce qui revient à répartir les sous-domaines de ce domaine en différents groupes, chaque groupe étant hébergé soit par un serveur fils, soit par le serveur père lui-même, Aussi, ie fichier informatique selon l'invention comprend principalement une liste des identifiants des serveurs de partition (c'est-à- dire les serveurs fils et éventuellement Ie serveur père), et une règle de répartition permettant d'identifier un serveur de partition particulier adapté à fournir la donnée DNS recherchée. L'information utile renvoyée par le serveur pour rediriger son client peut être de différents types.
Par exemple, elle peut au moins comporter un élément parmi :
- la au moins une règle de répartition accompagnée des noms ou des alias des serveurs de partition, - le nom du serveur de partition adéquat, et
- un alias du serveur de partition adéquat.
Si l'information utile est constituée par la règle de répartition, Ie dispositif client, ou son administrateur, doit interpréter la règle de répartition pour déterminer le nom du serveur de partition. Aussi, et selon un troisième aspect, l'invention vise également un système informatique client d'un serveur de noms de domaine dans un réseau de télécommunications, comportant des moyens pour envoyer audit serveur une requête visant à obtenir une donnée DNS de ce domaine. Ce système informatique client comporte des moyens pour interpréter une expression régulière reçue en réponse à Ia requête, cette interprétation lui permettant d'obtenir le nom d'un serveur de partition capable de répondre à la requête.
Une fois qu'il connaît le nom ou l'alias du serveur de partition, Ie dispositif client peut interroger ce serveur pour obtenir les données recherchées, en progressant de proche en proche comme il en est d'usage dans l'utilisation de l'architecture DNS.
Préférentiellement, l'information utile comporte en outre l'adresse du serveur de partition, associée à au moins l'un des éléments précités. Dans un mode préféré de réalisation, la règle de répartition permettant d'identifier le serveur de partition est une expression régulière, et le serveur de noms de domaines comporte des moyens pour interpréter cette expression régulière de manière à obtenir l'adresse du serveur de partition et envoyer cette dernière au dispositif client.
On rappelle que, de façon connue, une expression régulière peut être définie comme une ligne de code informatique définissant la recherche d'un motif ("pattern" en anglais) au sein d'une chaîne de caractères.
Cette caractéristique particulièrement avantageuse facilite grandement la tâche des utilisateurs qui ne possèdent pas de dispositif client selon l'invention, adapté à interpréter les expressions régulières.
Corrélativement, l'invention concerne un procédé de gestion des requêtes DNS relatives à un domaine dans un réseau de téiécommunications comportant une étape de réception, en provenance d'un dispositif client, d'une requête visant à obtenir une donnée DNS de ce domaine.
Le procédé comporte ;
- une étape de lecture d'un fichier de zone, le fichier comportant au moins une règle définissant une partition de i'ensemble des sous-domaines) du domaine en une pluralité de sous-zones, les données DNS de chacune des sous-zones étant hébergée par un serveur, dit « serveur de partition »,
- une étape d'obtention, à partir du fichier de zone d'une information suffisante pour identifier le serveur de partition capable de répondre à la requête ; et
- une étape d'envoi de ladite information utile au dispositif client en réponse à la requête.
L'invention vise aussi un procédé d'obtention d'une donnée DNS d'un domaine dans un réseau de télécommunications, ce procédé comportant une étape d'envoi d'une requête visant à obtenir la donnée.
Ce procédé comporte une étape pour interpréter une expression régulière reçue en réponse à la requête, et pour obtenir, à partir de cette interprétation, te nom d'un serveur de partition capable de répondre à la requête.
Selon une implémentation préférée, les différentes étapes du procédé de gestion et du procédé d'obtention sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, ï'invention vise aussi des programmes d'ordinateur sur un support d'informations, ces programmes étant susceptibles d'être mis en œuvre dans un ordinateur, dans un serveur de noms de domaines ou dans un dispositif client, ces programmes comportant des instructions adaptées à Ia mise en œuvre d'un procédé de gestion de noms de domaines ou d'un procédé d'obtention de donnée tels que mentionnés brièvement ci-dessus.
Ces programmes peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur ou un serveur de noms de domaines, et comportant des instructions d'au moins un programme d'ordinateur tels que mentionnés ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le 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 magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissibïe tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des dessins
D'autres caractéristiques et avantages de Ia présente invention ressortiront de la description faite ci-dessous, en référence aux annexes et dessins qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif et dans lesquels :
- les annexes 1 et 2 représentent les principales lignes d'un fichier de zone d'un serveur de noms de domaines père conforme à l'invention dans deux modes de réalisation ;
- l'annexe 3 représente les principales lignes d'un fichier de zone d'un serveur de noms de domaines fils conforme à l'invention dans un mode préféré de réalisation ;
- Ia figure 1, déjà décrite, représente un exemple d'une arborescence de domaines DNS connue de l'homme du métier ;
- la figure 2 représente un réseau de télécommunications comportant un serveur de noms de domaines père conforme à l'invention et deux serveurs de partition ;
- la figure 3 représente, sous forme d'organigramme, !es principales étapes d'un procédé de gestion de noms de domaines conforme à l'invention dans un mode préféré de réalisation ; et
- la figure 4 représente, sous forme d'organigramme, les principales étapes d'un procédé d'obtention d'une donnée conforme à l'invention dans un mode préféré de réalisation.
Description détaillée d'un mode de réalisation
La figure 2 représente un réseau de télécommunications 1 et un serveur de noms de domaines nsl gérant un domaine (ou zone) zl.com. Comme mentionné précédemment, pour mettre en œuvre l'invention, on partitionne cette zone zl.com en plusieurs sous-zones. Pour cela, on utilise une règle de répartition, qui, dans cet exemple, répartit les noms des sous-domaines du domaine zl.com de la façon suivante :
- les noms de sous-domaines dont la première lettre commence par une lettre comprise entre "a" et "m" sont hébergés par le serveur fils nsl-partl ; et
- les noms de sous-domaines dont la première lettre commence par une lettre comprise entre "n" et "z" sont hébergés par le serveur fils nsl-part2. Ainsi, lorsqu'un client CLl interroge le serveur père nsl pour obtenir une donnée DHS relative au sous-domaine domaine2.zl,com, ce client reçoit, en réponse à cette requête, une information utile qui le redirige vers le serveur de partition nsl-partl, puisque la première lettre du nom de ce sous-domaine (domaine2.zl,com) est la lettre "d", comprise entre les lettres "a" et "m". Pour le client CLl et pour chacun des serveurs de noms de domaines nsl, nsl-partl et nsl-part2, on a représenté à la figure 2 des moyens 10 pour recevoir et envoyer des données sur ie réseau de télécommunications 1, ces moyens étant par exemple constitués par une carte réseau associée à des pilotes gérant le protocole http (Hyper Text Transfer Protocol), et des moyens 20 de traitement classiques d'un ordinateur, à savoir notamment un processeur, une mémoire contenant des programmes informatiques, et une mémoire vive pour stocker temporairement ies variables nécessaires d'exécution de ces programmes.
Les moyens 20 de traitement du serveur nsl sont adaptés à exécuter les instructions d'un programme d'ordinateur mettant en œuvre les principales étapes ElO à E50 du procédé de gestion conforme à l'invention représenté à la figure 3.
De même, les moyens 20 de traitement du dispositif client CLl sont adaptés à exécuter les instructions d'un programme d'ordinateur mettant en œuvre les principales étapes FlO à F30 du procédé d'obtention de donnée DNS conforme à l'invention représenté à la figure 4.
Nous allons supposer que le client CLl envoie (étape FlO de la figure 4), en utilisant les moyens de communication 10, une requête au serveur de noms de domaines nsl d'adresse IP 10,193.161.50 pour obtenir l'adresse IP du sous-domaine domaine2.zl.com, notée également
IP(domaine2.zl.com),
Cette requête peut par exemple être du type ;
DIG 10.193.161.50 +norecurse domaine2.zl.com, DIG (Domaine Information Groper) étant l'outil connu de l'homme du métier pour interroger les serveurs de noms de domaines dans l'architecture DNS.
Cette requête est reçue à l'étape ElO de la figure 3 par les moyens 10 de réception du serveur de noms de domaines nsl.
L'homme du métier reconnaîtra que puisque la commande DIG ne comporte pas de type, cela signifie que la donnée recherchée par le client est une donnée de type A, à savoir l'adresse IP du domaine domaine2.zl.com.
Après l'étape ElO de réception de la requête du client CLl, les moyens 20 de traitement de noms du serveur nsl sont adaptés à iire au cours d'une étape E20 le fichier de zone FZl. zone définissant la gestion de la zone zl.com par ce serveur nsl.
Ce fichier de zone FZl.zone peut par exemple être mémorisé dans une mémoire 30 du serveur nsl. Il peut aussi être mémorisé dans une autre machine. Les principales lignes de ce fichier de zone FZl.zone sont données à l'annexe 1.
Les lignes conformes au standard DNS et connues de l'homme du métier ne seront pas décrites ici.
Ce fichier comporte en particulier des lignes L9 et LlO comportant les identifiants nsl-partl et nsl-part2 des serveurs de partition qui gèrent les données DNS de la zone zl.com.
L'homme du métier reconnaîtra, à !a ligne L9, que l'adresse du serveur nsl-partl. zl.com sur le réseau 1 est 10.193.161.73 (champ A), et que serveur 1 est un alias (champ CNAME) du serveur de partition nsl- part2.zl.com, l'adresse de ce serveur de partition sur ie réseau 1 étant
10.193.161.30, comme indiqué en ligne LlL
Par ailleurs, les lignes L6 et L7 du fichier de zone FZl.zone comportent une règle de répartition pour, dans cet exemple, rediriger le client CLl : - vers le serveur nsl-partl.zl.com pour toute requête d'obtention d'une donnée associée à un sous-domaine dont la première lettre est comprise entre "a" et "m", et - vers le serveur nsl-part2.zl.com pour les autres.
Plus précisément, le champ "regexp" contient une expression régulière à laquelle la requête émise par le client doit être substituée. Ce résultat constitue ainsi la prochaine requête à émettre par le client.
Conformément à l'invention, l'expression régulière est constituée par un test qui permet ensuite d'indiquer le nom du serveur qui héberge la donnée recherchée. L'annexe 2 comporte les principales lignes d'un fichier de zone FZlbîs.zone du serveur nsl conforme à l'invention dans un deuxième mode de réalisation.
Seules les lignes L6 et L7 diffèrent du fichier de zone FZl. zone de l'annexe 1.
Ce fichier de zone diffère du précédent en ce que l'indication de redirection est placée dans Se champ "regexp", ie champ "replacement" étant vide.
En variante, on pourrait aussi décider de préciser un nouveau service, ceci afin d'éviter toute interprétation sur la nature de la règle de répartition (on désigne par "service" la logique que le client doit adopter afin de résoudre correctement la requête). Ainsi, en choisissant le sigie "D2NS" (Domaine to Name Server), le champ NAPTR (Naming Autority Pointer) serait le suivant :
classe type flags service regexp replacement nsl IN NAPTR « a » «D2NS» «iΛ[a-m] !πsl-partl.zl.com.!»
Le champ "service" est défini dans la norme RFC 3403. C'est une chaîne de caractères qui permet au client d'identifier Ie traitement qui doit être fait par lui. Dans cette variante, on introduit Ie service D2NS afin de signifier au client la manière dont doivent être interprétés les champs de la règle énoncée dans le champ NAPTR.
En variante, on pourrait également aussi décider de préciser le nom de la règle de répartition comme argument de la fonction du service, ceci afin d'éviter toute interprétation sur la nature de la règle de répartition. Ainsi, en choisissant le sigie "D2NS" (Domaine to Name Server), le champ NAPTR serait le suivant :
classe type flags service regexp replacement
IN NAPTR « a » «D2NS!nsl!» «!A[a-m] !nsl-partl.zi.com.!»
En variante, on pourrait également aussi décider de préciser Ie nom de la règle de répartition dans Ie champ regexp, ceci afin d'éviter toute interprétation sur la nature de la règle de répartition. Ainsi, en choisissant le sigle "D2NS" (Domaine to Name Server), Ie champ NAPTR serait par exemple le suivant :
classe type fîags service regexp replacement
IN NAPTR « a » «D2NS!nsl!» «!Λ[a-m] !\\:nsl:nsl~partl.zl.com.!»
L'intérêt de ne pas faire figurer Ie nom de la règle comme nom de domaine est de garantir que l'ensemble des règles se trouveront à la racine de la zone, et d'éviter une mauvaise interprétation du nom de domaine relatif à la règle.
Il est alors préférable que le client puisse déterminer si le nom auquel fait référence le champ de type NS est un nom de domaine ou une règle de répartition.
L'intérêt de faire figurer la règle comme un nom de domaine est de préciser le nom du domaine sur lequel se fera la prochaine interrogation. Traditionnellement, l'interrogation qui suit porte sur le champ avec le type A. Dans l'invention, l'interrogation porte sur le champ de type NAPTR.
Selon le DNS traditionnel, le champ ns du serveur gérant ies partitions pointe sur un nom de domaine que doit suivre une interrogation portant sur un champ de type A. Ceci n'est plus le cas dans les fichiers de zone conformes à l'invention.
Dans le mode de réalisation préféré décrit ici, le champ ns fait référence à un champ de type NAPTR, dans lesquels se trouvent les règles de répartition (lignes L6 et L7). Bien entendu, la création d'un nouveau type de champ pourrait être envisagée au lieu d'une utilisation du champ NAPTR comme décrit dans ce mode de réalisation.
Le fait que le champ ns associé au nom de domaine zl.com ne pointe pas vers un champ de type A est un élément caractéristique d'un fichier de zone conforme à l'invention.
La présence de règles de répartition en est un autre. Dans un mode préféré de réalisation, les moyens 10 de traitement du serveur nsl sont adaptés à interpréter (étape E30) les expressions régulières des lignes L6 et L7 pour obtenir, à partir du nom domaine2.zl.com, le nom nsl-partl du serveur de partition qui héberge la donnée DNS recherchée.
Quoi qu'il en soit, conformément à l'invention, les moyens de traitement 10 du serveur nsl sont adaptés à obtenir, au cours d'une étape E40, une information utile pour rediriger le client CLl vers le serveur de partition nsl-partl.
Cette information utile peut être de différents types. Elle peut par exemple comporter la règle de répartition l_6, L7. L'information utile obtenue par le serveur nsl peut aussi comporter ie nom (nsl-partl, zl.com) du serveur de partition.
Elle peut aussi comporter un alias de ce serveur. Ainsi, en supposant que le client CLl interroge le serveur nsl avec un nom de domaine commençant par la lettre "r", l'alias "serveurl" peut faire partie des informations utiles pour rediriger le client CLl vers Ie serveur de partition hébergeant les données de ce domaine, à savoir en l'espèce nsl- part2.zLcom.
Dans un mode préféré de réalisation, l'information utile de redirection comporte également l'adresse IP 10.193161.30 d'un serveur de partition, associée au moins à un élément parmi la règle de répartition L6, L7, le nom nsl-part2 du serveur de partition ou l'alias serveurl de ce serveur.
En revenant à la figure 3, une réponse comportant l'information utile obtenue au cours des étapes E30 et E40 est envoyée, au cours d'une étape E50, par le serveur de nom nsl au client CLl. Le citent CLl reçoit cette réponse au cours d'une étape F20 représentée sur la figure 4,
Plus précisément, la réponse à la requête DIG mentionnée ci- dessus peut prendre l'une des formes suivantes ;
; <<>> DiG 9.3.1 <<>> domaine.zl.com ;; global options; printcmd ;; Got answer:
;; -»HEADER«- opcode; QUERY, status: IMOERROR, id: 21511 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;domaine,zl.com, IN
;; ANSWER SECTION: domaine.zl.com. 300 IN A 212.78.202.252
;; AUTHORITY SECTION: zl.com. 80394 IN NS nsl
ADDITIONAL SECTION:
classe type order pref flags service regexp replacement nsl IN NAPTR 100 50 « a » « » "!Λ[a-m]" nsl-partl. zl.com nsi IN NAPTR 100 50 « a » « » "!Λ[n-z]" nsl-paιt2.zlxom
nsl-partl.zLcom. IN A 10.193.161.73 nsl-part2.zl.com. IN CNAME serveurl serveur! IN A 10.193.161.30
;; Query time: 91 msec ;; SERVER: 10.193.117.254#53(10.193.117.254) ;; WHEN: Fri Apr 22 16:14:46 2005 ;; MSG SIZE rcvd: 217
Conformément à l'invention, les moyens de traitement 20 du dispositif client CLl sont adaptés à interpréter, Ie cas échéant, la règle de répartition L6, L7 contenue dans la réponse.
En l'espèce, le dispositif client CLl détermine grâce à cette interprétation que le nom du serveur de partition comportant la donnée recherchée est nsl-partl. Quoi qu'il en soit, les informations utiles de redirection contenues dans la réponse sont traitées par le client CLl qui reconnaît qu'il doit interroger Ie serveur nsl-partl.zl.com pour obtenir l'adresse IP du domaine domaine2.zl.com. A cet effet, il émet (étape FlO) une requête qui est reçue, au cours d'une étape ElO, par les moyens de communication 20 du serveur fils nsl-partl.
Le fichier de zone FZl-partl.zone qui gère ia partition du serveur nsl-partl est donné à l'annexe 3.
Sur réception de cette requête, le serveur fils nsl-partl lit (étape E20) le fichier de zone FZl-partl.zone et obtient (étape E40) l'adresse 10.193.161.33 du domaine domaine2.zl.com (voir ligne L13 de l'annexe 3). Cette adresse est envoyée au cours de l'étape E50 au client CLl.
Dans Ie mode de réalisation décrit ici, le fichier de zone
FZl.partl.zone du serveur fils nsl-partl comporte également les informations permettant de rediriger le client CLl si celui-ci a interrogé le serveur nsl-partl à tort, par exemple pour obtenir une donnée associée à un nom de sous-domaine dont la lettre commence par exemple par Ia lettre "t".
Dans ce cas là, le serveur fils nsl-partl renvoie une information qui permet au client CLl d'interroger le bon serveur, à savoir nsl-part2.
Préférentiellement, la réponse du serveur nsl-partl est dans ce cas de la forme :
zl.com. IN ns nsl classe type order pref flags service regexp Replacement nsl IN NAPTR 100 50 « a » «D2NS» «!Λ[a-m] » nsl-partl .zl.com. nsl IN NAPTR 100 50 « a » «D2NS» «SΛ[n-2] » nsl-part2.zl.com.
nsl-partl, .zl xom. IN A 10.193, ,161.73 nsl-part2, .zl .corn. IN A 10.193, ,161.30
On notera que ce cas est un cas de fonctionnement anormal, car le client a pris connaissance de la règle de répartition avant d'interroger le serveur de partition, puisque la règle lui a été communiquée. ANNEΞXE 1
FZl.zone
$TTL 86400 //Ll zl.com. IN SOA local host. root, loca I host { } //L2
zl.com. IN ns nsl //L3 zl.com IN ns nsO //L4
classe type order pref flags service regexp replacement //L5 nsl IN NAPTR 100 50 « a » « » w!Λ[a-m]" nsl-partl.zl.com //L6 nsl IN NAPTR 100 50 « a » « » "!A[n-z]" nsl-part2,zlxom HU
nsl-partl .zl .corn. IN A 10. 193.161.73 //L9 nsl-part2 .zl .com. IN CNAME serveurl //LlO
serveurl IN A 10. 193.161.30 //LU nsO IN A 10, 193.161.30 //L12
ANNEXE 2
FZlbis.zone
$TTL 86400 //Ll zl.com, IN SC localhost.rootlocalhost {} IM
zl.com IN ns nsl IM zl.com IN ns nsO //L4
classe type oorrddeerr pref flags service regexp replacement //LS nsl IN NAPTR 100 50 « a » «D2NS» «iΛ[a-m] insl-partl.zl.com.'» //L6 nsl IN NAPTR 100 50 « a » « » «iΛ[π-z] 'nsl part2 zl.com. ι» IM
nsl-partl.zl.com. IN A 10.193.161.73 //L9 nsl-part2.2l.com. IN CNAME serveurl //LlO
serveurl IN A 10.193.161.30 //LU nsO IN A 10.193.161.30 IMl
ANNEXE 3
FZl-partl.zone
$TTL 86400 //Ll zl.com. IN SOA localhost.root.Iocalhost { //L2
} //L3
zl.com. IN ns nsl //L4
classe type order pref flags service regexp replacement //15 nsl IN NAPTR 100 50 « a » «D2NS» «!A[a-m]>> nsl-partl.2l.com. //L6 nsl IN NAPTR 100 50 « a » «D2NS» «!Λ[n-z]>> nsl-part2.zl.com. IM
nsl-partl.zl .corn. IN A 10. 193.161.73 //19 nsl-part2.zl .com. IN A 10. 193.161.30 //LlO
$ORIGIN zl. corn domainel IN A 10.193.161 .31 //L12 c!omaîne2 ÏN A 10.193.161 .33 //L13

Claims

REVENDICATIONS
1. Serveur (nsl) de domaine (zl.com) dans un réseau (1) de télécommunications adapté à gérer les requêtes DNS relatives audit domaine (zl.com), comportant des moyens (10) pour recevoir, en provenance d'un dispositif client (CLl), une requête visant à obtenir une donnée DIMS (IP(domaine2. zl.com)) de ce domaine, ledit serveur étant caractérisé en ce qu'il comporte : - un fichier de zone comportant au moins une règle de répartition définissant une partition de l'ensemble des sous-domaines (domainel.zl.com, dornaine2.zl.com) dudit domaine (zl.com) en une pluralité de sous-zones, les données DNS de chacune desdites sous-zones étant hébergées par un serveur, dit « serveur de partition », - des moyens (10) pour obtenir, à partir dudit fichier de zone, une information suffisante, pour identifier le serveur de partition adéquat capable de répondre à ladite requête ; et
- des moyens (10) pour envoyer ladite information utile au dispositif client (CLl) en réponse à ladite requête.
2. Serveur selon la revendication 1, caractérisé en ce que ladite information utile comporte au moins un élément parmi :
- ladite au moins une règle de répartition (L6, L7) accompagnée des noms (nsl-partl, nsl-part2) ou des alias (serveurl, serveur2) desdits serveurs de partition,
- Ie nom (nsl-part2) dudit serveur de partition adéquat, et
- un alias (serveur2) dudit serveur de partition adéquat.
3. Serveur seion la revendication 2, caractérisé en ce que ladite information utile comporte en outre l'adresse (10.193.169.73,
10.193.169.30) dudit serveur de partition adéquat.
4. Serveur selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite règle de répartition (L6, L7) est une expression régulière permettant d'obtenir l'adresse dudit serveur de partition adéquat.
5. Fichier informatique susceptible d'être lu par un serveur (nsl) de domaine (zl.corn) dans un réseau (1) de télécommunications, caractérisé en ce qu'il comporte : - des lignes (L6, L7) définissant au moins une règle de répartition de l'ensembie des sous-domaines (domainei.zl.com, domatne2.zl.com) dudit domaine (zl.com) en une pluralité de sous-zones ;
- des lignes (L9, LlO) comportant des identifiants (nsl-partl, nsl-part2) d'une pluralité de serveurs, dits « serveurs de partition », chacun d'entre eux hébergeant les données DNS d'une dite sous-zone.
6. Procédé de gestion des requêtes DNS relatives à un domaine (zl.com) dans un réseau (1) de télécommunications comportant :
-une étape (ElO) de réception, en provenance d'un dispositif client (CLl), d'une requête visant à obtenir une donnée DNS (IP(domaine2.zLcom)) de ce domaine ; ledit procédé étant caractérisé en ce qu'il comporte :
- une étape (E20) de lecture d'un fichier de zone (FZl. zone), ledit fichier comportant au moins une règle de répartition définissant une partition de l'ensemble des sous-domaines (domainel.zl.com, domaine2.zl.com) dudit domaine (zl.com) en une pluralité de sous-zones, ies données DNS de chacune desdites sous-zones étant hébergée par un serveur, dit « serveur de partition »,
- une étape d'obtention (E30, E40), à partir dudit fichier de zone (FZl. zone) d'une information suffisante pour identifier ledit serveur de partition capable de répondre à ladite requête ; et
- une étape (E50) d'envoi de ladite information utile audit dispositif client (CLl) en réponse à ladite requête.
7. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de gestion selon la revendication 6 lorsque ledit programme est exécuté par un ordinateur.
8. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de gestion selon la revendication 6.
9. Système informatique client (CLl) d'un serveur (nsl) de noms de domaine (zl.com) dans un réseau (1) de télécommunications, comportant des moyens pour envoyer audit serveur (nsl) une requête visant à obtenir une donnée DNS (IP(domaine2.zl.com)) de ce domaine, caractérisé en ce qu'il comporte des moyens (20) pour interpréter une expression régulière (L6, L7) reçue en réponse à ladite requête, cette interprétation lui permettant d'obtenir le nom d'un serveur de partition (nsl-partl) capable de répondre à ladite requête.
10. Procédé d'obtention d'une donnée DNS d'un domaine (zl.com) dans un réseau (1) de télécommunications, ce procédé comportant une étape d'envoi d'une requête visant à obtenir ladite donnée, ce procédé étant caractérisé en ce qu'il comporte une étape pour interpréter une expression régulière (L6, L7) reçue en réponse à ladite requête, et pour obtenir, à partir de cette interprétation, le nom d'un serveur de partition (nsl-partl) capable de répondre à ladite requête.
11. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé d'obtention de données selon la revendication 10, lorsque ledit programme est exécuté par un ordinateur.
12. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé d'obtention de données selon la revendication 10.
EP07766024A 2006-05-17 2007-05-10 Serveur et procede pour gerer les noms de domaines dans un reseau Withdrawn EP2052526A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0651792 2006-05-17
PCT/FR2007/051244 WO2007132112A2 (fr) 2006-05-17 2007-05-10 Serveur et procede pour gerer les noms de domaines dans un reseau

Publications (1)

Publication Number Publication Date
EP2052526A2 true EP2052526A2 (fr) 2009-04-29

Family

ID=37709492

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07766024A Withdrawn EP2052526A2 (fr) 2006-05-17 2007-05-10 Serveur et procede pour gerer les noms de domaines dans un reseau

Country Status (4)

Country Link
US (1) US9130990B2 (fr)
EP (1) EP2052526A2 (fr)
CN (1) CN101444072B (fr)
WO (1) WO2007132112A2 (fr)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101841409B (zh) * 2010-01-26 2013-04-24 中国科学院计算机网络信息中心 实现dns区创建同步的方法、服务器以及域名系统
US10565666B2 (en) 2011-09-26 2020-02-18 Verisign, Inc. Protect intellectual property (IP) rights across namespaces
US9992155B2 (en) 2012-03-29 2018-06-05 Hitachi Vantara Corporation DNS alias synchronization in replication topology
WO2013147784A1 (fr) * 2012-03-29 2013-10-03 Hitachi Data Systems Corporation Synchronisation de pseudonymes d'un système de nom de domaine (dns) dans une topologie de duplication
US8935430B2 (en) 2012-06-29 2015-01-13 Verisign, Inc. Secondary service updates into DNS system
CN104253875B (zh) * 2013-06-28 2018-05-22 北京宽广电信高技术发展有限公司 一种dns流量分析方法
JP6184269B2 (ja) * 2013-09-18 2017-08-23 キヤノン株式会社 画像処理システム、情報処理装置、画像処理方法、情報処理方法、及びプログラム
CN103501358B (zh) * 2013-09-18 2016-08-17 北京蓝汛通信技术有限责任公司 一种域名托管管理方法及装置
EP2871819A1 (fr) 2013-11-12 2015-05-13 Verisign, Inc. Opération d'approvisionnement d'objet multiple
US10965616B2 (en) * 2014-10-21 2021-03-30 Unisys Corporation Nonstop computing fabric arrangements
US9906589B2 (en) * 2014-11-14 2018-02-27 Facebook, Inc. Shared management service
WO2017039603A1 (fr) * 2015-08-31 2017-03-09 Hewlett Packard Enterprise Development Lp Classification de domaine
CN110661892B (zh) * 2018-06-28 2022-06-28 贵州白山云科技股份有限公司 一种域名配置信息处理方法及装置
CN115344620B (zh) * 2022-10-19 2023-01-06 成都中科合迅科技有限公司 自定义数据池实现前后端分离后数据按需同步方法

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7188138B1 (en) * 1999-03-22 2007-03-06 Eric Schneider Method, product, and apparatus for resource identifier registration and aftermarket services
US6687746B1 (en) * 1999-08-30 2004-02-03 Ideaflood, Inc. System apparatus and method for hosting and assigning domain names on a wide area network
US7441045B2 (en) * 1999-12-13 2008-10-21 F5 Networks, Inc. Method and system for balancing load distribution on a wide area network
US6976090B2 (en) * 2000-04-20 2005-12-13 Actona Technologies Ltd. Differentiated content and application delivery via internet
US6701329B1 (en) * 2000-09-14 2004-03-02 Microsoft Corporation Aging and scavenging of DNS resource records
US7478148B2 (en) * 2001-01-16 2009-01-13 Akamai Technologies, Inc. Using virtual domain name service (DNS) zones for enterprise content delivery
US20040044791A1 (en) * 2001-05-22 2004-03-04 Pouzzner Daniel G. Internationalized domain name system with iterative conversion
US20030182447A1 (en) * 2001-05-31 2003-09-25 Schilling Frank T. Generic top-level domain re-routing system
US6961783B1 (en) * 2001-12-21 2005-11-01 Networks Associates Technology, Inc. DNS server access control system and method
KR20030065064A (ko) * 2002-01-29 2003-08-06 삼성전자주식회사 도메인 네임 관리 방법
FR2841072A1 (fr) * 2002-06-14 2003-12-19 France Telecom Systeme de consultation et/ou mise a jour de serveurs dns et/ou d'annuaires ldap
KR100496984B1 (ko) * 2002-08-21 2005-06-23 한국전자통신연구원 레이블 분배 프로토콜의 확장을 이용한 ＱｏＳ지원 2계층가상 사설 망 양방향 터널 설정 및 구성정보 분배방법
JP2005539428A (ja) * 2002-09-16 2005-12-22 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ 第一コンピュータ・ネットワークから第二コンピュータ・ネットワークへの通信セッションの始動
US7426576B1 (en) * 2002-09-20 2008-09-16 Network Appliance, Inc. Highly available DNS resolver and method for use of the same
US20080288470A1 (en) * 2004-10-06 2008-11-20 France Telecom Method and System for Distributed Dns Resolution
US7680955B2 (en) * 2004-12-01 2010-03-16 George Mason Intellectual Properties, Inc. SCIT-DNS: critical infrastructure protection through secure DNS server dynamic updates
US7904520B2 (en) * 2005-06-09 2011-03-08 Trueffect, Inc. First party advertisement serving
US20070043829A1 (en) * 2005-08-17 2007-02-22 Robin Dua Method and system for accessing a storage or computing device via the Internet
WO2007074286A1 (fr) * 2005-12-27 2007-07-05 France Telecom Serveur et procede pour gerer des requetes dnssec
JP5032582B2 (ja) * 2006-11-16 2012-09-26 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ゲートウェイ選択機構

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"DNS sub domain", 24 March 2006 (2006-03-24), pages 1 - 3, XP055033661, Retrieved from the Internet <URL:http://forums.devshed.com/dns-36/dns-sub-domain-337205.html> [retrieved on 20120724] *

Also Published As

Publication number Publication date
WO2007132112A2 (fr) 2007-11-22
WO2007132112A3 (fr) 2008-01-03
US20090113075A1 (en) 2009-04-30
CN101444072A (zh) 2009-05-27
US9130990B2 (en) 2015-09-08
CN101444072B (zh) 2013-03-20

Similar Documents

Publication Publication Date Title
EP2052526A2 (fr) Serveur et procede pour gerer les noms de domaines dans un reseau
EP1974522B1 (fr) Serveur, client et procédé pour gérer des requetes DNSSEC
US9659070B2 (en) Methods, systems, products, and devices for processing DNS friendly identifiers
US7565407B1 (en) Network proxy apparatus and methods
EP2000929B1 (fr) Utilisation d&#39;un arbre de hachage à préfixes (PHT) pour la localisation des services au sein d&#39;un réseau de communication poste-à-poste
US20080235383A1 (en) Methods, Systems, Products, And Devices For Generating And Processing DNS Friendly Identifiers
WO2006037865A1 (fr) Procede et systeme de resolution dns distribuee
EP1641223B1 (fr) Procédé perfectionné d&#39;attribution d&#39;identifiants de réseau, au moyen d&#39;identifiants d&#39;interfaces
FR2908540A1 (fr) Deploiement de bases dnssec
WO2019063907A2 (fr) Procédé et dispositif de traitement d&#39;une requête d&#39;instanciation d&#39;un service réseau
EP1142269B1 (fr) Procede d&#39;adressage et serveur de noms et d&#39;adresses dans un reseau numerique
WO2019074546A1 (fr) Transfert d&#39;informations dans un nom d&#39;hôte dans un réseau de distribution de contenu (cdn)
WO2014072665A1 (fr) Procédé de résolution d&#39;un numéro de téléphone porté en un identifiant de ressource réseau
FR3023098A1 (fr) Procede et systeme de traitement d&#39;une demande de resolution d&#39;un nom d&#39;un serveur, emise par une application cliente sur un reseau de communication.
CA2433216A1 (fr) Serveur d&#39;annuaire reparti
Pöhlsen et al. Integrating a decentralized web service discovery system into the internet infrastructure
EP1695523A1 (fr) Procede et dispositif d emission de requetes vers un serveur de noms de domaine depuis une machine requerante
FR3053562A1 (fr) Procede de synchronisation dans un reseau mobile
EP2293521B1 (fr) Procédé de geolocalisation IP dans un réseau d&#39;entreprise
WO2013140097A1 (fr) Selection d&#39;une entite de reseau pour la fourniture d&#39;un contenu numerique
CN116627925A (zh) 一种基于k8s环境的业务日志数据处理方法及装置
WO2007138228A2 (fr) Procede, dispositif et systeme de nommage, procede et terminal d&#39;acces a une ressource, procede de reponse a une interrogation et serveur de resolution
FR2961984A1 (fr) Synchronisation de liste des utilisateurs dans un reseau p2p
WO2009071836A1 (fr) Procédé de gestion de l&#39;interface utilisateur d&#39;un terminal mobile associé à un module de sécurité et terminal mobile associé
WO2000042526A1 (fr) Interfonctionnement et systeme de caches cooperants et caches repartis

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20081114

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20100329

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20180126

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180606