WO2005032096A1 - Module et procede de transmission de messages a un serveur de noms de domaine et architecture ayant le module - Google Patents

Module et procede de transmission de messages a un serveur de noms de domaine et architecture ayant le module Download PDF

Info

Publication number
WO2005032096A1
WO2005032096A1 PCT/FR2004/002335 FR2004002335W WO2005032096A1 WO 2005032096 A1 WO2005032096 A1 WO 2005032096A1 FR 2004002335 W FR2004002335 W FR 2004002335W WO 2005032096 A1 WO2005032096 A1 WO 2005032096A1
Authority
WO
WIPO (PCT)
Prior art keywords
messages
value
filtering
server
domain name
Prior art date
Application number
PCT/FR2004/002335
Other languages
English (en)
Inventor
David Dugoujon
Gilles Lecorgne
Daniel Migault
Original Assignee
France Telecom
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 filed Critical France Telecom
Publication of WO2005032096A1 publication Critical patent/WO2005032096A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • 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]

Definitions

  • the invention relates to a module and a method for transmitting messages to a domain name server, as well as a hierarchical architecture of name servers.
  • domain One possibility of applying the invention relates to hierarchical architectures of domain name servers using telephone dialing.
  • one or more domain name server (s) is provided.
  • Each domain name server has records in memory, associated with the names and zones that it manages, and / or references to other domain name servers, for the names and zones that it does not manage .
  • domain name servers are open to everyone, in particular due to the development of the Internet network which is supposed to allow access to information for everyone. Therefore, any requester can obtain the records from any domain name server by submitting a request, which requests the contents of the associated records in memory at the name (address) specified in the request.
  • the invention aims to obtain a module and a method for transmitting messages to a domain name server, as well as a hierarchical architecture of domain name servers, overcoming the drawbacks of the prior art and making it possible to improve the security of domain name servers both in relation to potential fraud committed against the applicant and from the point of view of the privacy of the persons corresponding to the names.
  • a first object of the invention is a module for transmitting messages between one and the other of a requester of a domain name server and of said domain name server, the messages containing at at least one NAPTR resource record having a service field, characterized in that the transmission module comprises: - at least a first message transmission channel of at least a first message admission entry from the requestor to at at least a first output for delivering messages to the domain name server, - at least a second channel for transmitting messages from at least a second message admission input from the domain name server to at least a second output for supply of messages to the requester, and - interposed between the input and the output of at least one determined channel among the first and second transmission channels, means for receiving messages from the input of said determined channel, means of extraction of the value of the service field in the messages received and means for filtering the messages of said input from said channel determined as a function of the value extracted from the service field, present in said messages received, and of at least one service fields filtering value, present in a filtering base
  • a second object of the invention is a hierarchical architecture of domain name servers, comprising at least a first domain name server, a module for transmission, as described above, of messages between a requester and said first domain name server, and a second domain name server, parent of the first domain name server and arranged to refer to said first name server domain by the address of the transmission module.
  • a third object of the invention is a method of transmitting messages between one and the other of a requester of a domain name server and of said domain name server, the messages containing at least one registration of resource
  • NAPTR having a service field, characterized in that one receives the messages originating from the requester and intended for the domain name server, respectively the messages originating from the domain name server and intended for the applicant, and one performs a filtering of messages to the recipient according to the value of the service field present in said messages and of service field filter values, present in a filtering base, said service field filter value being one of at least one authorized value of service fields and at least one unauthorized value of service fields, the filtering being carried out so that the filtered messages do not contain a NAPTR resource record having a service field value not corresponding to the filtering value, when this filtering value is an authorized value of service fields, and does not contain a resource record NAPTR having a value of service field corresponding to the filtering value, when this filtering value is an unauthorized value of service fields.
  • the at least one NAPTR resource record having a service field is for example according to document RFC 3403 of the IETF working group.
  • the invention will be better understood on reading the description which follows, given solely by way of nonlimiting example with reference to the appended drawings, in which: - Figure 1 schematically shows an architecture of domain name servers comprising a transmission module according to the invention and a platform for interrogating it, - Figure 2 schematically shows an example of the content of the memory of a domain name server in Figure 1, and - Figure 3 shows schematically an example of the content of the filtering base of the transmission module of FIGS. 1 and 2.
  • the invention is described by way of example in the following with reference to an architecture A of hierarchical servers of telephone number domain names.
  • each domain name server 3 is associated with one or more memories, being part of or distant from the server 3 as shown in FIG. 1, these memories being designated by the generic term from memory 4 in the following.
  • Each memory 4 comprises recordings ENR of information I at determined names (or addresses) ADR. For example, in the name ADR1 are recorded the information Ma, 11b, 11c, in the name ADR2 the information I2a, in the name ADR3 the information I3a, in the name ADR4 the information I4a and I4b, in the name ADRj the information Ij and in the name ADRn the information I2n.
  • the names in the domain name servers 3 use the telephone numbers of the users according to the ENUM protocol of the working group on mapping with telephone numbers (Telephone Number Mapping Working Group) defined in the IETF working group (Internet engineering task force) according to document RFC2916, to which reference is made here, RFC meaning in English "Request For Comments" and being reference publications on the Internet.
  • E.164 number and domain name servers E.164 Number and DNS
  • country code for example + 33-2 -96053538 for a telephone number of a user in France
  • dots between the numbers we insert dots between the numbers, we reverse the order of the numbers and we add the string "e.164.arpa" at the end figures, to obtain the number E164 as an ADR domain name in architecture, i.e. 8.3.5.3.5.0.6.9.2.3.3.e164.arpa in the previous example illustrated in Figures 1, 2 and 3.
  • the number E164 is associated in the memory 4 associated with said domain name server 3 a number of NAPTR resource records (for naming authority pointer resource record or Naming Authority Pointer Resource Record) according to the document of the IETF working group RFC2915, rendered obsolete by the document RFC3403, to which reference is made here.
  • the NAPTR record has, according to part 4 of the IETF document RFC3403, a DNS type code equal to 35 for the TYPE field of the resource record format according to paragraph 3.2.1 of the IETF document RFC1035.
  • the NAPTR record thus has the following format: ORDER, PREFERENCE, FLAGS, SERVICES, REGEXP, REPLACEMENT.
  • the REGEXP field contains the information I proper, namely for example information I of the user, such as information I to reach the user, such as for example sip: dupont@ft.com, mailto: dupont ( ⁇ ) ft.com, http://www.example.fr, which are in this example other information to reach Mr. Dupont having the telephone number + 33-2-96053538.
  • the SERVICES field hereinafter called the service field, is a character string which specifies the applicable service parameters and depends on the specifications of the application. Thus, in this example, the ENR records associated with this domain name will be: $ ORIGIN 8.3.5.3.5.0.6.9.2.3.3.e164.arpa IN NAPTR 10 10 "u""E2U + sip""!
  • a first server 1 (called TierO) of domain names manages a world root of addresses in “e.164.arpa”, of second servers 2, 2a (called Tierl) of domain names to which the first server 1 returns each manages a country code (for example 4.6.e164.arpa for Sweden, 3.3.e164.arpa for metropolitan France), and third servers 3, 3a, 3b (called Tier2) domain names then constitute the servers 3 of the aforementioned domain names, each managing their associated zone of domain names.
  • the references are symbolized by dashed lines.
  • Each server 2, 2a of domain names refers to one or several servers 3, 3a, 3b of domain names, which are not referred e not the other servers 2, 2a.
  • the server 1 is said to be the parent of the servers 2, 2a, themselves parents of the servers 3, 3a to which they refer.
  • Each server 3, 3a, 3b manages the zone associated with E164 numbers.
  • the domain name server 2a 3.3.e164.arpa refers to several domain name servers 3a, 3b.
  • the domain name server 3a manages for example a certain number of addresses in 3.3.e164.arpa, comprising for example the address 8.3.5.3.5.0.6.9.2.3.3.e164.arpa and is associated with memory 4 of figure 2.
  • the server 3a manages the zone ending with 5.0.6.9.2.3.3.e164.arpa
  • the 3b server manages an area ending in 6.0.6.9.2.3.3.e164.arpa.
  • a machine H wishing to obtain information I present in an ENR record of architecture A sends to an ASP platform, which may for example be that of a service provider, a request making it possible to determine the ADR name of this record REC.
  • This ASP platform has for example a client-server architecture and includes an access 10 for receiving requests from the outside and emitted by H machines and a resolution module 11 (resolver) for processing requests received on the access 10.
  • the resolution module 11 is a client of a local domain name server 12 connected to the module 11 and is able to send signals to the local domain name server 12 connected to the module 11. interrogation corresponding to the request received on the access 10.
  • the local domain name server 12 is able to send, as a function of the interrogation signals, request messages R in information I to the architecture of name servers of field as follows.
  • R request messages include the ADR name of the domain to be queried in the architecture to obtain the desired ENR record.
  • the request message R comprising the name ADR is sent first in step E1 to the server 1, which then returns in step E2 a first response message to the local server 12, indicating a reference to the corresponding server 2 , selected by this ADR address, that is to say in the previous example the server 2a.
  • the local server 12 then sends during step E3 the request message R comprising the ADR name to server 2 selected and indicated in the first response message, that is to say in the previous example to server 2a, which server 2a then sends, during step E4, a second response message to local server 12, indicating a reference to the corresponding server 3, selected by this name ADR, that is to say in the previous example the server 3a.
  • the local server 12 then sends during step E5 the request message R comprising the name ADR to the server 3 of domain names selected and indicated in the second response message, on its input 21 for receiving request messages from the outside, that is to say in the previous example at the input 21 of the server 3a.
  • Each server 3, 3a, 3b comprises at least one input 5 for admitting request messages R.
  • the request messages R can for example be requests for reading information I with the name ADR or requests for writing information I in the name ADR.
  • a read request message with the name ADR arrives at the admission entry 5
  • the record ENR of the information I present at this address ADR is read in the associated memory 4 (for example the information 12a is read for address AD.R2).
  • the server 3, 3a, 3b has a first output 6 for supplying a response message to the request R for reading present on its input 5.
  • This response message contains the information I read in the associated memory 4 and the records NAPTR read with the name specified in the read request message R, like those indicated in the example mentioned above.
  • 3b of domain names is interposed a message transmission module 7, through which messages sent to this server (s) 3, 3a, 3b must pass from a requestor, formed in the example described above by the local server 12 having sent the request message R, and the messages sent by this server 3, 3a, 3b to the requester.
  • the transmission module 7 has as address, in the architecture A of the servers, the return address to the server 3a with which it is associated.
  • this transmission module 7 comprises a first channel 8 for transmitting messages from a first input 21 for admitting the applicant's messages to a first output 50 for delivering messages to the server 3a of domain names connected to the input 5 for admitting said messages from the server 3a, a second channel 9 for transmitting messages from a second input 60 for admitting messages from the server of domain names 3a, connected to the output 6 for supplying said messages from the server 3a, to a second output 25 for supplying messages to the requester.
  • a first module 20 for controlling messages from the requester and / or a second module 26 for controlling messages from the server 3a are provided in the transmission module 7 for the domain name server 3a.
  • the first module 20 for controlling messages from the requestor is interposed on the first transmission channel 8 between the first input 21 for admitting messages from the requester and the first output 50 for delivering messages to the server 3a.
  • the second module 26 for controlling messages from the server 3a is interposed on the second transmission channel 9 between the second input 60 for admitting messages from the server 3a and the second output 25 for delivering messages to the requester.
  • the first module 20 for controlling messages from the requester comprises first means 22 for receiving the messages present on its input 21 for admitting messages from the requester and for analyzing these messages, and first means 24 for filtering messages.
  • the first automatically detect analysis means 22 for example by the presence in the message of a read signal (OPCODE field positioned at 0 in the message according to the document IETF RFC 1035 and RFC 2136)
  • this is transmitted directly, except for possible control of additional access as will be explained below, by the first filtering means 24 at the first output 50 and at the input 5 for admitting messages from the server 3a.
  • Associated 3a comprises second means 27 for receiving the messages present on its input 60 for admitting messages from the output 6 for supplying the server 3a, and for analyzing these messages, and second means 28 for filtering messages.
  • the transmission module 7 further comprises a filtering base 23 containing one or more first values DF for filtering service fields, associated with the first filtering means 24, and one or more second values DF for filtering service fields, associated to the second filter means 28.
  • the message transmitted by the server 3a to its supply output 6 is a message RR in response to this request request message R for reading, which contains the NAPTR records read.
  • the means 27 analyze this response RR message to extract the service fields from the NAPTR records it contains.
  • the second filtering means 28 compare each service field extracted from the response RR message with the second service value (s) DF of the service base 23.
  • the service field filtering DF values can be find one or more authorized values of service fields, for example in the previous example "mailto" and "http" for the second filtering values DF, and / or one or more authorized values of service fields. If it is determined by the second filtering means 28 that the service field extracted from the response RR message corresponds to a second authorized service field value or does not correspond to any second unauthorized service field value service, the NAPTR record containing this service field is kept in the response RR message transmitted to the second output 25 for supplying the message to the requester 12.
  • the second filtering means 28 If it is determined by the second filtering means 28 that the service field extracted of the 5 response RR message corresponds to a second unauthorized service field value or does not correspond to any second authorized service field value, the NAPTR record containing this service field is deleted in the response RR message transmitted to the second output 25 for supplying the message to the requester 12.
  • the requester 12 does not therefore receive in the RR response messages transmitted by the module 7 the NAPTR records with an unauthorized service field, which are eliminated therefrom by the module 26.
  • the module 7 of transmission therefore filters the content of response RR messages from server 3a to requester 12.
  • le5 RR message of r response filtered on output 25 will therefore be: 8.3.5.3.5.0.6.9.2.3.3.e164.arpa: type NAPTR, class inet Name: 8.3.5.3.5.0.6.9.2.3.3.e164.arpa Type: Naming authority pointer Class: inet 0 Time to live: 30 seconds Data length: 48 Data: 10 20 "u""E2U + mail""! ⁇ . * $! mailto: dupont (5 ) ft.com! "
  • a NAPTR record from the server 3a can only reach the output 25 towards the outside and, during the step E6 subsequent to the step E5, to the local server 12 only by having crossed the second module 26 successfully, the output 6 for supplying response messages from the server 3a being masked by this second module 26 for the server 12.
  • the request message sent by the requesting local server 12 can also be a request message W in writing information I in the domain name server 3a into at least one ADR name specified therein and managed by this server 3a.
  • a write request message W therefore comprises one or more NAPTR records, which are those to be written with the name specified in this message in the memory 4 associated with the server 3a recipient of the message.
  • This write request message W is then sent to the first request admission input 21, to be received and analyzed by the means 22 of the transmission module 7.
  • the analysis means 22 When the message present on input 21 is a write request message W, which is automatically detected by the analysis means 22 for example by the presence in the message of a write signal (OPCODE field positioned at 5 in the message according to the document IETF RFC 1035 and RFC 2136), the analysis means 22 automatically extract the service fields from the NAPTR records it contains.
  • the first filtering means 24 compare each service field extracted from the write request message W with the first service value (s) DF for the service field filter 23.
  • the NAPTR record containing this service field is kept in the write request message W transmitted to the first output 50 for supplying the message to the server 3a. If it is determined by the first filtering means 24 that the service field extracted from the message of W write request corresponds to a first unauthorized service field value or does not correspond to any first authorized service field value, the NAPTR record containing this service field is deleted in the W write request message transmitted to the first output 50 for supplying the message to the server 3a.
  • the server 3a therefore does not receive in the write messages W transmitted by the module 7 the NAPTR records with an unauthorized service field, which are eliminated therefrom by the module 20.
  • the transmission module 7 therefore filters the content of the messages W in writing from requester 12 to server 3a.
  • a second unauthorized value of service fields is "mail” and if a second authorized value of service fields is "http”
  • requester 12 will not be able to write the NAPTR 10 record 20 "u "" E2U + mail ""! ⁇ . * $! Mailto: durand ( ⁇ , ft.com! "But can write the NAPTR 10 record 20" u "" E2U + http ""! ⁇ . * $!
  • the service field filtering DF value (s) are valid for all messages, for example and all the names managed by the server 3a
  • the first and / or second values DF of filtering of the base 23 are associated in addition with values DC of access control, associated with means Corresponding access control CAs, combined with the first and / or second filtering means 24, 28, as shown in parentheses in FIG. 1.
  • the DC access control values are parameters present in messages. Therefore, message content filtering is then performed based also on other message parameters, as explained below.
  • the means 22 extract in addition to the message that they have received the parameters corresponding to these DC values.
  • the filtering means 24 compare these extracted parameters and the extracted service field with the combination or combinations associated values DF and DC of the base 23, to determine whether the received message includes such a combination. If so, the message present on the first admission intake 21 of the applicant is transmitted, filtered by its field of service as has been described above, to the first output 50 of supply to the server 3a on its input 5. If not, the message present on the first input 21 of the applicant's admission is not transmitted to the first output 50 of supply to the server 3a on its input 5.
  • DC access control values that base 23 can contain are as follows, as shown in FIG. 3: - one or more of an IP address of a local name server (local DNS) domain, analogous to the server 12 of the ASP platform, these local servers transmitting the request messages R in read and / or request W in write containing this IP address of local server. IP addresses of multiple local servers can be included in the DC access control data.
  • local DNS local name server
  • the access control performed by the first module 20 does not transmit to input 5 the R and / or W request messages originating from local servers whose IP address is absent from the base 23 but does not allow the transmission to input 5 of R and / or W request messages originating from local servers having an IP address identified as such in the base 23. - one or more ADR name (s) managed by the name server 3a field.
  • the access control performed by the first module 20 does not transmit to the input 5 the request messages R for reading and / or the request W for writing on a name absent from the base 23 but does not allow the transmission to input 5 only of request messages R for reading and / or request W for writing containing an ADR name identified as such in the base 23.
  • the access control performed by the first module 20 does not transmit to input 5 the request messages R for reading and / or the request W for writing concerning a name absent from the name fields of the base 23 but only allows the transmission to input 5 of request messages R for reading and or request W for writing containing an ADR name belonging to a zone of the base 23.
  • the filtering DF values and the access control DC values recorded in the base 23 can be modified by a managing authority of the server 3a.
  • a request message R from this same local server 12 but which would query the name 8.3.5.3.5.0.7.9.2.3.3. e164. arpa would not be transmitted to server 3a, since the ADR * .6.9.2.3.3.e164.arpa names field associated with the IP address of this server 12 in the DF data for this 3a system does not contain the name 8.3.5.3.5.0.7.9.2.3.3.e164.arpa.
  • the service fields can be filtered by the transmission module 7 according to the requesters 12 or local servers 12, which can be different service providers to which subscribes the people using H machines, this selective filtering being carried out thanks in addition to the DC access control values associated with the filtering values.
  • the access control DC values comprise for the first module 20, in addition to one or more of the data described above, also action data indicating the writing and / or reading to authorize the transmission of messages of requests R in reading and requests W in writing.
  • Action data positioned on read in association with the other values DF, DC means that all the request messages R in read checking the other values DF, DC will be transmitted from the first input 21 to the input 5 of the server 3a.
  • Action data positioned on write in association with the other values DF, DC means that all the request messages W in write checking the other values DF, DC will be transmitted from the first input 21 to input 5 of the server 3a.
  • the access control DC values can also include a key shared between the ASP platform and the domain name server 3a, this shared key using a non-invertible hashing function to authenticate the messages.
  • This shared key is used to sign the message by adding a transaction signature such as TSIG according to the IETF document RFC2845.
  • the signature makes it possible to prove that the sender and the recipient of the message share the same key and that the message has not been modified since it was sent.
  • This signature is used for the messages of requests R in reading and requests W in writing.
  • a trust relationship must be established between the domain name server 3a and the ASP platform for sharing the key.
  • the local server 12 must be able to know how to add the key when it sends a request message to the server 3a.
  • the transmission module 7 comprises for example means for, in the case where the access control means CA associated with the first and / or second filtering means 24, 28, refuse a message access to the first output 50 and at the inlet 5 for admission and / or at the second outlet 25, return towards the outside during step E6 subsequent to step E5, on a corresponding outlet, for example 25, at the transmitter 12 of this message a response containing a corresponding error code.
  • the transmission module also comprises, for example, means for, in the absence of NAPTR registration in the write request message W filtered on the first output 50 for supplying messages to the domain name server 3a, while one or more NAPTR records were present in the unfiltered write request W message on the first input 21, returning to the second output 25 for providing the requester with a response containing a corresponding error code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Suivant l'invention, le module de transmission de messages comporte, interposés entre l'entrée et la sortie d'au moins une voie déterminée (8, 9) de transmission, des moyens (20, 26) de réception des messages depuis l'entrée (21, 6), des moyens d'extraction de la valeur du champ de service dans les messages reçus et des moyens (24, 28) de filtrage des messages de l'entrée (21, 6) en fonction de la valeur extraite du champ de service, présente dans les messages reçus, et d'une valeur (DF) de filtrage de champs de service, présente dans une base (23) de filtrage associée aux moyens (20, 26) de filtrage.

Description

Module et procédé de transmission de messages à un serveur de noms de domaine et architecture ayant le module L'invention concerne un module et un procédé de transmission de messages à un serveur de noms de domaine, ainsi qu'une architecture hiérarchisée de serveurs de noms de domaine. Une possibilité d'application de l'invention concerne les architectures hiérarchisées de serveurs de noms de domaine utilisant la numérotation téléphonique. Dans ce type d'architecture est prévu un ou plusieurs serveur(s) de noms de domaine. Chaque serveur de noms de domaine comporte des enregistrements en mémoire, associés aux noms et aux zones qu'il gère, et/ou des références à d'autres serveurs de noms de domaine, pour les noms et les zones qu'il ne gère pas. Dans les réalisations actuelles, les serveurs de noms de domaine sont ouverts à tous, notamment en raison du développement du réseau Internet censé permettre l'accès à tous à de l'information. Par conséquent, n'importe quel requérant peut obtenir les enregistrements de n'importe quel serveur de noms de domaine en lui présentant une requête, qui demande le contenu des enregistrements associés en mémoire au nom (adresse) spécifié dans la requête. L'ouvrage intitulé « DNS et BIND » de Paul Albitz et Cricket Liu,
ISBN 2-84177-150-4 décrit au chapitre 11 , page 289, de sécuriser les serveurs de noms de domaines, en appliquant des restrictions aux requêtes par un contrôle d'accès basé sur les adresses IP de l'origine des requêtes et sur les zones du domaine, visées par les requêtes. Ainsi, cette sécurisation permet théoriquement d'empêcher qu'un fraudeur accède aux enregistrements du serveur de noms de domaine, dans la mesure où l'adresse IP, à partir de laquelle il émettra sa requête, ne correspondra pas à la liste d'accès prévue dans le contrôle d'accès. Toutefois, rien n'empêche que le fraudeur accède quand même à l'ensemble des enregistrements du serveur de noms de domaine, si il s'introduit en fraude sur un serveur local requérant d'adresse IP autorisée dans la liste d'accès et émet à partir de celui-ci des requêtes. En effet, dans ce cas, ces requêtes auront l'adresse IP d'origine autorisée dans la liste d'accès et passeront donc avec succès le contrôle d'accès. A l'inverse, si l'on se place du côté des utilisateurs correspondants aux noms du domaine géré par le serveur destinataire des requêtes, ceux- ci peuvent souhaiter que certaines informations privatives associées à leur nom ne soient pas rendues accessibles, et ce même à des requérants autorisés à accéder à d'autres informations enregistrées à leur nom. Compte tenu du caractère privatif de ces informations enregistrées dans le serveur de noms de domaine, leur obtention publique présente des inconvénients non seulement pour l'utilisateur concerné, mais également pour le propriétaire du serveur de noms de domaine, qui ne peut pas garantir l'usage qui sera fait des informations obtenues. L'invention vise à obtenir un module et un procédé de transmission de messages à un serveur de noms de domaine, ainsi qu'une architecture hiérarchisée de serveurs de noms de domaine, palliant les inconvénients de l'état de la technique et permettant d'améliorer la sécurité des serveurs de noms de domaine aussi bien vis-à-vis de potentielles fraudes commises à l'égard du requérant que du point de vue de la vie privée des personnes correspondant aux noms. A cet effet, un premier objet de l'invention est un module de transmission de messages entre l'un et l'autre d'un requérant d'un serveur de noms de domaine et dudit serveur de noms de domaine, les messages contenant au moins un enregistrement de ressource NAPTR ayant un champ de service, caractérisé en ce que le module de transmission comporte : - au moins une première voie de transmission de messages d'au moins une première entrée d'admission de messages du requérant à au moins une première sortie de fourniture de messages au serveur de noms de domaine, - au moins une deuxième voie de transmission de messages d'au moins une deuxième entrée d'admission de messages du serveur de noms de domaine à au moins une deuxième sortie de fourniture de messages au requérant, et - interposés entre l'entrée et la sortie d'au moins une voie déterminée parmi les première et deuxième voies de transmission, des moyens de réception des messages depuis l'entrée de ladite voie déterminée, des moyens d'extraction de la valeur du champ de service dans les messages reçus et des moyens de filtrage des messages de ladite entrée de ladite voie déterminée en fonction de la valeur extraite du champ de service, présente dans lesdits messages reçus, et d'au moins une valeur de filtrage de champs de service, présente dans une base de filtrage associée aux moyens de filtrage, ladite valeur de filtrage de champs de service étant l'une parmi au moins une valeur autorisée de champs de service et au moins une valeur non autorisée de champs de service, les moyens de filtrage étant aptes à ce que les messages transmis à ladite sortie de ladite voie déterminée ne contiennent pas d'enregistrement de ressource NAPTR ayant une valeur de champ de service ne correspondant pas à la valeur de filtrage, lorsque cette valeur de filtrage est une valeur autorisée de champs de service, et ne contiennent pas d'enregistrement de ressource NAPTR ayant une valeur de champ de service correspondant à la valeur de filtrage, lorsque cette valeur de filtrage est une valeur non autorisée de champs de service. Grâce à l'invention, seuls les enregistrements NAPTR correspondant à des services autorisés sont transmis dans les messages. Il est ainsi garanti que le secret des données privées des utilisateurs sur les serveurs de noms de domaines ne sera pas violé. Une sécurité supplémentaire est ainsi également apportée contre les fraudes liées aux accès illicites aux enregistrements. D'autres caractéristiques de l'invention font l'objet des revendications 2 à 14. Un deuxième objet de l'invention est une architecture hiérarchisée de serveurs de noms de domaine, comportant au moins un premier serveur de noms de domaine, un module de transmission, tel que décrit ci-dessus, de messages entre un requérant et ledit premier serveur de noms de domaine, et un deuxième serveur de noms de domaine, parent du premier serveur de noms de domaine et agencé pour faire référence audit premier serveur de noms de domaine par l'adresse du module de transmission. Un troisième objet de l'invention est un procédé de transmission de messages entre l'un et l'autre d'un requérant d'un serveur de noms de domaine et dudit serveur de noms de domaine, les messages contenant au moins un enregistrement de ressource
NAPTR ayant un champ de service, caractérisé en ce que l'on reçoit les messages provenant du requérant et à destination du serveur de noms de domaine, respectivement les messages provenant du serveur de noms de domaine et à destination du requérant, et l'on exécute un filtrage des messages au destinataire en fonction de la valeur du champ de service présente dans lesdits messages et de valeurs de filtrage de champs de service, présentes dans une base de filtrage, ladite valeur de filtrage de champs de service étant l'une parmi au moins une valeur autorisée de champs de service et au moins une valeur non autorisée de champs de service, le filtrage étant effectué de manière à ce que les messages filtrés ne contiennent pas d'enregistrement de ressource NAPTR ayant une valeur de champ de service ne correspondant pas à la valeur de filtrage, lorsque cette valeur de filtrage est une valeur autorisée de champs de service, et ne contiennent pas d'enregistrement de ressource NAPTR ayant une valeur de champ de service correspondant à la valeur de filtrage, lorsque cette valeur de filtrage est une valeur non autorisée de champs de service. Le au moins un enregistrement de ressource NAPTR ayant un champ de service est par exemple selon le document RFC 3403 du groupe de travail IETF. L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple non limitatif en référence aux dessins annexés, sur lesquels : - la figure 1 représente schématiquement une architecture de serveurs de noms de domaine comportant un module de transmission suivant l'invention et une plate-forme pour l'interroger, - la figure 2 représente schématiquement un exemple du contenu de la mémoire d'un serveur de noms de domaine de la figure 1 , et - la figure 3 représente schématiquement un exemple du contenu de la base de filtrage du module de transmission des figures 1 et 2. L'invention est décrite à titre d'exemple dans ce qui suit en référence à une architecture A de serveurs hiérarchisés de noms de domaine de numérotation téléphonique. Bien entendu, l'invention est également applicable à tout autre type de serveurs de noms de domaine. Ainsi que cela est représenté aux figures 1 et 2, chaque serveur 3 de noms de domaine est associé à une ou plusieurs mémoires, en faisant partie ou distantes du serveur 3 ainsi que représenté à la figure 1 , ces mémoires étant désignées par le terme générique de mémoire 4 dans ce qui suit. Chaque mémoire 4 comporte des enregistrements ENR d'informations I à des noms (ou adresses) ADR déterminées. Par exemple, au nom ADR1 sont enregistrées les informations Ma, 11 b, 11c, au nom ADR2 l'information I2a, au nom ADR3 l'information I3a, au nom ADR4 les informations I4a et I4b, au nom ADRj l'information Ij et au nom ADRn l'information I2n. Dans le cas d'un domaine de numérotation téléphonique, les noms dans les serveurs 3 de noms de domaine utilisent les numéros de téléphone des utilisateurs selon le protocole ENUM du groupe de travail sur la mise en correspondance avec des numéros de téléphone (Téléphone Number Mapping Working Group) défini au groupe de travail IETF (groupe de travail sur le réseau Internet, ou Internet Engineering Task Force) selon le document RFC2916, auquel il est fait référence ici, RFC signifiant en anglais « Request For Comments » et étant des publications de référence portant sur le réseau Internet. Selon ce document, intitulé « numéro E.164 et serveurs de noms de domaine » (E.164 Number and DNS), on enlève du numéro de téléphone d'un utilisateur, qui comprend le code du pays (par exemple +33-2-96053538 pour un numéro de téléphone d'un utilisateur en France) tous les caractères non numériques, on intercale des points entre les chiffres, on inverse l'ordre des chiffres et on ajoute la chaîne « e.164.arpa » à la fin des chiffres, pour obtenir le numéro E164 comme nom de domaine ADR dans l'architecture, c'est-à-dire 8.3.5.3.5.0.6.9.2.3.3.e164.arpa dans l'exemple précédent illustré aux figures 1 , 2 et 3. Au numéro E164 sont associés dans la mémoire 4 associée audit serveur 3 de noms de domaine un certain nombre d'enregistrements de ressource NAPTR (pour enregistrement de ressource de pointeur d'autorité de nommage ou Naming Authority Pointer Ressource Record) selon le document du groupe de travail IETF RFC2915, rendu caduc par le document RFC3403, auxquels il est fait référence ici. L'enregistrement NAPTR a, selon la partie 4 du document IETF RFC3403, un code de type de DNS égal à 35 pour le champ TYPE du format d'enregistrement de ressource selon le paragraphe 3.2.1 du document IETF RFC1035. L'enregistrement NAPTR a ainsi le format suivant : ORDRE, PREFERENCE, DRAPEAUX (FLAGS), SERVICES, REGEXP, REPLACEMENT. Le champ REGEXP contient les informations I proprement dites, à savoir par exemple des informations I de l'utilisateur, telles que des informations I pour joindre l'utilisateur, comme par exemple sip:dupont@ft.com, mailto:dupont(α)ft.com, http://www.exemple.fr, qui sont dans cet exemple d'autres informations pour joindre Monsieur Dupont ayant le numéro de téléphone +33-2-96053538. Le champ SERVICES, appelé ci-dessous champ de service, est une chaîne de caractères qui spécifie les paramètres de service applicables et dépend des spécifications de l'application. Ainsi, dans cet exemple, les enregistrements ENR associés à ce nom de domaine seront : $ORIGIN 8.3.5.3.5.0.6.9.2.3.3.e164.arpa IN NAPTR 10 10 "u" "E2U+sip" "!Λ.*$!sip:dupont@ft.com !" IN NAPTR 10 20 "u" Ε2U+mailto" "!Λ.*$!mailto:dupont@ft.com!" IN NAPTR 10 20 "u" "E2U+http" "!Λ.*$!http://www.exemple.fr!" En outre, selon le document IETF RFC1035, le principe de délégation de l'architecture ENUM dans le contexte de la gestion de la numérotation E164 définit en outre plusieurs niveaux de responsabilité en arborescence en ce sens qu'un premier serveur 1 (dénommé TierO) de noms de domaine gère une racine mondiale d'adresses en « e.164.arpa », des deuxièmes serveurs 2, 2a (dénommés Tierl) de noms de domaine auxquels le premier serveur 1 renvoie gèrent chacun un code de pays (par exemple 4.6.e164.arpa pour la Suède, 3.3.e164.arpa pour la France métropolitaine), et des troisièmes serveurs 3, 3a, 3b (dénommés Tier2) de noms de domaine constituent alors les serveurs 3 de noms de domaine précités, gérant chacun leur zone associée de noms de domaine. A la figure 1 , les renvois sont symbolisés par des traits interrompus. Chaque serveur 2, 2a de noms de domaine renvoie à un ou plusieurs serveurs 3, 3a, 3b de noms de domaine, auxquels ne renvoie pas les autres serveurs 2, 2a. Le serveur 1 est dit parent des serveurs 2, 2a, eux-mêmes parents des serveurs 3, 3a auxquels ils renvoient. Chaque serveur 3, 3a, 3b gère la zone associée à des numéros E164. Dans l'exemple précédent, le serveur 2a de noms de domaine 3.3.e164.arpa renvoie à plusieurs serveurs 3a, 3b de noms de domaine. Le serveur 3a de noms de domaine gère par exemple un certain nombre d'adresses en 3.3.e164.arpa, comprenant par exemple l'adresse 8.3.5.3.5.0.6.9.2.3.3.e164.arpa et est associé à la mémoire 4 de la figure 2. Par exemple, le serveur 3a gère la zone se terminant par 5.0.6.9.2.3.3.e164.arpa, le serveur 3b gère une zone se terminant par 6.0.6.9.2.3.3.e164.arpa. Une machine H souhaitant obtenir des informations I présentes dans un enregistrement ENR de l'architecture A envoie à une plate-forme ASP, qui peut être par exemple celle d'un fournisseur de services, une demande permettant de déterminer le nom ADR de cet enregistrement ENR. Cette plate-forme ASP a par exemple une architecture client-serveur et comprend un accès 10 de réception des demandes depuis l'extérieur et émises par des machines H et un module 11 de résolution (resolver) pour le traitement des demandes reçues sur l'accès 10. Le module 11 de résolution est client d'un serveur local (DNS local) de noms de domaine 12 connecté au module 11 et est apte à envoyer au serveur local de noms de domaine 12 connecté au module 11 , des signaux d'interrogation correspondant à la demande reçue sur l'accès 10. Le serveur local 12 de noms de domaine est apte à émettre, en fonction des signaux d'interrogation, des messages de requêtes R en informations I vers l'architecture de serveurs de noms de domaine de la manière suivante. Les messages de requêtes R comprennent le nom ADR du domaine à interroger dans l'architecture pour obtenir l'enregistrement ENR souhaité. Dans l'exemple précédent de la numérotation téléphonique, la demande envoyée par la machine H à la plate-forme ASP précise le numéro de téléphone souhaité, que la plate-forme ASP (par exemple par le module 11 de résolution) traduit en numéro E.164 faisant office d'adresse ADR à interroger (par exemple ADR = 8.3.5.3.5.0.6.9.2.3.3.e164.arpa). Le message de requête R comprenant le nom ADR est envoyé d'abord à l'étape E1 au serveur 1 , lequel renvoie ensuite lors de l'étape E2 un premier message de réponse au serveur local 12, lui indiquant une référence au serveur 2 correspondant, sélectionné par cette adresse ADR, c'est-à-dire dans l'exemple précédent le serveur 2a. Le serveur local 12 envoie ensuite lors de l'étape E3 le message de requête R comprenant le nom ADR au serveur 2 sélectionné et indiqué dans le premier message de réponse, c'est-à-dire dans l'exemple précédent au serveur 2a, lequel serveur 2a envoie ensuite, lors de l'étape E4, un deuxième message de réponse au serveur local 12, lui indiquant une référence au serveur 3 correspondant, sélectionné par ce nom ADR, c'est-à-dire dans l'exemple précédent le serveur 3a. Le serveur local 12 envoie ensuite lors de l'étape E5 le message de requête R comprenant le nom ADR au serveur 3 de noms de domaine sélectionné et indiqué dans le deuxième message de réponse, sur son entrée 21 de réception de messages de requêtes depuis l'extérieur, c'est-à-dire dans l'exemple précédent à l'entrée 21 du serveur 3a. Chaque serveur 3, 3a, 3b comporte au moins une entrée 5 d'admission de messages de requêtes R. Les messages de requêtes R peuvent être par exemple des requêtes en lecture d'informations I au nom ADR ou des requêtes en écriture d'informations I au nom ADR. Lorsqu'un message de requête en lecture au nom ADR, parvient à l'entrée d'admission 5, l'enregistrement ENR des informations I présentes à cette adresse ADR est lu dans la mémoire 4 associée, (par exemple l'information 12a est lue pour l'adresse AD.R2). Le serveur 3, 3a, 3b comporte une première sortie 6 de fourniture d'un message de réponse à la requête R en lecture présente sur son entrée 5. Ce message de réponse contient l'information I lue dans la mémoire 4 associée et les enregistrements NAPTR lus au nom spécifié dans le message R de requête en lecture, comme ceux indiqués dans l'exemple mentionné ci-dessus. Suivant l'invention, devant l'un, plusieurs ou tous les serveurs 3, 3a,
3b de noms de domaine est interposé un module 7 de transmission de messages, par lequel doivent passer les messages émis vers ce(s) serveur 3, 3a, 3b depuis un requérant, formé dans l'exemple décrit ci-dessus par le serveur local 12 ayant émis le message de requête R, et les messages émis par ce serveur 3, 3a, 3b vers le requérant. Le module 7 de transmission possède comme adresse, dans l'architecture A des serveurs, l'adresse de renvoi au serveur 3a auquel il est associé. Ainsi, pour le serveur 3a de noms de domaine, ce module 7 de transmission comporte une première voie 8 de transmission des messages d'une première entrée 21 d'admission des messages du requérant à une première sortie 50 de fourniture des messages au serveur 3a de noms de domaine reliée à l'entrée 5 d'admission desdits messages du serveur 3a, une deuxième voie 9 de transmission des messages d'une deuxième entrée 60 d'admission des messages du serveur 3a de noms de domaine, reliée à la sortie 6 de fourniture desdits messages du serveur 3a, à une deuxième sortie 25 de fourniture des messages au requérant. Un premier module 20 de contrôle des messages depuis le requérant et/ou un deuxième module 26 de contrôle des messages depuis le serveur 3a sont prévus dans le module 7 de transmission pour le serveur 3a de noms de domaine. Le premier module 20 de contrôle des messages depuis le requérant est interposé sur la première voie 8 de transmission entre la première entrée 21 d'admission de messages depuis le requérant et la première sortie 50 de fourniture des messages au serveur 3a. Le deuxième module 26 de contrôle des messages depuis le serveur 3a est interposé sur la deuxième voie 9 de transmission entre la deuxième entrée 60 d'admission de messages depuis le serveur 3a et la deuxième sortie 25 de fourniture des messages au requérant. Bien entendu, un autre, plusieurs autres ou tous les serveurs 3, 3a,
3b de noms de domaine peuvent également comporter chacun leur module
7 de transmission, ayant le module 20 et/ou le module 26. Dans l'exemple précédent et dans ce qui suit, on suppose que c'est au moins le serveur 3a de noms de domaine, qui comporte les modules 7, 20 et 26. Le premier module 20 de contrôle des messages depuis le requérant comporte des premiers moyens 22 de réception des messages présents sur son entrée 21 d'admission de messages depuis le requérant et d'analyse de ces messages, et des premiers moyens 24 de filtrage des messages. Lorsque le message présent sur l'entrée 21 est un message de requête R en lecture, ce que détectent automatiquement les premiers moyens 22 d'analyse par exemple par la présence dans le message d'un signal de lecture (champ OPCODE positionné à 0 dans le message selon le document IETF RFC 1035 et RFC 2136), celui-ci est transmis directement, sauf éventuel contrôle d'accès supplémentaire ainsi que cela sera expliqué ci-dessous, par les premiers moyens 24 de filtrage à la première sortie 50 et à l'entrée 5 d'admission de messages du serveur 3a. Le deuxième module 26 de contrôle des messages depuis le serveur
3a associé comporte des deuxièmes moyens 27 de réception des messages présents sur son entrée 60 d'admission des messages depuis la sortie 6 de fourniture du serveur 3a, et d'analyse de ces messages, et des deuxièmes moyens 28 de filtrage des messages. Le module 7 de transmission comporte en outre une base 23 de filtrage contenant une ou plusieurs premières valeurs DF de filtrage de champs de service, associées aux premiers moyens 24 de filtrage, et une ou plusieurs deuxièmes valeurs DF de filtrage de champs de service, associées aux deuxièmes moyens 28 de filtrage. Dans le cas d'un message de requête R en lecture transmis à l'entrée 5 d'admission, le message transmis par le serveur 3a à sa sortie 6 de fourniture est un message RR de réponse à ce message de requête R en lecture, qui contient les enregistrements NAPTR lus. Les moyens 27 analysent ce message RR de réponse pour en extraire les champs de service des enregistrements NAPTR qu'il contient. Les deuxièmes moyens 28 de filtrage comparent chaque champ de service extrait du message RR de réponse à la ou aux deuxième(s) valeurs DF de filtrage de champ de service de la base 23. Parmi les valeurs DF de filtrage de champs de service peuvent se trouver une ou plusieurs valeurs autorisées de champs de service, par exemple dans l'exemple précédent « mailto » et « http » pour les deuxièmes valeurs DF de filtrage, et/ou une ou plusieurs valeurs autorisées de champs de service. Si il est déterminé par les deuxièmes moyens 28 de filtrage que le champ de service extrait du message RR de réponse correspond à une deuxième valeur autorisée de champ de service ou ne correspond à aucune deuxième valeur non autorisée de champ de service, l'enregistrement NAPTR contenant ce champ de service est conservé dans le message RR de réponse transmis à la deuxième sortie 25 de fourniture du message au requérant 12. Si il est déterminé par les deuxièmes moyens 28 de filtrage que le champ de service extrait du 5 message RR de réponse correspond à une deuxième valeur non autorisée de champ de service ou ne correspond à aucune deuxième valeur autorisée de champ de service, l'enregistrement NAPTR contenant ce champ de service est supprimé dans le message RR de réponse transmis à la deuxième sortie 25 de fourniture du message au requérant 12. Le0 requérant 12 ne reçoit donc pas dans les messages RR de réponse transmis par le module 7 les enregistrements NAPTR à champ de service non autorisé, qui en sont éliminés par le module 26. Le module 7 de transmission effectue donc un filtrage de contenu des messages RR de réponse du serveur 3a au requérant 12. Dans l'exemple précédent, le5 message RR de réponse filtré sur la sortie 25 sera donc : 8.3.5.3.5.0.6.9.2.3.3.e164.arpa: type NAPTR, class inet Name: 8.3.5.3.5.0.6.9.2.3.3.e164.arpa Type: Naming authority pointer Class: inet 0 Time to live: 30 seconds Data length: 48 Data: 10 20 "u" "E2U+mail" "!Λ.*$!mailto:dupont(5)ft.com!"
8.3.5.3.5.0.6.9.2.3.3.e164.arpa: type NAPTR, class inet5 Name: 8.3.5.3.5.0.6.9.2.3.3.e164.arpa Type: Naming authority pointer Class: inet Time to live: 30 seconds Data length: 39 o Data: 10 20 "u" "E2U+http" "!Λ.*$!http://www.exemple.fr!" Par conséquent, dans ce mode de réalisation, un enregistrement NAPTR du serveur 3a ne peut parvenir à la sortie 25 vers l'extérieur et, lors de l'étape E6 postérieure à l'étape E5, au serveur local 12 qu'en ayant traversé avec succès le deuxième module 26, la sortie 6 de fourniture de messages de réponse du serveur 3a étant masquée par ce deuxième module 26 pour le serveur 12. Le message de requête émis par le serveur local 12 requérant peut également être un message de requête W en écriture d'informations I dans le serveur 3a de noms de domaine en au moins un nom ADR spécifié dans celui-ci et géré par ce serveur 3a. Un message de requête W en écriture comporte donc un ou plusieurs enregistrements NAPTR, qui sont ceux à écrire au nom spécifié dans ce message dans la mémoire 4 associée au serveur 3a destinataire du message. Ce message de requête W en écriture est alors envoyé à la première entrée 21 d'admission de requêtes, pour être reçu et analysé par les moyens 22 du module 7 de transmission. Lorsque le message présent sur l'entrée 21 est un message de requête W en écriture, ce que détectent automatiquement les moyens 22 d'analyse par exemple par la présence dans le message d'un signal d'écriture (champ OPCODE positionné à 5 dans le message selon le document IETF RFC 1035 et RFC 2136), les moyens 22 d'analyse extraient automatiquement les champs de service des enregistrements NAPTR qu'il contient. Les premiers moyens 24 de filtrage comparent chaque champ de service extrait du message de requête W en écriture à la ou aux première(s) valeurs DF de filtrage de champ de service de la base 23. Si il est déterminé par les premiers moyens 24 de filtrage que le champ de service extrait du message de requête W en écriture correspond à une première valeur autorisée de champ de service ou ne correspond à aucune première valeur non autorisée de champ de service, l'enregistrement NAPTR contenant ce champ de service est conservé dans le message de requête W en écriture transmis à la première sortie 50 de fourniture du message au serveur 3a. Si il est déterminé par les premiers moyens 24 de filtrage que le champ de service extrait du message de requête W en écriture correspond à une première valeur non autorisée de champ de service ou ne correspond à aucune première valeur autorisée de champ de service, l'enregistrement NAPTR contenant ce champ de service est supprimé dans le message de requête W en écriture transmis à la première sortie 50 de fourniture du message au serveur 3a. Le serveur 3a ne reçoit donc pas dans les messages W en écriture transmis par le module 7 les enregistrements NAPTR à champ de service non autorisé, qui en sont éliminés par le module 20. Le module 7 de transmission effectue donc un filtrage de contenu des messages W en écriture du requérant 12 au serveur 3a. Dans l'exemple précédent, si une deuxième valeur non autorisée de champs de service est « mail » et si une deuxième valeur autorisée de champs de service est « http », le requérant 12 ne pourra pas écrire l'enregistrement NAPTR 10 20 "u" "E2U+mail" "!Λ.*$!mailto:durand(α,ft.com!" mais pourra écrire l'enregistrement NAPTR 10 20 "u" "E2U+http" "!Λ.*$!http ://www.durand(α,ft.com!" au nom 8.3.5.3.5.0.6.9.2.3.3.e164.arpa. La ou les valeurs DF de filtrage de champ de service sont par exemple valables pour tous les messages et tous les noms gérés par le serveur 3a. Dans un perfectionnement de l'invention, les premières et/ou deuxièmes valeurs DF de filtrage de la base 23 sont associées en plus à des valeurs DC de contrôle d'accès, associées à des moyens CA de contrôle d'accès correspondants, combinés aux premiers et/ou deuxièmes moyens de filtrage 24, 28, ainsi que cela est représenté entre parenthèses à la figure 1. Les valeurs DC de contrôle d'accès sont des paramètres présents dans les messages. Par conséquent, le filtrage de contenu des messages est alors effectué en fonction également d'autres paramètres des messages, ainsi que cela est expliqué ci-dessous. Par conséquent, lorsqu'une première valeur DF de filtrage est associée à une ou plusieurs valeurs DC de contrôle d'accès, les moyens 22 extraient en plus du message qu'ils ont reçu les paramètres correspondants à ces valeurs DC. Les moyens 24 de filtrage comparent ensuite ces paramètres extraits et le champ de service extrait à la ou aux combinaisons de valeurs DF et DC associées de la base 23, pour déterminer si le message reçu comporte une telle combinaison. Dans l'affirmative, le message présent sur la première entrée 21 d'admission du requérant est transmis, filtré par son champ de service ainsi que cela a été décrit ci- dessus, à la première sortie 50 de fourniture au serveur 3a sur son entrée 5. Dans la négative, le message présent sur la première entrée 21 d'admission du requérant n'est pas transmis à la première sortie 50 de fourniture au serveur 3a sur son entrée 5. Il en est de même pour les moyens 27 de réception et d'analyse, les moyens 28 de filtrage, les deuxièmes valeurs DF de filtrage vis-à-vis des messages envoyés sur la deuxième entrée 60 d'admission des messages du serveur 3a de noms de domaine. Des exemples de valeurs DC de contrôle d'accès que peut contenir la base 23 sont les suivants, ainsi que cela est représenté à la figure 3 : - une ou plus d'une adresse IP d'un serveur local (DNS local) de noms de domaine, analogue au serveur 12 de la plate-forme ASP, ces serveurs locaux émettant les messages de requête R en lecture et/ou de requête W en écriture contenant cette adresse IP de serveur local. Des adresses IP de plusieurs serveurs locaux peuvent être comprises dans les données DC de contrôle d'accès. Dans ce cas, le contrôle d'accès effectué par le premier module 20 ne transmet pas à l'entrée 5 les messages de requêtes R et/ou W émanant de serveurs locaux dont l'adresse IP est absente de la base 23 mais ne permet la transmission à l'entrée 5 que de messages de requêtes R et/ou W émanant de serveurs locaux ayant une adresse IP identifiée comme telle dans la base 23. - un ou plusieurs nom(s) ADR gérés par le serveur 3a de noms de domaine. Dans ce cas, le contrôle d'accès effectué par le premier module 20 ne transmet pas à l'entrée 5 les messages de requête R en lecture et/ou de requête W en écriture sur un nom absent de la base 23 mais ne permet la transmission à l'entrée 5 que de messages de requête R en lecture et/ou de requête W en écriture contenant un nom ADR identifié comme tel dans la base 23. - une ou plusieurs zone(s) de noms ADR gérés par le serveur 3a de noms de domaine. Dans ce cas, le contrôle d'accès effectué par le premier module 20 ne transmet pas à l'entrée 5 les messages de requête R en lecture et/ou de requête W en écriture concernant un nom absent des zones de noms de la base 23 mais ne permet la transmission à l'entrée 5 que de messages de requête R en lecture et ou de requête W en écriture contenant un nom ADR appartenant à une zone de la base 23. - en association pour au moins une adresse IP de serveur de noms de domaine local extérieur, au moins un nom ; - en association pour au moins une adresse IP de serveur de noms de domaine local extérieur, au moins une zone de noms. Les valeurs DF de filtrage et les valeurs DC de contrôle d'accès enregistrées dans la base 23 peuvent être modifiées par une autorité gestionnaire du serveur 3a. On suppose dans l'exemple décrit ci-dessus de la requête R envoyée à l'étape E5 à l'entrée 21 , que le message de requête R provient du serveur local 12 de la figure 1 ayant l'adresse IP 172.32.32.32. Dans l'exemple illustré à la figure 3, les messages de requête R provenant de l'adresse IP 172.32.32.32 et interrogeant un nom ADR appartenant à la zone de noms ADR *.6.9.2.3.3.e164.arpa seront transmises filtrées par leur champ de service à l'entrée 5. Par conséquent, le message de requête R émis par le serveur local 12 ayant cette adresse IP et interrogeant le nom ADR = 8.3.5.3.5.0.6.9.2.3.3. e164. arpa sera transmis, filtré par son champ de service, à l'entrée 5 d'admission du_ serveur 3a. En revanche, un message de requête R de ce même serveur local 12 mais qui interrogerait le nom 8.3.5.3.5.0.7.9.2.3.3. e164. arpa ne serait pas transmis au serveur 3a, étant donné que la zone de noms ADR *.6.9.2.3.3.e164.arpa associée à l'adresse IP de ce serveur 12 dans les données DF de ce système 3a ne contient pas le nom 8.3.5.3.5.0.7.9.2.3.3.e164.arpa. Ainsi, le filtrage des champs de service peut être effectué par le module 7 de transmission en fonction des requérants 12 ou serveurs locaux 12, qui peuvent être différents fournisseurs de services auxquels ont souscrit les personnes utilisant les machines H, ce filtrage sélectif étant effectué grâce en plus aux valeurs DC de contrôle d'accès associées aux valeurs de filtrage. Dans une variante, représentée à la figure 3, les valeurs DC de contrôle d'accès comportent pour le premier module 20, en plus de l'une ou plusieurs des données décrites ci-dessus, également des données d'action indiquant l'écriture et/ou la lecture pour autoriser la transmission des messages de requêtes R en lecture et de requêtes W en écriture. Des données d'action positionnées sur lecture en association avec les autres valeurs DF, DC font en sorte que tous les messages de requêtes R en lecture vérifiant les autres valeurs DF, DC seront transmises de la première entrée 21 à l'entrée 5 du serveur 3a. Des données d'action positionnées sur écriture en association avec les autres valeurs DF, DC font en sorte que tous les messages de requêtes W en écriture vérifiant les autres valeurs DF, DC seront transmises de la première entrée 21 à l'entrée 5 du serveur 3a. Les valeurs DC de contrôle d'accès peuvent également comporter une clé partagée entre la plate-forme ASP et le serveur 3a de noms de domaine, cette clé partagée utilisant une fonction de hachage non inversible pour authentifier les messages. Cette clé partagée est utilisée pour signer le message en y ajoutant une signature de transaction telle que TSIG selon le document IETF RFC2845. Dans l'exemple de la figure 3, la valeur DC de contrôle d'accès de clé associée est par exemple skgKc4wwlQu77F==. La signature permet de prouver que l'expéditeur et le destinataire du message partagent la même clé et que le message n'a pas été modifié depuis son envoi. Cette signature est utilisée pour les messages de requêtes R en lecture et de requêtes W en écriture. Une relation de confiance doit être établie entre le serveur 3a de noms de domaine et la plate-forme ASP pour le partage de la clé. Le serveur local 12 doit être capable de savoir ajouter la clé lorsqu'il envoie un message de requête au serveur 3a. Le module 7 de transmission comporte par exemple des moyens pour, dans le cas où les moyens CA de contrôle d'accès associés aux premiers et/ou deuxièmes moyens de filtrage 24, 28, refusent à un message l'accès à la première sortie 50 et à l'entrée 5 d'admission et/ou à la deuxième sortie 25, retourner vers l'extérieur lors de l'étape E6 postérieure à l'étape E5, sur une sortie correspondante, par exemple 25, à l'émetteur 12 de ce message une réponse contenant un code d'erreur correspondant. Le module de transmission comporte également par exemple des moyens pour, en cas d'absence d'enregistrement NAPTR dans le message de requête en écriture W filtré sur la première sortie 50 de fourniture de messages au serveur 3a de noms de domaine, alors qu'un ou plusieurs enregistrements NAPTR étaient présent dans le message de requête en écriture W non filtré sur la première entrée 21 , retourner sur la deuxième sortie 25 de fourniture de messages au requérant une réponse contenant un code d'erreur correspondant.

Claims

REVENDICATIONS
1. Module de transmission de messages entre l'un et l'autre d'un requérant (12) d'un serveur (3a) de noms de domaine et dudit serveur (3a) 5 de noms de domaine, les messages contenant au moins un enregistrement de ressource NAPTR ayant un champ de service, caractérisé en ce que le module de transmission comporte : - au moins une première voie (8) de transmission de messages d'au0 moins une première entrée (21) d'admission de messages du requérant à au moins une première sortie (50) de fourniture de messages au serveur (3a) de noms de domaine, - au moins une deuxième voie (9) de transmission de messages d'au moins une deuxième entrée (60) d'admission de messages du serveur (3a)5 de noms de domaine à au moins une deuxième sortie (25) de fourniture de messages au requérant (12), et - interposés entre l'entrée et la sortie d'au moins une voie déterminée parmi les première et deuxième voies (8, 9) de transmission, des moyens (20, 26) de réception des messages depuis l'entrée (21 ,0 6) de ladite voie déterminée, des moyens d'extraction de la valeur du champ de service dans les messages reçus et des moyens (24, 28) de filtrage des messages de ladite entrée (21 , 6) de ladite voie déterminée en fonction de la valeur extraite du champ de5 service, présente dans lesdits messages reçus, et d'au moins une valeur (DF) de filtrage de champs de service, présente dans une base (23) de filtrage associée aux moyens (20, 26) de filtrage, ladite valeur (DF) de filtrage de champs de service étant l'une parmi au moins une valeur autorisée de champs de service et au moins une o valeur non autorisée de champs de service, les moyens (24, 28) de filtrage étant aptes à ce que les messages transmis à ladite sortie (50, 25) de ladite voie déterminée ne contiennent pas d'enregistrement de ressource NAPTR ayant une valeur de champ de service ne correspondant pas à la valeur (DF) de filtrage, lorsque cette valeur (DF) de filtrage est une valeur autorisée de champs de service, et ne contiennent pas d'enregistrement de ressource NAPTR ayant une valeur de 5 champ de service correspondant à la valeur (DF) de filtrage, lorsque cette valeur (DF) de filtrage est une valeur non autorisée de champs de service.
2. Module de transmission selon la revendication 1 , caractérisé en ce que les moyens (20, 26) de réception, d'extraction et de filtrage des messages sont interposés au moins entre la première entrée (21 ) et la0 première sortie (50) de la première voie (8) de transmission de messages.
3. Module de transmission selon la revendication 1 , caractérisé en ce que les moyens (20, 26) de réception et de filtrage des messages sont interposés au moins entre la deuxième entrée (60) et la deuxième sortie (25) de la deuxième voie (9) de transmission de messages.5 4. Module de transmission suivant l'une quelconque des revendications précédentes, caractérisé en ce que les moyens (20, 26) de réception, d'extraction et de filtrage des messages sont interposés au moins entre la première entrée (21 ) et la première sortie (50) de la première voie (8) de transmission de messages et entre la deuxième entrée (60) et la0 deuxième sortie (25) de la deuxième voie (9) de transmission de messages. 5. Module de transmission suivant l'une quelconque des revendications 3 et 4, caractérisé en ce que la deuxième entrée (60) d'admission de messages du serveur (3a) de noms de domaine est une entrée (60) d'admission de messages (RR)5 de réponse du serveur (3a) de noms de domaine à des messages de requêtes en lecture (R) d'enregistrements de ressource NAPTR, lesdits messages de requêtes en lecture (R) ayant été émis par le requérant (12) et ayant été transmis au serveur (3a) de noms de domaine, lesdits messages (RR) de réponse comportant en outre respectivement ledit au o moins un enregistrement de ressource NAPTR du serveur (3a) de noms de domaine, lu selon la requête en lecture, lorsque cet enregistrement de ressource NAPTR est présent dans le serveur (3a) de noms de domaine, la deuxième sortie (25) de fourniture de messages au requérant est une sortie (25) de fourniture desdits messages (RR) de réponse filtrés au requérant. 6. Module de transmission suivant l'une quelconque des revendications 2, 4 et 5, caractérisé en ce que la première entrée (21 ) d'admission de messages du requérant (12) est une entrée (21) d'admission de messages de requêtes au moins en écriture (W) dudit au moins un enregistrement de ressource NAPTR dans le serveur (3a) de noms de domaine, lesdits messages de requêtes en écriture (W) ayant été émis par le requérant (12), la première sortie (50) de fourniture de messages au serveur (3a) de noms de domaine est une sortie (50) de fourniture desdits messages de requêtes en écriture (W) au serveur (3a) de noms de domaine, chaque message de requête en écriture (W) comportant en outre respectivement ledit au moins un enregistrement de ressource NAPTR à écrire dans le serveur (3a) de noms de domaine selon la requête en écriture. 7. Module de transmission suivant la revendication 6, caractérisé en ce qu'il comporte en outre des moyens pour, en cas d'absence d'enregistrement NAPTR dans le message de requête en écriture (W) présent sur la première sortie (50) de fourniture de messages au serveur (3a) de noms de domaine, retourner sur la deuxième sortie de fourniture de messages . au requérant une réponse contenant un code d'erreur correspondant. 8. Module de transmission suivant l'une quelconque des revendications 5 à 7, caractérisé en ce que chaque message de requête en écriture (W) respectivement en lecture (R) comporte un signal d'écriture respectivement de lecture, et les valeurs (DF) de filtrage de champs de service comprennent des valeurs (DF) de filtrage associées à une valeur d'action indiquant l'écriture respectivement la lecture, les moyens (24, 28) de filtrage étant aptes à effectuer ledit filtrage des messages comportant un signal d'écriture respectivement de lecture sur la base des valeurs (DF) de filtrage associées à une valeur d'action indiquant l'écriture respectivement la lecture. 9. Module de transmission suivant l'une quelconque des revendications précédentes, caractérisé en ce que les moyens (24, 28) de filtrage sont combinés à des moyens de contrôle d'accès des messages de l'entrée de la voie déterminée à la sortie de la voie déterminée en fonction d'au moins une valeur (DC) de contrôle d'accès, qui est associée dans la base (23) de filtrage à ladite au moins une valeur (DF) de filtrage et qui porte dans les messages sur un paramètre homologue de la valeur (DC) de contrôle d'accès. 10. Module de transmission suivant la revendication 9, caractérisé en ce que ladite au moins une valeur (DC) de contrôle d'accès et ledit paramètre homologue des messages sont choisis parmi le nom (ADR) de domaine de destination des messages et/ou l'adresse IP du requérant et/ou la signature TSIG associée au message. 11. Module de transmission suivant l'une quelconque des revendications 9 ou 10, caractérisé en ce qu'il comporte en outre des moyens pour, en cas de refus d'accès d'un message à la sortie de la voie déterminée, retourner sur la deuxième sortie de fourniture de messages au requérant une réponse contenant un code d'erreur correspondant. 12. Module de transmission suivant l'une quelconque des revendications précédentes, caractérisé en ce que les noms (ADR) dudit serveur (3a) de noms de domaine utilisent des numéros de téléphone. 13. Module de transmission suivant la revendication 12, caractérisé en ce que les noms dudit serveur (3a) de noms de domaine utilisent des numéros de téléphone au format E.164, ledit serveur (3a) de noms de domaine étant un serveur (3a) de noms de domaine de numérotation téléphonique e164.arpa. 14. Module de transmission suivant l'une quelconque des revendications précédentes, caractérisé en ce que le au moins un enregistrement de ressource NAPTR ayant un champ de service est selon le document RFC 3403 du groupe de travail IETF. 15. Architecture hiérarchisée de serveurs de noms de domaine, comportant au moins un premier serveur (3a) de noms de domaine, un module (7) de transmission de messages entre un requérant (12) et ledit premier serveur (3a) de noms de domaine suivant l'une quelconque des revendications précédentes, et un deuxième serveur (2a) de noms de domaine, parent du premier serveur (3a) de noms de domaine et agencé pour faire référence audit premier serveur (3a) de noms de domaine par l'adresse du module de transmission. 16. Procédé de transmission de messages entre l'un et l'autre d'un requérant (12) d'un serveur (3a) de noms de domaine et dudit serveur (3a) de noms de domaine, les messages contenant au moins un enregistrement de ressource NAPTR ayant un champ de service, caractérisé en ce que l'on reçoit les messages provenant du requérant et à destination du serveur (3a) de noms de domaine, respectivement les messages provenant du serveur (3a) de noms de domaine et à destination du requérant, et l'on exécute un filtrage des messages au destinataire en fonction de la valeur du champ de service présente dans lesdits messages et de valeurs (DF) de filtrage de champs de service, présentes dans une base (23) de filtrage, ladite valeur (DF) de filtrage de champs de service étant l'une parmi au moins une valeur autorisée de champs de service et au moins une valeur non autorisée de champs de service, le filtrage étant effectué de manière à ce que les messages filtrés ne contiennent pas d'enregistrement de ressource NAPTR ayant une valeur de champ de service ne correspondant pas à la valeur (DF) de filtrage, lorsque cette valeur (DF) de filtrage est une valeur autorisée de champs de service, et ne contiennent pas d'enregistrement de ressource NAPTR ayant une valeur de champ de service correspondant à la valeur (DF) de filtrage, lorsque cette valeur (DF) de filtrage est une valeur non autorisée de champs de service. 17. Procédé de transmission de messages suivant la revendication 16, caractérisé en ce que le au moins un enregistrement de ressource NAPTR ayant un champ de service est selon le document RFC 3403 du groupe de travail IETF.
PCT/FR2004/002335 2003-09-26 2004-09-15 Module et procede de transmission de messages a un serveur de noms de domaine et architecture ayant le module WO2005032096A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0311271A FR2860370A1 (fr) 2003-09-26 2003-09-26 Module et procede de transmission de messages a un serveur de noms de domaine et architecture ayant le module
FR0311271 2003-09-26

Publications (1)

Publication Number Publication Date
WO2005032096A1 true WO2005032096A1 (fr) 2005-04-07

Family

ID=34307173

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/002335 WO2005032096A1 (fr) 2003-09-26 2004-09-15 Module et procede de transmission de messages a un serveur de noms de domaine et architecture ayant le module

Country Status (2)

Country Link
FR (1) FR2860370A1 (fr)
WO (1) WO2005032096A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1993267A1 (fr) * 2007-05-16 2008-11-19 Telnic Limited Système de récupération d'informations de contact et système de communication l'utilisant

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111245973B (zh) * 2020-01-20 2022-06-03 烽火通信科技股份有限公司 一种基于域名的报文传输方法、报文转发控制方法及系统

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CENTER FOR DEMOCRACY AND TECHNOLOGY: "ENUM: Mapping Telephone Numbers onto the Internet - Potential Benefits with Public Policy Risks", STANDARDS, TECHNOLOGY AND POLICY PROJECT, April 2003 (2003-04-01), XP002281100, Retrieved from the Internet <URL:http://www.cdt.org/standards/enum/030428analysis.pdf> [retrieved on 20040519] *
HASSLER V: "X.500 AND LDAP SECURITY: A COMPARATIVE OVERVIEW", IEEE NETWORK, IEEE INC. NEW YORK, US, vol. 13, no. 6, November 1999 (1999-11-01), pages 54 - 64, XP000875732, ISSN: 0890-8044 *
M. MEALLING: "RFC 3403 - Dynamic Delegation Discovery System (DDDS), Part Three: The Domain Name System (DNS) Database", REQUEST FOR COMMENTS, October 2002 (2002-10-01), XP002281099, Retrieved from the Internet <URL:http://www.faqs.org/ftp/rfc/pdf/rfc3403.txt.pdf> [retrieved on 20040519] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1993267A1 (fr) * 2007-05-16 2008-11-19 Telnic Limited Système de récupération d'informations de contact et système de communication l'utilisant

Also Published As

Publication number Publication date
FR2860370A1 (fr) 2005-04-01

Similar Documents

Publication Publication Date Title
JP4460016B2 (ja) グローバルネームゾーン
EP1974522B1 (fr) Serveur, client et procédé pour gérer des requetes DNSSEC
EP1327345B1 (fr) Procede de controle d&#39;acces a des adresses de sites internet
US8433700B2 (en) Method and system for triggering web crawling based on registry data
US7565407B1 (en) Network proxy apparatus and methods
EP2294776B1 (fr) Procédé et système d&#39;accès par un utilisateur à au moins un service offert par au moins un autre utilisateur
US20040250119A1 (en) Authenticated domain name resolution
EP1797696A1 (fr) Procede et systeme de resolution dns distribuee
US20070271393A1 (en) System and Methods for Domain Name Acquisition and Management
US8219709B2 (en) Method for internet name sharing
JP2009500733A (ja) データベース内の情報をカプセル化する方法、通信システム内で使用されるカプセル化データベース、及びデータベースがシステム内でインスタントメッセージを仲介する方法
CN102394885A (zh) 基于数据流的信息分类防护自动化核查方法
EP1704700B1 (fr) Procede et systeme pour l&#39; exploitation d&#39;un reseau informatique destine a la publication de contenu
FR2908540A1 (fr) Deploiement de bases dnssec
FR2979044A1 (fr) Procede de gestion et de controle de donnees de differents domaines d&#39;identite organises en ensemble structure
US20030191953A1 (en) Enhanced computer intrusion detection methods and systems
WO2005032096A1 (fr) Module et procede de transmission de messages a un serveur de noms de domaine et architecture ayant le module
EP3560163A1 (fr) Validation de livraison de contenu et de verification d&#39;une delegation de livraison d&#39;un contenu
EP2807815B1 (fr) Système et procédö de controle d&#39;une requête dns
WO2007003818A1 (fr) Procede de filtrage par couplage multi-protocolaire sur la base du protocole dns.
EP1695523B1 (fr) Procédé et dispositif d&#39;émission de requêtes vers un serveur de noms de domaine depuis une machine requérante
US8732293B2 (en) System and method for tracking individuals on a data network using communities of interest
CN110300193B (zh) 一种获取实体域名的方法和装置
WO2006021665A1 (fr) Procede d&#39;attribution de certificat d&#39;authentification et infrastructure d&#39;attribution de certificat
FR2855630A1 (fr) Systeme de vote electronique aux assemblees d&#39;actionnaires

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase