AdGuard DNS désormais prend en charge SDE (Structured DNS Errors). Voici ce que ça veut dire

11 novembre 2024 Lecture 4 min

La version 2.10 d'AdGuard DNS est comparable à la mise en oeuvre de DNS-over-QUIC - AdGuard DNS est une fois de plus devenu le premier résolveur DNS public au monde à mettre en oeuvre une nouvelle fonctionnalité avant qu'elle ne devienne une norme officielle. Cette fois-ci, il s'agit d'erreurs DNS structurées, dites Structured DNS Errors.

Nous expliquons ci-dessous en détail de quoi il s'agit et pourquoi c'est important. Mais si vous n'avez pas beaucoup de temps, voici un résumé :

Lorsqu'un site web est bloqué au niveau du DNS, les utilisateurs peuvent voir une erreur « Ce site ne peut être atteint » ou « Pas de connexion Internet » qui n'explique pas la raison du blocage.
Pour clarifier la situation, les serveurs DNS pourraient rediriger les utilisateurs vers leur propre page avec une explication. Toutefois, les sites web HTTPS (qui constituent la majorité des sites web) nécessiteraient un certificat distinct.
Il existe une solution plus simple : Structured DNS Errors (SDE). Elles permettent d'envoyer des informations supplémentaires (comme la raison du blocage, l'entité responsable et les coordonnées) dans la réponse DNS afin que le navigateur puisse les lire et les transmettre à l'utilisateur, ce qui améliore considérablement la transparence de la communication.
Pour que ce système fonctionne, les navigateurs doivent commencer à prendre en charge le SDE. C'est ce que nous préconisons.

Structured DNS Errors : qu’est-ce que c’est, en détail

Le filtrage au niveau du DNS est largement utilisé. AdGuard DNS compte à lui seul plus de 100 millions d'utilisateurs. Les gens utilisent le filtrage DNS pour bloquer les publicités et les traqueurs ou pour protéger leurs enfants. Même si un utilisateur n'a pas configuré le DNS manuellement, il est toujours confronté au filtrage DNS, en raison des politiques de son pays ou de son entreprise. On peut supposer qu'il y a presque autant de personnes que d'internautes en total qui ont été confrontés à des sites web bloqués par DNS.

Le blocage au niveau du DNS empêche l'accès à un domaine entier. Un utilisateur essaie de visiter https://example.com, son navigateur fait une requête DNS et un serveur DNS répond que le domaine example.com est bloqué, ce qui fait que le navigateur affiche “Ce site est inaccessible” ou “Pas de connexion Internet”.

Erreur “Ce site est inaccessible”
Si l'utilisateur n'a pas bloqué manuellement ce domaine, il peut ne pas comprendre pourquoi il ne peut pas ouvrir la page. Il peut se poser des questions :

Y a-t-il un problème ? Dois-je recharger la page ?
Cela n'a pas fonctionné. La connexion Internet est-elle coupée ?
L'Internet fonctionne bien. La page est-elle bloquée ? Oui, mais pourquoi ?
Peut-être que mon service DNS est en panne. Je devrais le signaler.

Ce manque de communication entre le service DNS et l'utilisateur est un problème. Les services DNS peuvent et veulent le résoudre - par exemple, en redirigeant l'utilisateur vers une page contenant une explication plus détaillée afin qu'il sache ce qui s'est passé et qui contacter.
Pourquoi ne pas le faire ?

Il y a un hic :

S'il s'agit d'un site web HTTP, ce qui signifie que la connexion n'est pas cryptée, le serveur DNS peut rediriger en toute sécurité l'utilisateur vers une page non cryptée.
S'il s'agit d'un site web HTTPS, le navigateur effectue une authentification par certificat et s'attend à voir un certificat valide pour https://example.com. Si AdGuard DNS redirige vers sa propre page, le navigateur affichera une erreur de validation de certificat.

Erreur du certificat

Une des solutions consisterait donc à installer un certificat spécial sur l'appareil de l'utilisateur. Cependant, ce n'est pas toujours possible ou sûr. Il existe un moyen beaucoup plus simple : envoyer plus d'informations dans la réponse DNS.

Pour faire ça, la norme 2020 Extended DNS Errors standard a été introduite, permettant aux réponses DNS d'inclure un code d'erreur ainsi qu'un champ EXTRA-TEXT pour plus de détails. Le Structured DNS Errors draft propose également d'ajouter au champ EXTRA-TEXT des fichiers I-JSON (un profil restreint de JSON) que les navigateurs peuvent facilement lire et afficher dans un format convivial.

Que contiendraient ces fichiers I-JSON ?

Motif du blocage
Informations de contact pour les demandes de renseignements si la page a été bloquée par erreur
Organisation responsable du filtrage DNS dans ce cas (facultatif)
Autres informations facultatives

C'est vraiment pratique. Un tel système améliore la transparence entre les services DNS et les utilisateurs et assure la sécurité de ces derniers. S'ils comprennent pourquoi un site web est bloqué, ils sont moins susceptibles d'abandonner un serveur DNS sécurisé au profit d'un serveur non crypté.

Ce qu'il faut pour mettre en œuvre Extended DNS Errors et Structured DNS Errors

Les navigateurs doivent les prendre en charge. Après tout, ce sont eux qui déterminent les informations que l'utilisateur voit - qu'il s'agisse d'une simple erreur de connexion ou d'une explication détaillée de la raison pour laquelle le site web est bloqué et de ce qu'il faut faire ensuite.

Nous demandons donc aux représentants des navigateurs de prendre en charge la RFC8914 et, idéalement, sa proposition de mise à jour. Ce changement contribuera à rendre l'internet plus transparent et plus convivial pour des milliards de personnes.

A quoi cela ressemble dans AdGuard DNS

Nous avons créé une extension de démonstration qui montre comment les Erreurs DNS Structurées pourraient fonctionner si les navigateurs les supportaient. Avec cette extension, si vous essayez de visiter un site web bloqué par AdGuard DNS, il lira les informations envoyées par SDE et affichera une belle page d'explication. Beaucoup plus facile à comprendre que les exemples ci-dessus, n'est-ce pas ?

Page d'explication

Vous pouvez installer l'extension depuis le Chrome Web Store ou depuis GitHub.

Autres améliorations : Expérience plus personnalisée pour les utilisateurs et les organisations

Notre public comprend aussi bien des particuliers qui configurent des DNS pour leur domicile que de grandes organisations. Ils ont des besoins et des expériences différents : certains ont besoin de connecter 10 appareils et se contentent d'une configuration manuelle ; d'autres ont besoin de connecter 1 000 appareils et préfèrent l'automatisation. Pour mieux comprendre les besoins de chaque utilisateur, nous avons ajouté un questionnaire d'accueil pour recueillir des informations sur les objectifs et le nombre d'appareils prévus.

Onboarding du tableau de bord

Cela nous aidera à personnaliser le DNS à l'avenir — par exemple, en fournissant plus d'informations sur les options d'automatisation pour ceux qui en ont besoin.