FR3108007A1 - Procédé et dispositif de détection de l’usage d’un serveur de noms de domaine non certifié. - Google Patents

Abstract

L'invention concerne un procédé et un dispositif de notification, par un dispositif de notification, de l’usage, par au moins un terminal, d’un serveur de noms de domaine non certifié, le procédé étant caractérisé en ce qu’il comprend : - une étape de réception d’une requête en provenance dudit au moins un terminal, ladite requête comprenant au moins un paramètre correspondant à une première adresse permettant la communication avec un serveur ; - une étape de recherche de ladite première adresse dans une liste, ladite liste comprenant au moins une adresse obtenue depuis au moins un serveur de noms de domaine certifié ; - une étape de notification, en fonction du résultat de la recherche, de l’usage, par ledit au moins un terminal, d’un serveur de noms de domaine non certifié. Figure pour l'abrégé : Figure 2

Description

Procédé et dispositif de détection de l’usage d’un serveur de noms de domaine non certifié.

1. Domaine de l'invention

L'invention se rapporte au domaine général des réseaux de télécommunications, et plus particulièrement à la technologie DNS (en anglais «Domain Name System»).

2. Art Antérieur

Lorsqu’un utilisateur souhaite accéder à un site Internet, comme par exemple un site marchand, celui-ci va classiquement utiliser un navigateur Internet présent sur son terminal. Pour accéder au site marchand, le navigateur ou le terminal peut interroger un serveur de noms de domaine, également appelé serveur DNS (en anglais «Domain Name System»), afin d'établir une correspondance entre l’URL (en anglais «Uniform Resource Locator») du site marchand, par exemple saisie par l’utilisateur, et l’adresse IP (Internet Protocol) du serveur qui l’héberge. Ce mécanisme est appelé «résolution DNS». En effet, sur Internet, c’est l’adresse IP qui est utilisée pour communiquer entre les différents terminaux du réseau.

Les messages échangés avec les serveurs DNS sont des messages dits «en clair», c’est-à-dire sans chiffrage. Cette caractéristique permet aux fournisseurs d’accès à Internet qui opèrent les serveurs DNS de proposer à leurs clients des services additionnels tels que des services de contrôle parental ou des services de détection de sites Internet malveillants. Concrètement, ces services se basent sur les URL pour lesquelles une correspondance avec une adresse IP est demandée pour par exemple réaliser un filtrage de l’URL ou envoyer un message particulier au client.

Depuis quelques années, certains acteurs proposent des serveurs DNS publics qui se substituent à ceux mis historiquement en place par les fournisseurs d’accès à Internet. A date près de 50% des résolutions DNS sont réalisées via ces serveurs DNS publics. Ce pourcentage est de plus en augmentation avec l’usage accru de protocole DNS sécurisé de type DoH (DNS over HTTPS avec la RFC IETF 8484) ou DoT (DNS over TLS). En effet, certains navigateurs Internet permettent l’utilisation de ces protocoles avec par défaut la configuration possible par son utilisateur d’un serveur DNS public.

Si ces services de résolution DNS publics sont dans certains cas pertinents pour les utilisateurs (meilleur temps de réponse annoncé par exemple pour des jeux en réseau, chiffrement des requêtes et réponses DNS pour une meilleure sécurité, etc…), ils entrainent cependant la perte de certains services proposés par les fournisseurs d’accès à Internet. En effet, les serveurs DNS du fournisseur d’accès à Internet n’étant pas utilisés par les terminaux des utilisateurs, les services basés sur les résolutions DNS comme par exemple le contrôle parental, ne fonctionneront plus. Cela peut par exemple engendrer des insatisfactions utilisateur et des coûts de services après-vente importants pour les fournisseurs d’accès à Internet. En effet, il peut être assez difficile à un conseiller du service d'assistance téléphonique de déterminer que le problème provient de l’utilisation d’un serveur DNS public par un terminal ou une application exécutée sur le terminal.

De manière plus générale, l’utilisation de ces serveurs DNS publics peut également engendrer une augmentation du trafic IP international. En effet, ces serveurs DNS publics, hébergés pour la plupart aux Etats-Unis, ne permettent pas l’utilisation de «cache DNS» local (mémoire qui stocke les paires «Noms de domaine - adresses IP» qui viennent d'être résolues, afin de les retrouver plus rapidement), disponible par exemple au sein du réseau d’un fournisseur d’accès Internet, donc valable pour l’ensemble de ses clients, ou bien au sein d’une passerelle domestique d’un fournisseur d’accès à Internet, donc valable pour l’ensemble des terminaux et applications gérés par celle-ci, qui permettrait d’avoir une réduction substantielle du trafic DNS et un impact énergétique/environnemental plus faible. L’utilisation de DNS Publics pose également un problème concernant la protection des données à caractère personnel. Un acteur malveillant qui proposerait un tel service pourrait récupérer des données sensibles des utilisateurs et les revendre sans que les utilisateurs en aient conscience.

3. Exposé de l'invention

L'invention vient améliorer l'état de la technique et propose à cet effet un procédé de notification, par un dispositif de notification, de l’usage, par au moins un terminal, d’un serveur de noms de domaine non certifié, le procédé étant caractérisé en ce qu’il comprend:

- une étape de réception d’une requête en provenance dudit au moins un terminal, ladite requête comprenant au moins un paramètre correspondant à une première adresse permettant la communication avec un serveur;

- une étape de recherche de ladite première adresse dans une liste, ladite liste comprenant au moins une adresse obtenue depuis au moins un serveur de noms de domaine certifié;

- une étape de notification, en fonction du résultat de la recherche, de l’usage, par ledit au moins un terminal, d’un serveur de noms de domaine non certifié.

Avantageusement, selon l'invention, le procédé va pouvoir détecter l’usage, par un terminal d’un utilisateur, d’un serveur de noms de domaine non certifié. A la réception d’une requête émise par le terminal, le procédé va vérifier qu’une résolution DNS a bien été effectuée par un serveur DNS certifié. Pour cela, le procédé va récupérer dans la requête reçue, un paramètre tel que l’adresse du serveur destinataire et vérifier que cette adresse est présente au sein d’une liste comprenant les adresses fournies au terminal par les serveurs DNS certifiés. Cette liste est par exemple remplie au fil de l’eau lors des résolutions DNS. Si l’adresse du serveur destinataire n’est pas présente dans la liste, alors le procédé va générer une notification informant que le terminal utilise un serveur de noms de domaine non certifié. Dans le cas contraire, cela signifie que la résolution DNS a bien été réalisée par un serveur DNS certifié et aucune notification n’est générée.

A noter que ce procédé est applicable quel que soit le protocole DNS utilisé, même pour les protocoles DoH/DoT dans lesquels les échanges DNS entre le terminal et un server DNS non certifié sont cryptés de bout en bout grâce au protocole HTTPS/TLS.

On entend par serveur DNS certifié, les serveurs de noms de domaine qui sont dits «de confiance» sélectionnés par une organisation habilitée comme par exemple le fournisseur d’accès à Internet de l’utilisateur du terminal. Bien entendu, les critères de sélection relatifs à la notion de confiance peuvent être propres à chaque organisation. Ainsi, les serveurs DNS certifiés peuvent être différents selon les organisations.

On entend par liste une suite d’éléments ordonnés ou non, distincts ou non, permettant d’obtenir un ensemble structuré tel qu’une liste d’éléments, par exemple horodatés, d’adresse IP, de nom de domaine, d’adresse MAC, de numéro de port ou bien de protocole. Cette liste est par exemple un cache DNS apte à stocker les paires «noms de domaine - adresses IP» qui viennent d'être résolues pour un terminal ou les applications exécutées sur le terminal.

On entend par adresse une suite de caractères et/ou de données binaires qui sert à identifier un terminal ou un de ses modules électroniques comme par exemple un serveur, une passerelle domestique, un smartphone (en anglais «téléphone intelligent»), un ordinateur, un objet connecté, une carte réseau ou tout autre terminal connecté à un réseau comme par exemple une URI.

On entend par serveur tout terminal connecté à un réseau tel qu’un serveur Internet, un smartphone (en anglais «téléphone intelligent»), un ordinateur, un objet connecté, etc.

On entend par terminal tout terminal connecté à un réseau ou application s’exécutant sur un terminal apte à communiquer avec un autre terminal.

On entend par requête tout message envoyé par un terminal ou par une application s’exécutant sur un terminal à destination d’un serveur comme par exemple un message HTTP, un paquet IP, etc.

On entend par serveur de noms de domaine un serveur DNS («Domain Name System») ou un serveur dit «Resolver DNS» qui inclut des moyens de consultation périodique des serveurs DNS racine (.org, .com, .net,…) et ceux qui sont sous le contrôle administratif de différentes entités (entreprises, états, associations, etc….) ainsi que des moyens de cache DNS.

Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que les étapes de recherche et de notification sont conditionnées au résultat d’une deuxième étape de recherche de ladite au moins une première adresse dans une deuxième liste, ladite deuxième liste comprenant les adresses de destinations des requêtes émises par ledit au moins un terminal.

Avantageusement, ce mode de réalisation permet de conditionner les étapes de recherche et de notification à la présence dans une liste de l’adresse de destination de la requête émise par le terminal de l’utilisateur. Cette liste peut par exemple être une liste d’adresses IP déjà connues d’une passerelle domestique telle qu’une table de NAT («Network Address Translation») ou NAPT («Network Address Port Translation) dans le cas de l’usage du protocole IPV4 ou bien encore une table de routage de paquets IPV6. Cela peut encore être par exemple une table NAPT d’un équipement réseau de type CGN (Carrier Grade NAT) qui assure une fonction de tunnel IPV4-IPV6.

Ce mode de mise en œuvre de l'invention permet également de vérifier que l’adresse de destination de la requête émise par le terminal de l’utilisateur, comme par exemple une adresse IP, est présente dans une liste stockée dans un espace de stockage numérique tel qu’une base de données, un fichier, ou une mémoire. L’espace de stockage numérique peut par exemple héberger des données liées aux serveurs DNS Publics non certifiés (liste noire).

Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape de recherche comprend en outre la recherche d’une seconde adresse associée à ladite première adresse dans ladite première liste, ladite seconde adresse étant un paramètre de ladite requête et correspondant à une adresse dudit au moins un terminal, ladite première liste comprenant au moins une adresse dudit au moins un terminal obtenue depuis ledit au moins un terminal associée à au moins une adresse obtenue depuis ledit au moins un serveur de noms de domaine certifié.

Avantageusement, ce mode de réalisation permet de prendre en compte le cas où plusieurs terminaux sont gérés par le dispositif de notification et que par exemple l’un d’entre eux utilise un serveur DNS non certifié.

En effet, la résolution d’un nom de domaine a pu être réalisée par un serveur DNS certifié pour le compte d’un des terminaux avant qu’une demande similaire ne soit faite par le terminal utilisant le serveur DNS non certifié. Par conséquent, on aura dans la liste, l’adresse du serveur correspondant au nom de domaine recherché par le terminal utilisant le serveur DNS non certifié. L’adresse du serveur n’est donc, dans ce cas, pas suffisante pour détecter l’usage d’un serveur de DNS non certifié. Pour ce faire, une deuxième adresse telle qu’une adresse MAC ou une adresse IP ou un identifiant unique de type IMEI (International Mobile Equipement Identifier) associée au terminal est nécessaire. Ainsi, cette deuxième adresse permet de trouver dans la liste les résolutions DNS d’un terminal en particulier.

Selon un mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape de recherche comprend en outre la recherche d’au moins un numéro de port de communication associé à ladite adresse dans ladite première liste, ledit au moins un numéro de port de communication correspondant à un paramètre de ladite requête, ladite première liste comprenant au moins un numéro de port de communication obtenu depuis ledit au moins un terminal associé à au moins une adresse obtenue depuis ledit au moins un serveur de noms de domaine certifié.

Avantageusement, ce mode de réalisation permet de prendre en compte le cas où plusieurs applications s’exécutent sur le terminal de l’utilisateur avec par exemple pour l’une d’entre elles l’utilisation d’un serveur DNS non certifié. En effet, la résolution d’un nom de domaine a pu être réalisée par un serveur DNS certifié avant qu’une demande similaire ne soit faite par l’application utilisant le serveur DNS non certifié. Par conséquent, on aura dans la liste, l’adresse du serveur correspondant au nom de domaine recherché par l’application utilisant le serveur DNS non certifié. L’adresse du serveur n’est donc, dans ce cas, pas suffisante pour détecter l’usage d’un serveur de DNS non certifié. Pour ce faire, le numéro du port de communication source correspondant à l’application utilisant le serveur DNS non certifié est nécessaire. En effet, dans le cas d’une communication TCP/IP, la pile TCP/IP du terminal ne peut pas affecter au même moment le même numéro de port source à différentes applications sans quoi la pile TCP/IP ne saurait pas vers quelle application router le trafic IP entrant. Le procédé peut ainsi notifier de l’usage par une application du terminal d’un serveur de DNS non certifié.

Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape de notification comprend une redirection de ladite requête vers au moins une page Internet.

Ce mode de mise en œuvre de l'invention permet d’informer l’utilisateur via l’affichage d’une page internet au niveau de son terminal qu’il utilise un serveur de noms de domaine non certifié avec les risques encourus.

Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape de notification comprend l’envoi d’un message à destination dudit premier terminal.

Ce mode de mise en œuvre de l'invention permet d’informer l’utilisateur via par exemple un SMS, un message RCS, un courriel ou un message de notification envoyé par exemple grâce à une solution de type FCM (Firebase Cloud Messaging) qu’il utilise un serveur de noms de domaine non certifié avec les risques encourus.

Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape de notification comprend l’envoi d’un message à destination d’un service d’assistance.

Ce mode de mise en œuvre de l'invention permet par exemple d’informer le service client du fournisseur d’accès à Internet de l’utilisateur du premier terminal que celui-ci utilise un serveur DNS non certifié. Le technicien du service client pourra alors plus facilement comprendre d’où vient un défaut de fonctionnement constaté par l’utilisateur sur un de ses services basés sur les résolutions DNS tel que le contrôle parental et aider l’utilisateur à résoudre le problème.

Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape de notification est suivie d’une étape de filtrage des requêtes en provenance dudit premier terminal.

Ce mode de mise en œuvre de l'invention permet, lorsque l’utilisateur du premier terminal utilise un serveur DNS non certifié, de procéder à un filtrage des requêtes émises par le premier terminal. Le filtrage peut être partiel ou total, c’est-à-dire que le filtrage peut bloquer toutes les requêtes ou en laisser passer une partie comme par exemple celles à destination de l’assistance en ligne du fournisseur d’accès à Internet de l’utilisateur du premier terminal. Le filtrage peut aussi correspondre à une mise en attente des requêtes pendant une durée (par exemple une seconde) provocant par exemple un ralentissement des flux Internet au niveau du premier terminal.

Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape de notification est suivie d’une étape de modification des requêtes émises par ledit premier terminal.

Ce mode de mise en œuvre de l'invention permet par exemple, lorsque l’utilisateur du premier terminal utilise un serveur DNS non certifié, de «marquer» les requêtes émises par le premier terminal. Les équipements réseaux qui reçoivent ces requêtes peuvent alors appliquer des règles de traitement spécifiques comme par exemple la comptabilisation, la non prise en charge, le blocage, le routage spécifique, ou bien la duplication du trafic.

L'invention concerne également un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié, et caractérisé en ce que le dispositif comprend:

- un module de réception d’une requête en provenance dudit au moins un terminal, ladite requête comprenant au moins un paramètre correspondant à une première adresse permettant la communication avec un serveur;

- un module de recherche de ladite première adresse dans une liste, ladite liste comprenant au moins une adresse obtenue depuis au moins un serveur de noms de domaine certifié;

- un module de notification, en fonction du résultat de la recherche, de l’usage par ledit au moins un terminal d’un serveur de noms de domaine non certifié.

Le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).

L’invention concerne également une passerelle caractérisée en ce qu’elle comporte un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.

On entend par passerelle un dispositif permettant de relier deux réseaux informatiques de type différent, comme par exemple un réseau local et un réseau Internet, telle qu’un modem-routeur, un téléphone mobile avec le mode «partage de connexion» activé, etc.

L’invention concerne également un serveur caractérisée en ce qu’il comporte un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.

L’invention concerne également un terminal caractérisée en ce qu’il comporte un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.

Avantageusement ce mode de réalisation permet de prendre en compte le cas où le terminal dispose par exemple d’un cache DNS.

L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé ci-dessus selon l'un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Le procédé peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

L'invention vise aussi un support d'enregistrement ou support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.

Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Ce dispositif de dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié et ce programme d'ordinateur présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.

4. Liste des figures

D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels:

La figure 1 représente l’architecture matérielle d’un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié;

La figure 2 présente sous forme d’organigramme les principales étapes d’un procédé de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.

5. Description d'un mode de réalisation de l'invention

La figure 1 représente l’architecture matérielle d’un dispositif DNU de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié conforme à l’invention.

Dans le mode de réalisation décrit ici, ce dispositif a l’architecture matérielle d’un ordinateur. Il comprend notamment un processeur PROC, une mémoire vive MV, une mémoire morte MEM et une mémoire flash non volatile MF. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. La mémoire morte constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC et sur lequel est enregistré ici un programme d’ordinateur PG conforme à l’invention, ce programme comportant des instructions pour mettre en œuvre les étapes du procédé de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié tel que décrit précédemment, lorsque le programme est exécuté par le processeur PROC.

A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UT met notamment en œuvre les étapes du procédé de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié selon l'un quelconque des modes particuliers de réalisation décrits en relation avec la figure 2, selon les instructions du programme d'ordinateur PG. Le dispositif DNU comprend un module de communication COM configuré pour établir des communications avec par exemple un réseau IP. Ce module de communication COM est utilisé pour recevoir des requêtes en provenance d’un terminal d’un utilisateur. Ce terminal est par exemple un smartphone (en anglais «téléphone intelligent»), un ordinateur, une tablette, l’ordinateur de bord d’une voiture connectée ou un objet connecté (IOT pour Internet Of Things) ou tout terminal apte à se connecter à un réseau par exemple de type Internet. Ainsi, lors de la réception de la requête par le module COM, le procédé va récupérer un paramètre comme par exemple une adresse telle qu’une adresse IP, une adresse MAC, un numéro de port de communication ou un protocole de transport, qui permet la communication avec un deuxième terminal tel qu’un serveur Internet hébergeant des services et/ou des pages web.

Le dispositif DNU comprend de plus un module RECH qui va rechercher l’adresse reçue dans une liste par exemple stockée dans une base de données, un fichier, ou une mémoire. Le dispositif comprend de plus un module NOTIF apte à notifier qu’un terminal utilise un serveur de noms de domaine non certifié si par exemple l’adresse reçue n’est pas dans la liste.

Selon un mode particulier de réalisation de l'invention, le module RECH peut également être utilisé pour rechercher l’adresse reçue dans une liste comprenant les adresses des serveurs de noms de domaine non certifiés (liste noire). Si l’adresse est présente dans la liste alors le terminal de l’utilisateur utilise un serveur de noms de domaine non certifié. Une notification pourra alors être émise par le dispositif informant sur l’usage par le terminal utilisateur d’un serveur de noms de domaine non certifié.

Selon un mode particulier de réalisation de l'invention, le dispositif peut comprendre une interface homme-machine permettant de restituer à l’utilisateur visuellement ou vocalement la notification.

Selon un mode particulier de réalisation de l'invention, le module RECH peut également être utilisé pour rechercher l’adresse reçue dans une liste de type NAT ou NAPT dans le cas de paquet IPV4 ou bien dans une liste de routage de paquets IPV6 par exemple hébergée au sein d’une passerelle ou plus généralement d’un point d’accès réseau fixe/mobile.

Selon un mode particulier de réalisation de l'invention, le module COM peut être utilisé pour envoyer la notification à un terminal comme par exemple le terminal de l’utilisateur. L’envoi de la notification peut également être réalisé en interne à la machine hébergeant le dispositif, par exemple vers un deuxième module de communication tel qu’une deuxième carte réseau.

Selon un mode particulier de réalisation de l'invention, le dispositif comprend une base de données configurée pour stocker des données telles qu’une adresse IP source, un port source, le protocole de transport, l’adresse IP destination et le port de destination des requêtes émises et reçues par le module COM.

Selon un mode particulier de réalisation de l'invention, le dispositif comprend une seconde base de données configurée pour stocker des données liées aux serveurs de noms de domaine non certifiés (liste noire) ou des données liées aux serveurs de noms de domaine certifiés (liste blanche).

En référence à la figure 2, nous allons maintenant décrire les principales étapes d’un procédé de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.

La figure 2 est constitué d’un terminal T apte à émettre et recevoir des requêtes vers et depuis le dispositif DNU et d’un serveur S apte à traiter les requêtes émises par le terminal T via le dispositif DNU. Dans l’exemple décrit à l’appui de la figure2, le dispositif DNU exécutant le procédé de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié est une passerelle supportant le protocole IPv4, le serveur S est un serveur de noms de domaine non certifié et le terminal T est par exemple un smartphone (en anglais «téléphone intelligent»), un ordinateur, une tablette, ou un objet connecté (IOT pour Internet Of Things) situé dans le réseau local géré par la passerelle DNU.

A l’étape E10 une application exécutée sur le terminal T émet une requête de résolution DNS à destination du serveur S avec pour adresse IP de destination de la requête, l’adresse IP du serveur S. A l’étape E20 la requête est reçue par la passerelle via son module de communication COM. L’adresse IP de destination ne correspondant pas à son espace d’adressage IP, c’est-à-dire aux adresses IP générées pour les terminaux situés en local et gérés par la passerelle via par exemple un module DHCP, la requête est redirigée vers un module N de la passerelle. Le module N permet par exemple de stocker dans une table ou une liste située par exemple dans une mémoire, un fichier ou une base de données, des données telles que l’adresse IP source d’une requête en provenance d’un terminal, c’est-à-dire l’adresse IP utilisée au sein du réseau local par le terminal ayant émis la requête, le numéro de port source contenu dans la requête émise et associé à l’application, le protocole de transport utilisé par la requête (UDP, TCP, SCTP,…), l’adresse IP de destination (l’adresse IP du serveur DNS non certifié) et le numéro de port de destination contenu dans la requête).

Selon un mode de réalisation particulier, le procédé peut conditionner le passage à l’étape E21 à la présence de l’adresse IP de destination dans la table gérée par le module N. Si celle-ci est présente, le procédé passe alors à l’étape E26.

A l’étape E21, le procédé va rechercher dans une liste située par exemple dans une mémoire, un fichier ou une base de données de la passerelle, l’adresse IP de destination de la requête. Cette liste est par exemple un cache DNS (CR) qui va stocker toutes les demandes de résolution DNS réalisées auprès de serveurs DNS certifiés provenant des terminaux situés dans le réseau local de la passerelle. Cette recherche peut par exemple se faire via une requête de type «Whois lookup» avec comme paramètre l’adresse IP du serveur S.

A l’étape E31, le cache DNS (CR) récupère le résultat de la recherche et l’envoie au module N à l’étape E32. Le résultat est ensuite récupéré et traité par le module N à l’étape E22.

Dans le cas où l’adresse IP du serveur S est présente dans le cache DNS, cela signifie que l’application a utilisé l’adresse FQDN (Fully Qualified Domain Name) du serveur S pour le contacter. Cela indique également qu’une résolution DNS a préalablement été réalisée par un serveur de noms de domaine certifié comme par exemple le serveur de noms de domaine utilisé par le terminal lui-même. Le procédé passe alors à l’étape E26. A noter que dans ce cas, un traitement particulier de la requête tel qu’un filtrage de type contrôle parental, a alors pu être réalisé au préalable par le serveur de noms de domaine certifié.

Dans le cas où l’adresse IP du serveur S n’est pas présente dans le cache DNS, cela signifie qu’aucune résolution DNS via un serveur de noms de domaine certifié n’a retournée l’adresse IP du serveur S. En d’autres mots, l’adresse IP a été récupérée par l’application via un serveur de noms de domaine non certifié. Cela peut également signifier que l’adresse IP du serveur DNS non certifié est connue de l’application et dans ce cas la résolution DNS n’est pas nécessaire.

Selon un mode particulier de réalisation de l’invention, le procédé peut, si la requête est par exemple une requête de type HTTP/HTTPS passer à l’étape E23. Le procédé va alors générer une requête de redirection HTTP/HTTPS via un code réponse standardisé de la série 3XX. L’adresse de redirection peut par exemple être une page web d’information hébergée sur un serveur du réseau Internet ou au niveau de la passerelle. Cette page web permet ainsi de notifier l’utilisateur de l’usage d’un DNS non certifié par l’application.

A noter que l’utilisateur peut, suite à la consultation de la page web d’information, désactiver la notification de l’usage d’un DNS non certifié et/ou la redirection via par exemple un paramètre de la passerelle accessible via une page web dédiée.

Selon une première variante de ce mode particulier de réalisation de l’invention, le procédé peut passer à l’étape E23 en fonction d’un nombre de requêtes à destination du serveur S. En d’autres mots, la redirection est activée en fonction d’un nombre de requêtes à destination du serveur S. Par exemple, toutes les n requêtes (par exemple 10) la redirection est activée puis désactivée à la requête n+1. Dans le cas où la redirection est désactivée alors le procédé passe directement de l’étape E22 à l’étape E26.

Selon une deuxième variante de ce mode particulier de réalisation de l’invention, si l’application relance une requête à destination du serveur S alors la redirection peut être désactivée pour une période prédéterminée (par exemple un jour / une semaine/ un ou plusieurs mois). Dans le cas où la redirection est désactivée alors le procédé passe directement de l’étape E22 à l’étape E26.

Selon un mode particulier de réalisation de l’invention (non représenté ici) qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, un message donnant des informations concernant la passerelle et/ou le terminal T exécutant l’application configurée pour utiliser un serveur de noms de domaine non certifié, est envoyé à destination d’un serveur comme par exemple un serveur du fournisseur d’accès à Internet de l’utilisateur du terminal T. Ce message permet de notifier un tiers de l’usage d’un DNS non certifié par l’application. Le message peut contenir toutes sortes de données telles que le jour, la date, l’adresse MAC du terminal et/ou de la passerelle, l’adresse IP attribuée au terminal sur le réseau local, l’adresse IP attribuée à la passerelle par le fournisseur d’accès à Internet, l’adresse IP du serveur S, etc.

Selon un mode particulier de réalisation de l’invention (non représenté ici) qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, la notification de l’usage d’un DNS non certifié par l’application est restituée par une interface homme-machine de la passerelle. Cette interface est par exemple un schéma représentant les terminaux présents au niveau du réseau local géré par la passerelle. Le schéma peut être visualisé par exemple via un écran situé sur la passerelle ou via un navigateur Internet d’un terminal connecté à la passerelle restituant une page web générée au niveau d’un serveur web s’exécutant sur la passerelle.

Selon un mode particulier de réalisation de l’invention le procédé peut mettre en place un filtrage des requêtes émises par le terminal T subséquentes à la requête émise à l’étape E10. Le filtrage peut être partiel ou total, c’est-à-dire que le filtrage peut bloquer toutes les requêtes ou en laisser passer une partie comme par exemple celles à destination de l’assistance en ligne du fournisseur d’accès à Internet de l’utilisateur du terminal T. Le filtrage peut aussi correspondre à une mise en attente des requêtes pendant une durée (par exemple une seconde) provocant par exemple un ralentissement des flux Internet au niveau du terminal T.

Selon un mode particulier de réalisation de l’invention le procédé peut modifier les requêtes émises par le terminal T subséquentes à la requête émise à l’étape E10 et à destination de serveurs du réseau Internet. La modification peut par exemple être un «marquage» de l’ensemble des requêtes émises par le terminal ou seulement celles émises par l’application. Le marquage peut être réalisé par exemple via:

• l’utilisation du 1er bit non utilisé sur les 3 bits du champ «Indicateur» de l’en-tête du paquet IPv4 correspondant à la requête;
• l’utilisation d’un des 2 bits non utilisés de l’en-tête IPV4 «Type de service»;
• la création d’une nouvelle option IP V4 DNS Public. Par exemple en utilisant une classe d’option réservée pour une utilisation ultérieure (classes 1 et 3) et créer une option «DNS public» dans l’une de ces classes ou créer l’option «DNS public» dans une des classes existantes 0 ou 2. Le codage de l’option «DNS public» pourrait par exemple être définie en numéro d’option 10 dans la classe d’options 0 et son codage pourrait être du type TLV (Type, Longueur, Valeur).

Ainsi, les serveurs et ou les routeurs recevant les requêtes marquées pourront appliquer des règles de traitement spécifiques de ces requêtes comme par exemple la comptabilisation, la non prise en charge, le blocage, le routage spécifique, la mise en place de politiques de qualité de service spécifique, ou bien la duplication.

A l’étape E26, le procédé va modifier la requête en remplaçant l’adresse IP source du terminal par l’adresse IP de la passerelle, c’est-à-dire l’adresse IP donnée à la passerelle internet par un serveur DHCP du fournisseur d’accès à Internet et permettant de communiquer avec les autres terminaux connectés au réseau Internet. Optionnellement le numéro de port de communication source, c’est-à-dire du terminal T, présent dans la requête peut également être modifié à l’étape E26. Le requête est ensuite envoyée au serveur S et est reçue par celui-ci à l’étape E46. De manière connue, la réponse suit le chemin inverse (E47, E27, E28) et est reçue à l’étape E18 par le terminal T.

Selon un mode particulier de réalisation de l’invention le procédé peut à l’étape E21 faire une recherche avec en paramètre l’adresse MAC et/ou l’adresse IP du terminal T en plus de l’adresse IP de destination de la requête. Ce mode de réalisation permet de prendre en compte le cas où plusieurs terminaux sont présents dans le réseau local géré par la passerelle DNU. En effet, l’adresse MAC et/ou l’adresse IP va permettre de déterminer le terminal qui a demandé une résolution DNS à un serveur de noms de domaine certifié et de s’assurer que s’il y a eu précédemment une résolution DNS mémorisée dans le cache CR pour cette adresse IP, elle a bien été réalisée par ce terminal et pas un autre. Bien évidement cela suppose que l’adresse MAC et/ou l’adresse IP du terminal qui effectue une résolution DNS soit sauvegardée et associée à la résolution DNS dans le cache CR avant l’étape E21, par exemple lors de la demande de résolution DNS.

Selon un mode particulier de réalisation de l’invention qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, le procédé peut à l’étape E21 faire une recherche avec en paramètre le numéro de port source de communication utilisé par une application du terminal T pour communiquer en plus de l’adresse IP de destination de la requête. Ce mode de réalisation permet de prendre en compte le cas où plusieurs applications aptes à demander des résolutions DNS sont exécutées sur le terminal T. En effet, le numéro de port source de communication va permettre de déterminer l’application qui a demandé une résolution DNS à un serveur de noms de domaine certifié et de s’assurer que s’il y a eu précédemment une résolution DNS mémorisée dans le cache CR pour cette adresse IP, elle a bien été réalisée par cette application du terminal T et pas une autre du même terminal T. Bien évidement cela suppose que le numéro de port source de communication de l’application qui effectue une résolution DNS soit sauvegardé et associé à la résolution DNS dans le cache CR avant l’étape E21, par exemple lors de la demande de résolution DNS. Alternativement ou cumulativement, le procédé peut également utiliser comme paramètre de recherche lors de l’étape E21, le numéro de port de communication de destination de la requête et/ou le protocole de transport utilisé et/ou toute donnée présente dans le message E10 telle qu’une donnée de IP de niveau 3 ou de niveau supérieur.

Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art sans pour autant sortir du cadre de l’invention. Selon d'autres modes particuliers de réalisation de l'invention, l'invention s'applique également à une passerelle utilisant un protocole IPv6. Dans ce cas, le module N correspond à un module de routage de paquets IPV6 de la passerelle. A noter que dans ce mode de réalisation particulier les champs d’extensions «Next Header» de l’en-tête du protocole IPv6 peuvent être utilisés pour marquer les requêtes/paquets IP en provenance des terminaux ou applications utilisant un serveur de noms de domaine non certifié.

Le marquage peut également être réalisé via un champ «Options» du header «HopByHopHeader» ou du Header «DestinationOptionsHeader» par exemple en utilisant le codage de type TLV

Selon un autre mode de réalisation de l’invention, l’invention s’applique également à un point d’accès mobile, par exemple à un smartphone (en anglais «téléphone intelligeant») 4G ou 5G jouant le rôle de point d’accès WiFi pour un ou plusieurs terminaux.

Selon un autre mode de réalisation de l’invention, l’invention s’applique également à un terminal, par exemple un terminal fixe ou mobile disposant d’une fonction de cache DNS.

Selon un autre mode particulier de réalisation de l'invention, l'invention s'applique également à un réseau cœur mobile 4G/5G mise en œuvre par l’équipement PGW (Packet GateWay) dans le cas d’un réseau cœur 4G, ou SMF (Session Management Function)/UPF (User Plane Function) dans le cas d’un réseau cœur 5G. Il s’agit du même procédé que celui présenté à l’appui de la figure 2. En effet, l’équipement PGW ou SMF/UPF peut intégrer un cache DNS CR dont le fonctionnement est identique à celui présenté précédemment. Par conséquent, le même procédé peut s’appliquer. A chaque nouveau flux ou requête IP détecté, une requête, par exemple de type «Whois Lookup», peut être émise par le module de traitement du trafic IP de l’équipement PGW ou SMF/UPF, c’est-à-dire le module N, à destination du cache DNS CR du PGW ou du SMF/UPF (avec plus ou moins de paramètres dans la requête pour fournir des informations ciblées permettant de détecter les résolutions DNS opérées auparavant par un terminal, une application du terminal, selon le protocole applicatif, selon le protocole de transport,…).

Selon un autre mode particulier de réalisation de l'invention, l'invention s'applique également à un réseau d’accès fixe ou mobile mise en œuvre par l’équipement CGN (Carrier Grade NAT). Il s’agit du même procédé que celui présenté à l’appui de la figure 2. En effet, l’équipement CGN peut intégrer un cache DNS dont le fonctionnement est identique à celui présenté précédemment. Par conséquent, le même procédé peut s’appliquer. A chaque nouveau flux ou requête IP détecté, une requête, par exemple de type «Whois Lookup», peut être émise par le module de traitement du trafic IP de l’équipement CGN, c’est-à-dire le module N, à destination du cache DNS CR du CGN (avec plus ou moins de paramètres dans la requête pour fournir des informations ciblées permettant de détecter les résolutions DNS opérées auparavant par un terminal, une application du terminal, selon le protocole applicatif, selon le protocole de transport,…).

Claims (14)

1. Procédé de notification, par un dispositif de notification, de l’usage, par au moins un terminal, d’un serveur de noms de domaine non certifié, le procédé étant caractérisé en ce qu’il comprend:
   - une étape de réception d’une requête en provenance dudit au moins un terminal, ladite requête comprenant au moins un paramètre correspondant à une première adresse permettant la communication avec un serveur;
   - une étape de recherche de ladite première adresse dans une liste, ladite liste comprenant au moins une adresse obtenue depuis au moins un serveur de noms de domaine certifié;
   - une étape de notification, en fonction du résultat de la recherche, de l’usage, par ledit au moins un terminal, d’un serveur de noms de domaine non certifié.
   
2. Procédé selon la revendication 1 dans lequel les étapes de recherche et de notification sont conditionnées au résultat d’une deuxième étape de recherche de ladite au moins une première adresse dans une deuxième liste, ladite deuxième liste comprenant les adresses de destinations des requêtes émises par ledit au moins un terminal.
   
3. Procédé selon la revendication 1 dans lequel l’étape de recherche comprend en outre la recherche d’une seconde adresse associée à ladite première adresse dans ladite première liste, ladite seconde adresse étant un paramètre de ladite requête et correspondant à une adresse dudit au moins un terminal, ladite première liste comprenant au moins une adresse dudit au moins un terminal obtenue depuis ledit au moins un terminal associée à au moins une adresse obtenue depuis ledit au moins un serveur de noms de domaine certifié.
   
4. Procédé selon la revendication 1 dans lequel l’étape de recherche comprend en outre la recherche d’au moins un numéro de port de communication associé à ladite adresse dans ladite première liste, ledit au moins un numéro de port de communication correspondant à un paramètre de ladite requête, ladite première liste comprenant au moins un numéro de port de communication obtenu depuis ledit au moins un terminal associé à au moins une adresse obtenue depuis ledit au moins un serveur de noms de domaine certifié.
   
5. Procédé selon la revendication 1 dans lequel en ce que l’étape de notification comprend une redirection de ladite requête vers au moins une page Internet.
   
6. Procédé selon la revendication 1 dans lequel l’étape de notification comprend l’envoi d’un message à destination dudit premier terminal.
   
7. Procédé selon la revendication 1 dans lequel l’étape de notification comprend l’envoi d’un message à destination d’un service d’assistance.
   
8. Procédé selon la revendication 1 dans lequel l’étape de notification est suivie d’une étape de filtrage des requêtes en provenance dudit premier terminal.
   
9. Procédé selon la revendication 1 dans lequel l’étape de notification est suivie d’une étape de modification des requêtes émises par ledit premier terminal.
   
10. Dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié, et caractérisé en ce que le dispositif comprend:
    - un module de réception d’une requête en provenance dudit au moins un terminal, ladite requête comprenant au moins un paramètre correspondant à une première adresse permettant la communication avec un serveur;
    - un module de recherche de ladite première adresse dans une liste, ladite liste comprenant au moins une adresse obtenue depuis au moins un serveur de noms de domaine certifié;
    - un module de notification, en fonction du résultat de la recherche, de l’usage par ledit au moins un terminal d’un serveur de noms de domaine non certifié.
    
11. Passerelle caractérisée en ce qu’elle comporte un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.
    
12. Serveur caractérisée en ce qu’il comporte un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.
    
13. Terminal caractérisée en ce qu’il comporte un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.
    
14. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 9, lorsque le programme est exécuté par un processeur.