WO2007003818A1

WO2007003818A1 - Method for filtering through multi-protocol coupling based on dns protocol

Info

Publication number: WO2007003818A1
Application number: PCT/FR2006/050461
Authority: WO
Inventors: Karel Mittig; Samuel Legouix
Original assignee: France Telecom
Priority date: 2005-05-20
Filing date: 2006-05-19
Publication date: 2007-01-11

Abstract

The invention concerns a filtering system and method for controlling access to content servers (40) by a user (1) from a computer terminal (2; 3; 4) sending a DNS resolution request to obtain a reply containing the IP address of the content server. The filtering method is characterized in that it includes the following steps: determining the user's profile (1) from data of the domain name resolution request emitted by the computer terminal (2; 3; 4) to verify whether a filtering of contents is defined in said profile; b) in case of negative verification, authorizing the domain name resolution request and reply; c) in case of positive verification, comparing the domain name present in the request and/or in the reply with a list of domain names predefined based of the profile of the user (1) of the computer terminal (2; 3; 4); d) filtering the domain name resolution request or reply when the result of the comparison indicates that the domain name present in the request or in the reply should be filtered, said filtering including one of the following two steps: d1) blocking the request or the reply and sending a notification of filtering to the user (1), or d2) sending the request or the reply to a secondary filtering device (20).

Description

MULTI-PROTOCOLAR COUPLING FILTERING PROCESS BASED ON THE DNS PROTOCOL

Field of the invention

The invention relates to filtering systems that control access to content hosted on servers to which users have access from a computer terminal via a computer network such as the Internet.

Prior art

Faced with the trivialization of access to the Internet and the multiplicity of content available on this medium, the control and filtering of access to these contents has become a necessity today, either in the family or educational context, so to prevent underage children from accessing pornographic or illegal content, either in the professional context, in order to limit the use of Internet or Intranet resources to the needs defined by the company.

Two types of content filtering solutions coexist today.

The first concerns solutions based on the installation of software on the client's terminal. These solutions have the main advantage of filtering many protocols, but are complex to deploy and maintain. The second type relates to solutions based on the use of proxy servers (also called proxy servers). These servers centralize all access to Internet and / or Intranet resources from client computers. These solutions are relatively easy to deploy and maintain, and provide an excellent level of filtering. On the other hand, they rarely support other protocols than the HTTP protocol ("HyperText Transfert

Protocol ") and have average performance at a high cost.

In the case of solutions based on the use of a proxy server, the content filtering may be based on the analysis of the request: the filtering is performed according to information sent by the user, typically a server name or a query URI ("Uniform Resource Identifier"). It can also be based on the analysis of the response: the filtering is done according to the response of the server, typically the meta-information that accompanies the response ("header" HTTP for example) and the requested object itself.

Naturally, the analysis of the transmitted request is the simplest, the least resource consuming and the fastest in terms of latency for the user. This mode is therefore preferred in all content filtering solutions (even when it is a response analysis solution). In concrete terms, when a query is presented, the filtering tool:

- Identifies the request, that is, determines what type of filtering should apply.

- Find / verify the domain name of the remote server or more generally I ¹ URI.

- Search in its internal base if I ¹ URI must be filtered or not.

- Apply the result of his search.

The first is a potentially complex and expensive operation (access to the Information System in the case of a company). The second step is usually ignored or misapplied by the filtering tools, and in the third step, the internal database contains mostly domain names and IP addresses rather than full URIs.

As with query analysis, content filtering based on response analysis must first identify the response to determine the type of filtering to apply. Then the tool runs a filter rule engine. This is the heart of the filtering system. The techniques used are more or less complex and represent a real technical know-how which consists in controlling both the quality of the filtering performed and the response time.

When the filtering system deems that content is inappropriate, it may apply:

- A blocking of access to the Internet resource: an application error ("404 Forbiden" for HTTP) is sent to the user to prevent it from blocking. - Partial blockage to the Internet resource; it can be to delete some parts of the object deemed unnecessary, resource-consuming or potentially dangerous (viruses, PopUp, Banner, ...). The user is usually not notified of the change.

- Degraded access to the Internet resource; for example, the bandwidth to access the object is limited. The user is not aware of the limitation applied.

Often, content filtering is confused with access control. This is often the case for protocols other than HTTP. Thus, for example, peer-to-peer (P2P) stream filtering now consists of limiting access by user or group of users.

Concerning filtering systems based on proxy servers, the main limitations of these systems are: - The latency induced by these solutions. For example, HTTP filtering systems need to break all the TCP ("Transmission Application Protocol") connections to perform content analysis, which has the effect of increasing the processing time and thus reducing the quality of service. perceived by users.

- The intrinsic inefficiency of these systems. Indeed, the percentage of filtered content is evaluated on average less than 5% of all content accessed. Excluding, current filtering systems involve analyzing all traffic, which implies unnecessary processing for 95% of requests.

- The low resistance in load. These systems have in fact reduced performance, which implies significant costs in the case where the number of customers is high.

- The low number of protocols supported by content filtering. Most existing solutions are indeed mono-protocols and rely only on HTTP. Few solutions also extend content filtering to protocols such as FTP ("File Transfer Protocol") or SMTP ("Simple Mail Transfer Protocol"). Object and brief description of the invention

The present invention aims to overcome the aforementioned drawbacks and to propose a filtering solution that can handle almost all requests for access to content servers, and this in an optimized manner, that is to say -describe using a concept based on the analysis and the gradual and multi-protocol filtering of client requests. This goal is achieved by a filtering method for controlling access to content by a user from a computer terminal comprising means for sending requests for content requests to content servers accessible via a network. communication system, access to the content servers comprising a prior step of DNS domain name resolution comprising the sending of a DNS resolution request from the computer terminal to obtain a response containing the IP address of the content server corresponding to the domain name indicated in the request, characterized in that it comprises the following steps: a) determining the profile of the user from the data of the domain name resolution request issued by the computer terminal to verify if content filtering is defined in the profile, b) in case of negative verification, authorization of the request and the response of res olution of domain name, c) in case of positive verification, comparison of the domain name present in the request and / or in the response with a list of predefined domain names according to the profile of the user of the computer terminal, d ) filtering the query or the domain name resolution response when the result of the comparison indicates that the domain name present in the request or in the response is to be filtered, said filtering comprising one of the following two steps; dl) blocking the request or response and sending a filtering notification to the user, or d2) returning the request or response to a secondary filtering device.

The invention thus makes it possible to filter the access requests, no longer at the level of the protocol used to obtain the content, but at the level of the DNS resolutions.

In the case where DNS filtering proves to be insufficient, the invention makes it possible to delegate requests requiring precise analysis (and only these requests) to traditional filtering systems such as relay application servers (HTTP proxies, FTP, etc.). . The invention thus makes it possible:

- Extremely efficient filtering of the majority of requests based on the DNS protocol. This filtering therefore applies to all application protocols based on DNS resolutions (ie almost all Internet protocols), and the proportion of queries that can be filtered is estimated at 99% of total requests.

- Notify a client that it has been filtered using the barrage server.

- Seamlessly redirect the remaining queries requiring more precise processing to application relay servers capable of analyzing the content requested by clients. This mechanism makes it possible to offer a filtering accuracy equivalent to existing solutions on the market, while removing all of the performance constraints of these solutions, since these devices will only process the proportion of remaining requests (ie around 1% of the traffic ).

In step d), the filtering further comprises a partial filtering step d3) of removing part of the information contained in the domain name resolution response transmitted to the user's terminal, thereby permitting the client to continue the connection but with limited access to only the content to which he has the right to access.

In step d1), the filtering notification is directly transmitted to the user by means of an application message containing the communication protocol used or indirectly by means of a message sent to the offline user, which allows in all the in case of returning to the user a message explaining the prohibition of access, either by using the content protocol used if it is standard, or by an additional notification system, such as an e-mail or an SMS, this which allows notifying a client access ban for all protocols that can not be supported.

To this end, the invention also relates to a barrier server comprising application means responsive to connection requests for returning a filtering notification message, each application means being able to support a specific application protocol, said barrier server further comprising means (ie computer program instructions) for checking whether the application protocol used in the connection request corresponds to one of the application protocols supported by the application means and for extracting, from the IP address of the sending user of the connection request, information for indirectly contacting the user and for sending a filtering notification message using said information, in case of negative verification.

The invention also relates to a DNS domain name filtering server intended to receive a DNS domain name resolution request issued from a user's computer terminal, characterized in that it comprises means (ie computer program instructions):

to determine the profile of the user from the data of the domain name resolution request sent by the computer terminal and to check if a content filtering is defined in said profile,

- to allow the request and the response of resolution of domain name in case of negative verification,

to compare the domain name present in the request and / or in the response with a list of predefined domain names according to the profile of the user, in case of a positive verification, and

- to filter the query or the domain name resolution response when the result of the comparison indicates that the domain name present in the request or in the response must be filtered. The domain name filtering server further comprises means for blocking the request or the response and for returning a domain name resolution response containing the IP address of a barrage server as previously described, said barrage server sending a filtering notification to the user.

The domain name filtering server further comprises means for returning the request or response to a secondary filtering device.

As for the filtering method described above, the domain name filtering server makes it possible to process the majority of content request requests, and this is optimized by a first level of simple and fast DNS filtering because it is independent of the protocol used in the content request. The accuracy of the filtering is further preserved with the ability to redirect the only requests requiring more precise filtering on secondary filtering servers.

Finally, the invention relates to a filtering system for controlling access to content by a user from a computer terminal, said system comprising a DNS domain name filtering server as described above, a server of barrage and one or more secondary filtering servers.

Brief description of the drawings

Other characteristics and advantages of the invention will emerge from the following description of particular embodiments of the invention, given by way of non-limiting examples, with reference to the appended drawings, in which:

FIG. 1 is a schematic global view of an embodiment of the DNS filtering system according to the invention,

FIG. 2 is a block diagram of a DNS filtering server according to one embodiment of the invention; FIG. 3 is a block diagram of a barrier server according to one embodiment of the invention; ,

FIG. 4 is a block diagram of a secondary filtering server,

- Figure 5 is a schematic view of a content filtering system according to the prior art. DETAILED DESCRIPTION OF THE EMBODIMENTS OF THE INVENTION

The present invention proposes to remove the limitations of the filtering solutions of the prior art by creating a hybrid filtering system based on the existing proxy server systems, but also and especially on domain name systems or DNS (acronym the English term "Domain Name System" or "Domain Name Service").

Indeed, access to a server on the Internet (web server, video server, mail server ...) is done after a DNS resolution to translate its name easily rememberable and intelligible to a human being (for example "www .wanadoo.fr ") in an IP address allowing the actual connection of the client station to this server (for example" 193.252.122.103 ").

The DNS protocol is thus used as a sub-layer prior to almost all the application protocols existing today on the Internet.

It also has extremely high performance. This position therefore makes it very suitable for access filtering solutions.

The invention proposes to bring a new approach to existing Web filtering mechanisms by proposing a system combining an initial DNS filtering associated, if necessary, with filtering on other protocols (eg HTTP).

The DNS model is defined by the IEETF standard 13 via RFCs 1034 and 1035. The purpose of the DNS model is to define a coherent namespace for Internet resources, allowing a match between a name and an IP address to be mapped. given moment.

The DNS model is based on a tree system, capable of supporting high load growth and allowing each organization to manage its address space. In this tree system, each node is a domain, and each domain is also a subdomain (with the exception of the root server).

The servers managing this model are divided into three functional groups: - Authoritative servers, responsible for managing domains. These servers are said to be "iterative", that is, they only answer questions about the areas they manage.

- Intermediate servers, also called DNS caches or DNS relay servers. These servers, optional, aim to store the most requested requests in order to accelerate DNS resolution times.

- Local servers, supporting user requests. These servers are called "recursive", that is, they are able to query the entire DNS tree to resolve a request from a client.

For a user, the only visible DNS server is its local DNS server (recursive DNS). This server is responsible for retrieving the IP address of the requested server and retransmitting it to the user. When a user tries to connect to a site in HTTP through a request for content request in the form of a URL ("Uniform Resource Locator") in his browser (for example, "www.francetelecom. com / subpart / index.html "), the connection is made in two stages. The browser performs a DNS resolution to obtain the IP address of the server. This request is sent to the local server, which is responsible for transmitting the request if necessary to other servers. Then, once the IP address obtained, the browser connects to the HTTP server, transmits the request for content request, retrieves the content and delivers it to the user. The DNS resolution request contains only the name of the requested server (in the example, "www.francetelecom.com"). The exact nature of the requested content is transmitted only within the HTTP content request request (in the example, "/ subpart / index.html").

This connection model is common to the majority of protocols: HTTP, WAP ("Wireless Application Protocol"), FTP ("File Transfer Protocol", SMTP ("Simple Mail Transfer Protocol"), IRC ("Internet Relay Chat"), RTSP ("Real Time Streaming Protocol"), etc.

Today, all filtering solutions rely solely on the analysis and filtering when connecting to the HTTP server (HTTP request scan) and not during the previous DNS resolution. The present invention provides: - the realization of a primary filtering system, working on domain names and based on the DNS protocol;

- The realization of a dam system, able to return an error message to a client regardless of the protocol used; - the definition of a mechanism for delegation of filtering to secondary filters in the case where the primary filtering system proves to be insufficient;

- The realization of secondary filtering systems, working on the concept of content and based on application protocols such as HTTP, FTP or SMTP.

The invention can thus be represented by:

- A DNS filtering device. This device can behave like a relay DNS server (DNS proxy), as a recursive DNS server (substitute for the DNS server client) or as an authoritative DNS server. These different modes of operation make it possible to position the invention as a cut-off of DNS flows at any point in the DNS architecture.

- A barrier device, the purpose of which is to return an error message to clients who have made a request that is not allowed.

- Secondary filtering devices, capable of analyzing other protocols such as HTTP, FTP, WAP, etc.

As described later in detail, these three types of devices can be implemented within dedicated servers. The barrier device and the secondary filtering devices do not need to be placed at a break from the client streams, and can be positioned at any point in a network architecture.

Principle of DNS filtering For the sake of simplification, an example of filtering according to the invention is described in the case where the DNS filtering system is implemented in the form of a relay between the clients and their recursive DNS server. This example is however not limiting to possible implementation cases, the invention can be implemented: - instead of the DNS server recursive customers, - or inserted anywhere in the DNS resolution chain depending on the deployment context.

The implementation case where the invention lies between the clients and their recursive DNS server is shown in FIG. 1. In the system represented in FIG. 1, a user 1 performs a DNS resolution request from a terminal. computer including means for connection to a computer network such as the Internet. For example, the user may have a personal computer 2, a communicating digital personal assistant 3 (communicating PDA) or a mobile telephone 4 (eg GPRS telephone or UMTS). According to the example considered here, the user first accesses a relay DNS server 5 in which the DNS filtering specific to the invention is implemented (ie the relay DNS server 5 being used here as the filtering server DNS domain name of the invention). The relay DNS server 5 is placed between the user's computer terminal and the recursive local DNS server 6, the latter having access to authoritative DNS servers 7 responsible for responding to requests from the recursive local server 6. In a well-known manner, the content that user 1 wants to access by a DNS resolution request from a computer terminal are hosted on servers located at various locations on the computer network. For simplicity, all these content servers, including HTTP servers, are shown in Figure 1 by a content server 40.

The system of the invention further comprises a barrier server 10 and a secondary filtering server 20 whose operation will be described later in detail.

As can be seen in FIG. 1, the DNS filtering server 5 of the invention receives and filters all the domain name resolution requests 41 sent to obtain an IP address. In this respect, it is able to filter access regardless of the protocol requested next. A response 42 is then sent. As described in detail below, depending on this response, there is automatic redirection to the content server 40, to the barrage server 10 or to the secondary filtering server 20. The majority of the traffic 43 is authorized, and not then meets more filtering system (gain in costs, performance and quality of service). A majority of the remaining 44 requests are blocked. Only a small part of the remaining traffic 45 requires a more precise analysis and then relies on secondary filtering systems.

FIG. 5 schematically illustrates an example of a state-of-the-art HTTP filtering architecture comprising a DNS server 105 for receiving the domain name resolution requests 108 sent by a user 101 by means of a terminal (a personal computer 102, communicating digital personal assistant 103 or a mobile phone 104) to obtain an IP address in response 109. The contents accessible by any type of flow (HTTP, FTP, P2P, etc.) are materialized by a content server 107. A filtering server 106 supporting the HTTP protocol is intended to filter the content requests sent by the user 101 after obtaining the IP address obtained. Unlike the DNS filtering server of the invention, it can be seen that the so-called "traditional" filtering server only positions itself in breaks of the streams that it is able to apprehend, here the HTTP streams 110. other streams 112 are not filtered. In addition, this type of filtering requires the analysis of all the requests concerning the streams 110 that it apprehends before authorizing a majority 111.

First of all, in relation with FIG. 2, the steps implemented during a DNS filtering operation in accordance with the invention are described.

One embodiment of the invention is parental control within the framework of an Internet Service Provider (ISP). In this context, the invention is based on a preliminary step which is the authentication of the user during his connection.

This step, known from the state of the art, consists of identifying the user during the initialization of his connection and storing his connection parameters (IP address) in a database. This step allows the various elements of the invention to find the profile of a client based on its IP address by querying a customer base 8.

In addition, customers can dynamically update their profile via an HTTP server with a Web interface provided that they provide a password that may be the same or different from the one used for the authentication request. This solution allows several users to use the same machine with different profiles.

The DNS filtering system consists of six large functional blocks; a DNS server module 51, responsible for receiving the requests from the clients and for returning the responses (filtered or not) to these clients; an identification module 52 responsible for extracting from the database of the clients 8 the profile of the client at the origin of the request received. This profile will contain information (such as "child", "teenager", "adult") that will allow the service to determine the level of filtering to be adopted. This module is based on the customer base presented in the preliminary identification step.

Obtaining the client profile is done by searching the client database for the profile attached to the original IP address of the DNS request. This IP address / Profll association is only valid for the duration of the user's connection. In addition, users have the possibility in this context to dynamically change the profile attached to their IP address in order to switch from a "parent" profile to a "child" profile for example. - A query filtering module 53. This module analyzes the client's request and uses the profile retrieved during the previous step to determine whether the request must be authorized, filtered or if it requires a secondary filtering system. For this, the analysis module relies on one or more white lists or black lists containing authorized and prohibited domain names.

Each profile will be associated with specific lists according to the desired service. As a nonlimiting example of the implementation possibilities, a profile "child" will be rather associated with one or more white lists. A "teenager" profile will be associated with one or more blacklists. Finally, an "adult" profile will not be filtered.

In general, we will attach to each profile a list of information including:

- the information whose access is allowed for this profile;

- the information whose access is forbidden for this profile; - information requiring analysis using secondary filtering to determine if they are accessible or not by this profile; a DNS relay module 54 transmitting the client's request to the DNS servers capable of solving it;

a response filtering module 55. This module analyzes the response of the DNS servers, and uses the profile retrieved by the identification module to determine whether the response must be authorized, filtered or if it requires a secondary filtering system. . For this, the analysis module relies on one or more white lists or black lists containing authorized and prohibited domain names. These lists may be identical or different from those of the query analysis module, the process remaining the same in both cases; a response generation module 56 comprising four sub-modules 561 to 564.

These different modules as well as the steps implemented are shown in FIG. 2. The modules 51 to 56 can be implemented within a server located in the DNS resolution chain, such as the relay DNS server 5 of FIG.

Example of implementation of a DNS filtering device or server The steps shown in FIG. 2 are as follows: A user makes a request from a client application 9 (eg browser) installed on its terminal. DNS resolution.

This request is received by the DNS server module 51, which implements the protocol defined by the DNS standard (step S1).

The request of the user is transmitted to the identification module

52. This extracts from the request the IP address of the user (step S2). The identification module 52 queries the client base 8 to find the profile of the user associated with the extracted IP address (step S3). The identification module 52 retrieves the profile associated with this IP address, for example "child", "teenager" or "adult". In the case where the customer base 8 does not provide the profile associated with an address (error case), the identification module 52 can apply a default profile

(for example, the "child" profile) (step S4). The identification module 52 submits the request of the user with the profile associated with a first level of analysis consisting in determining whether in the profile of the user it is indicated that it implies or not a filtering (step S5 ). When the profile associated with the query does not involve any analysis

(case of the "adult" profile in our example), no further analysis is applied and the request is transmitted to the DNS relay module 54 (step S6).

When the profile associated with the request requires analysis (case of "child" and "teenager" profiles in our example), the request is transmitted to a request filtering module 53 (step S7).

The query filtering module 53 confronts the user's request with one or more white lists 58 (case of the "child" profile) or with one or more blacklists 57 (case of the "teenager" profile) (step S8). In the case of the "child" profile, the white lists contain in an exhaustive manner the domain names that a child is allowed to consult. In the case of the adolescent profile, blacklists contain the domain names that a teenager is not allowed to view, as well as domain names that require analysis by a secondary filtering system. During this step, it is mainly to filter the so-called "normal" DNS resolution requests (i.e. requests to obtain an IP address from a domain name).

The result of this confrontation is transmitted to a first level of filtering which determines whether the request must be filtered or not according to this result (step S9).

When the user's request is not allowed (domain name that is not part of the white lists in the case of a "child" profile, or domain name that is part of the blacklist for a "teenager" profile) , the request is returned to the sub-module 561 of the DNS response module 56, which constructs a DNS message containing the IP address of a barrier server (step SlO).

When the request of the user is not explicitly prohibited, it is transmitted to a second level of filtering (step SI1) to determine whether or not it should be the subject of secondary filtering (step S12). When the user's request coincides with a domain name involving a secondary filtering system, the request is returned to the sub-module 562 of the DNS response module 56, which constructs a DNS message containing the IP address of the secondary filtering system. (Step S13). When the request of the user is authorized, it is transmitted to the DNS relay module 54 (step S14).

The DNS relay module 54 transmits, to the authoritative DNS servers 7, possibly via a recursive local DNS server (not shown), the DNS resolution request according to the protocol and the DNS standard in order to obtain a DNS resolution (step S15).

A DNS resolution response is obtained in return and is received by the DNS relay module 54 (step S16).

The module 54 transmits the DNS resolution response (with the user profile causing the request) to the response filtering module 55 (step S18).

The response filtering module confronts the response with one or more white lists 58 (case of the "child" profile) or with one or more blacklists 57 (case of the "teenager" profile) (step S19). These lists may be identical to or different from those used in step S8. This step has the advantage of being able to filter the so-called reverse resolution requests (requests for obtaining a name from an IP address), as well as partially filtering certain responses, for example, in a non-limiting manner, the deletion of information in the additional fields of the DNS response. The steps S20 to S24 are identical to the steps S9 to S13 respectively, the only difference being that it is the DNS resolution response that is considered here.

When the response is not directly prohibited and does not require a secondary filtering system, it is transmitted to a third level of filtering (step S25) which will determine whether or not the response requires partial filtering of the information contained in this response.

(Step S26).

When the response contains only information that can be transmitted to the user, it is sent as it is to the sub-module 563 of the DNS response module 56 which will transmit it to the user without modification (step S27). When the response contains information not to be transmitted to the user, the information not to be transmitted is deleted, and the request is transmitted to the sub-module 564 of the response module which will generate a response containing only the authorized information ( step S28). This information may relate to any parameters that can be transmitted by the DNS protocol (additional DNS fields, specific response types such as an ENUM record ("TElephone NUmber Mapping"), Session Initiation Protocol (SIP) number, etc.). For example, you can delete any information other than the correspondences (eg domain names <=> IP addresses) in the case of a child profile.

The response module transmits a DNS-compliant response to the DNS server module 51 (step S29) which transmits the response to the client software 9 of the user initiating the request (step S30). Partial filtering (step S28) is an interesting feature because it makes it possible to extend DNS filtering to new uses such as ENUM (protocol and technology based on the porting of E.164 telephony numbers on the DNS protocol which allows use the servers and the DNS protocol to store the reachability information of a user and thus offer a universal system for connecting users regardless of the means of access (traditional telephony, mobile or IP, messaging , videophone, etc.)). An example of ENUM use is to restrict access to personal phone numbers according to the profile of the requester. It will be noted in step S3 that the filtering profile is obtained from the IP address at the origin of the request. The determination of the filter profile will depend on the context of implementation of the invention.

In Intranet / Enterprise and Internet context, it is possible to have only one profile applicable to all users. The IP address at the origin of the request is not used in this case, and this identification step is then optional.

In the Intranet / Enterprise context, profiles can be associated with specific IP address ranges. Thus, a profile (for example, limited access to professional sites) will be associated with a range of IP addresses A (192.168.1.x for example). A user connecting to the corporate network with his username and password will be allocated an IP address according to the address range corresponding to its profile.

The previous mechanism can be extended to a multi-enterprise solution, each enterprise being characterized by a given IP address range.

Still in the Intranet / Enterprise context, it is possible to dynamically store the profile of a user associated with an IP address. To do this, we will rely on existing standard solutions such as Dynamic Host Configuration Protocol (DHCP) servers in Intranet, Radius servers in an Internet context or user session databases.

The two solutions above are adapted to the case where a user is associated with a physical machine during a given period. In a consumer Internet context, it may be necessary to provide a mechanism based on user identification (for example when parents and children use the same machine to connect to the Internet).

For this, it is necessary to add information characterizing the user to previous solutions. This information can be updated dynamically by the user using associated passwords: - by installing software on the client terminal, allowing to select a profile (parent / child) to associate with the user. identifier of the machine and dynamically updating this information at the level of DHCP, Radius or other servers, or - by the use of a Web application accessible by the users, allowing to select a profile (parent / child) to associate to the identifier of the machine and dynamically updating this information at the DHCP, Radius or other servers. In all cases, these user profile identification solutions rely on known mechanisms.

Principle of the dam server

The multiplicity of protocols supported by the invention (whether standard or not) as well as the impossibility of transmitting an explicit error message via the DNS protocol has led to the creation of a dam server. This dam server aims to indicate to the client at the origin of the request that it has been filtered, and this in a user-friendly manner.

The barrage server intervenes when the DNS filtering appliance or server detects that a client needs to be filtered. This server returns to the user the IP address of the dam server in place of the address

IP of the server requested by the client. The client then establishes a connection to the barrier server with any protocol.

The role of the barrage server is to detect a client connection attempt, as well as the application protocol used by this client. If the application protocol used by the client is known and implemented by the barrage server, the barrage server then returns to the client a filtering message using this protocol. If the application protocol used by the client is unknown or not implemented by the barrage server, the barrage server then returns to the client a filter message using a third party protocol.

Among the application protocols that can be used by a client and implemented by the dam server include: HTTP, WAP, SMTP, FTP, Telnet, Streaming, etc.

The dam server has a particular advantage especially when the client uses an unknown protocol. Indeed, in this case, the dam server implemented;

- A connection detection mechanism. This mechanism is similar to those used by firewalls or intrusion detection systems, and involves logging any connection attempt to the barrage server.

- An offline filtering notification mechanism. This mechanism will vary depending on the implementation framework of the invention, but two implementations may be proposed:

- Generally speaking, an e-mail or instant notification mechanism.

- In the context of mobile access, an SMS notification mechanism (Short Message Service).

The client's notification addresses will be stored with the client's profile (the .vs accessible via the IP address at the origin of the request). Thus, a client initiating a filtered connection attempt will receive a message explaining that its access has been blocked: - Directly if the application protocol used is recognized and implemented by the dam server - In an indirect way, by electronic mail or SMS, if the application protocol used is not recognized or is not implemented by the barrier server.

Example of implementation of the device or dam server is described, in connection with Figure 3, the steps implemented in a barrier server 10 which is requested during steps SlO or S21 of Figure 2.

Initially, the user application 9 of the user requests a connection to the barrage server 10 from the IP address that has been communicated to him in response to his DNS resolution request (step SlO or S21 of FIG. 2). (step S40).

The connection request is received by a connection request reception and analysis module 11 which determines whether the requested protocol is supported or not by the barrier server (step S41). If this is the case, the module 11 orients the request to the associated application (step S42), that is to say to one or more server application modules 12 to 15, capable of supporting connection requests. users, to generate and return to them an explicit filtering notification (step S49). These modules can support (not limited to) the application protocols http (module 12), FTP (module 13), SMTP (module 14) and Telnet (module 15).

If the requested protocol is not supported by the barrage server, the connection request reception and analysis module 11 directs the request to an offline filtering notification module 16 (step S43). In this case, the request is first transferred to a user identification module 17 which, like the module 52 of FIG. 2, relies on the IP address of the users to find, in the client database 8 , their profile (steps S44 and S45). The role of this module is thus to find information to contact the user indirectly. An example of implementation is thus the recovery of the e-mail address of the user. This However, this example does not limit the possibilities of implementing other information, such as the telephone number, that can be exploited.

The module 17 generates a filtering notification message and transmits it to one or more module (s) 16 for transmitting an offline message to the client (step S46). An exemplary implementation is thus an e-mail module capable of sending an electronic message to the user's mail server via the client's e-mail server 18 (steps S47 and S48).

Secondary filtering principle

Secondary filtering applies in the case where DNS filtering:

- has detected that the site requested by the client contains potentially filterable content. This case applies in particular to the search engines of websites or images, but also to portals sites not performing a clear separation of the contents (personal pages of Wanadoo for example), or

determined that the filtering decision involves a content analysis, or has thus responded to a client's DNS resolution request by the IP address of the secondary filtering system. In the latter case, the client initiates its connection to the secondary filtering system as if it were the requested content server. The secondary filtering system therefore acts as a "classic" proxy server, bridging the client and the final content server.

The secondary filtering system, by positioning itself as a relay between the client and the final server, is thus able to determine the exact nature of the content requested by the client. From this moment, the "traditional" filtering solutions known from the state of the art can thus be implemented. Among these, we can mention:

- HTTP filtering solutions, using blacklists or whitelists of URLs, or content analysis solutions;

- FTP filtering solutions (file transfer system); - e-mail filtering solutions;

- instant messaging filtering solutions; Example of implementing an HTTP-based secondary filtering device or server

HTTP filtering systems are an integral part of the state of the art. Nevertheless, a description of an implementation in an HTTP filtering server 20 which is requested during the steps S13 or S24 of FIG. 2 is described with reference to FIG. 4. This example is similar to the DNS filtering shown in FIG. 2, with two exceptions: - the option of using a secondary filtering system is removed, and

- the filtering is based in this case on the content requested by the users and not only on the name of the server.

Initially, the user's client application 9 requests a connection to the HTTP filtering server 20 from the IP address that has been communicated to him in response to his DNS resolution request (step S13 or S24 of FIG. ) (step S50). This request is received by an HTTP server module 21 which transmits the user's HTTP request to an identification module 22 (step S51). It extracts from the request the IP address of the user by querying the client base 8 and retrieves the profile associated with this IP address (steps S52 and S53).

The identification module 22 submits the request of the user with the profile associated with a first level of analysis consisting of determining whether in the user's profile it is indicated that the latter implies or not HTTP filtering (step S54).

When the profile associated with the request does not involve any analysis, the request is directly transmitted to the HTTP relay module 24 (step S55). When the profile associated with the request requires analysis, the request is transmitted to a request filtering module 23 (step S56).

The request filtering module 23 confronts the user's request with one or more white lists 28 or with one or more blacklists 27 (step S57).

The result of this confrontation is analyzed to determine whether the query should be filtered or not based on this result (step S58). When the request of the user is not allowed, the request is returned to a sub-module 261 of an HTTP response module 26, which constructs a filtered HTTP response (step S59).

When the request of the user is authorized, it is transmitted to the HTTP relay module 24 (step S60).

The HTTP relay module 24 transmits, to the HTTP servers 30 having the content requested in the request, the HTTP request in order to obtain an HTTP response (steps S61 and S62).

The module 24 transmits the HTTP response (with the user profile at the origin of the request) to a response filtering module 25 (step S63).

The response filtering module confronts the response with one or more white lists 28 or one or more blacklists 27 (step S64). The steps S65 and S66 are identical to the steps S58 and S59 respectively, the only difference being that it is the HTTP response that is considered here.

When the response contains only information that can be transmitted to the user, it is sent as it is to the sub-module 262 of the HTTP response module 26 which will transmit it to the user without modification (step S67).

The response module 26 transmits an HTTP compliant response to the HTTP server module 21 (step S68) which transmits the response to the client software 9 of the user initiating the request (step S69).

The invention therefore proposes an optimized filtering solution which relies on a first level of filtering based on the domain name protocol or DNS, and which makes it possible to call only, if necessary, more precise analysis systems. like HTTP filtering for example.

The invention thus advantageously uses the central position of the DNS protocol to establish a first level of filtering, thus effectively applying to the majority of Internet protocols. The very high performance of this DNS protocol improves filter performance while reducing sizing costs. This invention is also compatible with the standards and standards in force.

The invention is also distinguished by its simplicity of implementation and its scalability. Indeed, the configuration of the DNS of the customers is done in the majority of the cases automatically when they are connected, by means of traditional protocols like DHCP or PPP. It is thus easy to modify this configuration centrally so that customers use the invention in place of their local DNS server. Finally, the application framework of the invention is not limited to the protocols and contexts recognized at present, but also to any new protocol and context that can be created from the moment this protocol or context is based on the DNS protocol. An example of this genericity of the invention is thus the ENUM protocol.

Claims

A filtering method for controlling access to content by a user (1) from a computer terminal (2; 3; 4) including means for sending requests for content requests to content (40) accessible via a communication network, access to the content servers (40) comprising a prior step of DNS domain name resolution comprising sending a DNS resolution request from said computer terminal to obtain a response containing the IP address of the content server corresponding to the domain name indicated in the request, characterized in that it comprises the following steps: a) determining the profile of the user (1) from the data of the a domain name resolution request issued by the computer terminal (2; 3; 4) to check if a content filtering is defined in said profile; b) in case of negative verification, authorization of the request and the reply domain name resolution response, c) in case of positive verification, comparison of the domain name present in the request and / or in the response with a list of domain names (57; 58) predefined according to the profile of the user (1) of the computer terminal (2; 3; 4), d) filtering the query or the domain name resolution response when the result of the comparison indicates that the domain name present in the request or in the response must be filtered, said filtering comprising one of the following two steps: dl) blocking the request or response and sending a filtering notification to the user (1), or d2) returning the request or response to a secondary filtering device (20).

2. Method according to claim 1, characterized in that, in step c), the domain name present in the domain name resolution request is compared with a list of prohibited domain names (57) corresponding to all domain names to be filtered or with a list of authorized domain names (58) corresponding to the only domain names that should not be filtered.

3. Method according to claim 1 or 2, characterized in that, in step d), said filtering further comprises a partial filtering step d3) of removing a part of the information contained in the name resolution response of domain transmitted to the terminal (2; 3; 4) of the user (1), the information contained in the response being compared with a list of prohibited domain name information corresponding to all the information to be deleted in the response or to a list of authorized domain name information corresponding to the only information to be included in the response.

4. Method according to any one of claims 1 to 3, characterized in that, in step dl), the filtering notification is directly transmitted to the user (1) by means of an application message incorporating the protocol used or indirectly through a message sent to the offline user.

A DNS domain name filtering server (5) for receiving a DNS domain name resolution request issued from a computer terminal (2; 3; 4) of a user (1), characterized in that it comprises means (52) for determining the profile of the user (1) from the data of the domain name resolution request issued by the computer terminal (2; 3; 4) and for checking whether content filtering is defined in said profile, means (54) for authorizing the request and the domain name resolution response in the case of a negative verification, means (53) for comparing the domain name present in the request and / or in the response with a list of predefined domain names (57; 58) according to the profile of the user, in case of positive verification, and means for filtering the request or the domain name resolution response when the result of the comparison indicates that the domain name in the request or in the response must be filtered.

The DNS domain name filtering server (5) according to claim 5, characterized in that it further comprises means (561) for blocking the request or the response and for returning a domain name resolution response. DNS containing the IP address of a barrage server (10), said barrage server sending a filtering notification to the user.

The DNS domain name filtering server (5) according to claim 5 or 6, characterized in that it further comprises means (562) for returning the request or response to a secondary filtering device (20) .

A computer program that can be implemented by a DNS domain name filtering server (5) according to any one of claims 5 to 7, said server being adapted to receive a DNS domain name resolution request. issued from a computer terminal (2; 3; 4) of a user (1), characterized in that it comprises instructions for:

determining the profile of the user (1) from the data of the domain name resolution request sent by the computer terminal (2; 3; 4) and to check if a content filtering is defined in said profile,

- allow the request and the response of resolution of domain name in case of negative verification, - compare the domain name present in the request and / or in the response with a list of predefined domain names (57; 58) according to the profile of the user, in case of positive verification, and

- filtering the domain name resolution request or response when the result of the comparison indicates that the domain name present in the request or in the response must be filtered.

9. Filtering system for controlling access to content by a user (1) from a computer terminal (2; 3; 4) including means for sending a request for content request to servers contents (40) accessible via a communication network, the computer terminal (2; 3; 4) sending, prior to accessing the content servers (40), a DNS domain name resolution request for a response containing the IP address of the content server corresponding to the domain name indicated in the request, characterized in that said system further comprises a DNS domain name filtering server (5) according to one of claims 5 to 7.

10. System according to claim 9, characterized in that it further comprises a barrier server (10) comprising application means (12-15) reacting to connection requests to return a filtering notification message, each means application capable of supporting a specific application protocol, said barrier server further comprising means (11) for checking whether the application protocol used in the connection request corresponds to one of the application protocols supported by the application means, and means (16, 17) for extracting, from the IP address of the user issuing the connection request, information for indirectly contacting the user and for sending a filtering notification message using said information, in case negative verification.

System according to Claim 10, characterized in that the barrier server comprises means for extracting from a database the e-mail address of the user issuing the connection request and for sending an e-mail notification message. filtering to an email server using the extracted email address.