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

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 etdes 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

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 1 o 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 284177-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 selon le document RFC 3403 du groupe de travail IETF, 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, 2860370 3 - 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 1 o 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.

Suivant d'autres caractéristiques de l'invention, - les moyens de réception, d'extraction et de filtrage des messages sont interposés au moins entre la première entrée et la première sortie de la première voie de transmission de messages; - les moyens de réception et de filtrage des messages sont interposés au moins entre la deuxième entrée et la deuxième sortie de la deuxième voie de transmission de messages; - les moyens de réception, d'extraction et de filtrage des messages sont interposés au moins entre la première entrée et la première sortie de la 1 o première voie de transmission de messages et entre la deuxième entrée et la deuxième sortie de la deuxième voie de transmission de messages; - la deuxième entrée d'admission de messages du serveur de noms de domaine est une entrée d'admission de messages de réponse du serveur de noms de domaine à des messages de requêtes en lecture d'enregistrements de ressource NAPTR, lesdits messages de requêtes en lecture ayant été émis par le requérant et ayant été transmis au serveur de noms de domaine, lesdits messages de réponse comportant en outre respectivement ledit au moins un enregistrement de ressource NAPTR du serveur de noms de domaine, lu selon la requête en lecture, lorsque cet enregistrement de ressource NAPTR est présent dans le serveur de noms de domaine, la deuxième sortie de fourniture de messages au requérant est une sortie de fourniture desdits messages de réponse filtrés au requérant; - la première entrée d'admission de messages du requérant est une entrée d'admission de messages de requêtes au moins en écriture dudit au moins un enregistrement de ressource NAPTR dans le serveur de noms de domaine, lesdits messages de requêtes en écriture ayant été émis par le requérant, la première sortie de fourniture de messages au serveur de noms de 30 domaine est une sortie de fourniture desdits messages de requêtes en écriture au serveur de noms de domaine, 2860370 5 chaque message de requête en écriture comportant en outre respectivement ledit au moins un enregistrement de ressource NAPTR à écrire dans le serveur de noms de domaine selon la requête en écriture; le module de transmission comporte en outre des moyens pour, en cas d'absence d'enregistrement NAPTR dans le message de requête en écriture présent sur la première sortie de fourniture de messages au serveur 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; 1 o - chaque message de requête en écriture respectivement en lecture comporte un signal d'écriture respectivement de lecture, et les valeurs de filtrage de champs de service comprennent des valeurs de filtrage associées à une valeur d'action indiquant l'écriture respectivement la lecture, les moyens de filtrage étant aptes à effectuer ledit filtrage des messages comportant un signal d'écriture respectivement de lecture sur la base des valeurs de filtrage associées à une valeur d'action indiquant l'écriture respectivement la lecture; - les moyens 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 de contrôle d'accès, qui est associée dans la base de filtrage à ladite au moins une valeur de filtrage et qui porte dans les messages sur un paramètre homologue de la valeur de contrôle d'accès; - ladite au moins une valeur de contrôle d'accès et ledit paramètre homologue des messages sont choisis parmi le nom de domaine de destination des messages et/ou l'adresse IP du requérant et/ou la signature TSIG associée au message; - le module de transmission 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; - les noms dudit serveur de noms de domaine utilisent des numéros de téléphone; - les noms dudit serveur de noms de domaine utilisent des numéros de téléphone au format E.164, ledit serveur de noms de domaine étant un serveur de noms de domaine de numérotation téléphonique e164.arpa.

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 15 domaine et dudit serveur de noms de domaine, les messages contenant au moins un enregistrement de ressource NAPTR ayant un champ de service selon le document RFC 3403 du groupe de travail IETF, 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.

L'invention sera mieux comprise à la lecture de la description qui va 5 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 11 a, 11 b, 11 c, au nom ADR2 l'information 12a, au nom ADR3 l'information 13a, au nom ADR4 les informations 14a et 14b, au nom ADRj l'information Ij et au nom ADRn l'information 12n.

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 3o 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 (Telephone Number Mapping Working Group) défini au groupe de travail IETF (groupe 2860370 8 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, 25 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:duponteft.com, http:/lwww.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 5 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""! A. *$!sip:dupont@ft.com!" IN NAPTR 10 20 "u" "E2U+mailto" "!^. *$!mailto:duponteft.com!" IN NAPTR 10 20 "u" "E2U+http" "!^.*$!http://www. exemple.fr!" lo 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 Tier1) 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 2860370 10 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 El 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 2860370 11 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 ADR2). 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 2860370 12 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 3o 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 2860370 13 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.

1 o 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, etlou 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 2860370 14 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 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. Le 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 1 o 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, le 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 Time to live: 30 seconds Data length: 48 Data: 10 20 "u" "E2U+mail" "!A. *$!mailto:dupont@ft.com!" 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 Time to live: 30 seconds Data length: 39 Data: 10 20 "u" "E2U+http" "!^. *$!http:/lwww.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 2860370 15 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 1 o serveur 3a destinataire du message. Ce message de requête W en écriture est alors envoyé à la première entrée 21d'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 2860370 16 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 réquérant 12 ne pourra pas 1 o écrire l'enregistrement NAPTR 10 20 "u" "E2U+mail" "!". *$!mailto:durandeft.com!" mais pourra écrire l'enregistrement NAPTR 10 20 "u" "E2U+http" "!".*$!http://www.durand eft.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 3o 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 2860370 17 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.

II 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 2860370 18 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 10 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.

2860370 19 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 à 2860370 20 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 lo é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 (1)

1. 21 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 selon le document RFC 3403 du groupe de travail IETF, caractérisé en ce que le module de transmission comporte: au moins une première voie (8) de transmission de messages d'au 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) 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, 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 de 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 30 au moins une valeur autorisée de champs de service et au moins une valeur non autorisée de champs de service, 2860370 22 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 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 1 o 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.

   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.

   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 la 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) 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 moins un enregistrement de ressource NAPTR du serveur (3a) de noms de 2860370 23 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 30 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) dé 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 2860370 25 domaine étant un serveur (3a) de noms de domaine de numérotation téléphonique el 64.arpa.

   14. 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.

   15. 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 15 NAPTR ayant un champ de service selon le document RFC 3403 du groupe de travail IETF, 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 25 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, 2860370 26 lorsque cette valeur (DF) de filtrage est une valeur non autorisée de champs de service.