Les requêtes DNS cryptées doivent-elles ignorer les intérêts internes et n’interroger que les serveurs de noms de domaine (DNS) publics, ou résoudre les domaines présents uniquement sur le réseau interne via un résolveur DNS interne ? Les experts de l’Internet Engineering Task Force (IETF) ne sont pas d’accord sur ce point.

Split-DNS est un terme élastique. Pour certains, il ne signifie rien de moins que le détournement de noms de domaine sur des réseaux internes, pour d’autres, il s’agit d’un usage domestique légitime. Certains y voient même une pratique sans alternative dans les réseaux d’entreprise modernes. Le point crucial est le suivant : les informations DNS divisées ont-elles encore leur place dans le monde du DNS crypté ?

Les premières spécifications qui doivent permettre aux utilisateurs de choisir un résolveur DNS chiffré sont presque prêtes. La controverse porte désormais sur la question de savoir si les nouvelles méthodes doivent prendre en compte les environnements DNS fractionnés.

Petit retour en arrière : Depuis qu’Edward Snowden a révélé que la NSA enregistrait les mouvements des utilisateurs sur Internet à grande échelle, notamment à l’aide de requêtes DNS non cryptées, les développeurs DNS de l’IETF travaillent sur des méthodes de cryptage. C’est ainsi que sont apparus les DNS-over-TLS (DoT), DNS-over-HTTPS (DoH) et Oblivious DNS-over-HTTPS.

Les utilisateurs doivent trouver des serveurs de noms de domaine appropriés

Dernièrement, l’IETF a travaillé sur des méthodes permettant de trouver automatiquement les résolveurs cryptés. Cela devrait empêcher les fabricants de navigateurs de déplacer le trafic DNS à grande échelle vers des exploitants de résolveurs individuels. En effet, les utilisateurs souhaitent certes plus d’intimité et utilisent volontiers le DNS sur HTTPS pour cela.

Mais comme la recherche de résolveurs DoH est fastidieuse, ils prennent souvent simplement l’un de ceux que Mozilla propose dans le navigateur Firefox. C’est pratique, mais cela ne conduit pas forcément au serveur de noms de domaine le plus approprié du point de vue de l’utilisateur. C’est pourquoi le groupe de travail Adaptive DNS Discovery (ADD) de l’IETF veut finaliser deux variantes pour la découverte automatique de résolveurs, de sorte que les navigateurs trouvent automatiquement les résolveurs appropriés et les proposent au choix.

La pomme de discorde de l’ADN fractionné

Reste la question de savoir si le concept de Split-DNS doit être reproduit dans le nouveau monde DNS crypté. Trois groupes de travail de l’IETF ont récemment discuté de cette question lors d’un mini-sommet : Adaptive DNS Discovery (ADD), DNS Privacy (DPRIVE) et DNS Operations (DNSOP).

Lors de cette rencontre virtuelle, les définitions du terme Split-DNS ont déjà été discutées. En principe, le Split-DNS décrit des scénarios dans lesquels un résolveur interne donne des réponses différentes aux mêmes requêtes DNS qu’un résolveur externe, a expliqué Ben Schwartz de Google.

Dans le cas le plus simple, le Split-DNS est utilisé pour que les clients internes puissent s’adresser aux serveurs internes. En effet, de nombreux serveurs internes doivent rester privés et ne pas être répertoriés dans le DNS public. Ensuite, il y a les cas où les serveurs sont accessibles à la fois en interne et en externe. Les clients internes doivent généralement emprunter le chemin direct dans le réseau de l’entreprise, et non l’Internet public – pour désengorger la ligne, et pour des raisons de sécurité et de confidentialité.

Des problèmes surviennent par exemple lorsque des domaines qui sont également enregistrés sur l’Internet public sont utilisés en interne. Certains appellent cela le squatting DNS et font la moue. Par exemple, les routeurs Fritzbox sont en conflit de noms parce qu’ils utilisent en interne le domaine .box, qui est enregistré depuis quelques années comme domaine de premier niveau.

Le Split-DNS est en outre utilisé pour le filtrage local, comme l’a souligné Paul Vixie, gourou de BIND et fondateur de Farsight-Security, lors de la réunion. Certaines entreprises, universités ou écoles utilisent leurs résolveurs internes pour bloquer l’accès aux sites de logiciels malveillants ou à certains contenus, selon Vixie. Et certaines entreprises bloquent les accès à Facebook en indiquant que cela n’est pas autorisé pendant les heures de travail, a expliqué un participant.

Litige de principe

Le problème du contournement des filtres locaux par des clients cryptés a suscité de vives réactions politiques au cours de la standardisation – même les Lords britanniques ont déjà discuté de la menace perçue par DoH.

Le développeur de Google Schwartz s’oppose à la représentation d’un maximum de scénarios de DNS fractionné dans le DNS crypté. Certains pourraient ne plus être pris en charge par la nouvelle architecture, estime-t-il, en faisant référence aux proxies HTTP transparents. Utilisés tout naturellement dans les années 90 pour répondre localement aux demandes des utilisateurs en économisant les ressources, ils ont disparu avec la généralisation du trafic HTTPS. Il s’attend à une évolution similaire pour certains scénarios de split DNS.

« Si mon Google Chromecast se voit attribuer une adresse et une passerelle par mon serveur DHCP et les utilise, mais ignore mon serveur DNS local et envoie simplement toutes les requêtes DNS à (le serveur DNS de Google sous l’adresse IP) 8.8.8.8, il s’agit d’une pratique douteuse », a déclaré Schwartz, « Tous les experts en sécurité devraient clairement rejeter une telle pratique ».

Vixie insiste plutôt sur le fait de ne pas ignorer les utilisateurs lorsqu’il s’agit de décider quel résolveur répond à leurs requêtes DNS. Si une application veut envoyer des requêtes DNS à un résolveur externe, elle doit demander l’autorisation à l’utilisateur. La démarche de Google consistant à répondre lui-même aux requêtes DNS est certes compréhensible en raison des nombreux problèmes liés à un « mauvais DNS ». Mais cela signifie également une atteinte à la confidentialité pour les utilisateurs du monde entier.

Solutions proposées

Si l’on en croit Schwartz et ses coauteurs, l’IETF devrait se limiter à une petite solution pour le mariage du DNS crypté et du DNS fractionné. Un serveur DNS authentifié à cet effet doit répertorier les domaines à résoudre localement. DNSSEC ou une authentification via le canal DNS normal, par exemple par une solution de certificat, doivent éviter le détournement. Cela pourrait également être une solution pour les VPN, selon les experts. Et les noms qui ne sont pas enregistrés dans le DNS public, comme les noms .corp utilisés localement, ne devraient même pas être pris en compte par la spécification de l’IETF.

En se limitant, on peut rendre certaines applications Split DNS plus sûres et meilleures, estime Schwartz. C’est tout ce que l’on peut faire. En revanche, Warren Kumari, un collègue de Google, déplore que la majorité des déploiements de Split-DNS soient ainsi laissés de côté.

Ce n’est pas ainsi que les deux camps se rejoignent.

Les trois groupes de travail sur le DNS pourront bientôt lutter à nouveau pour trouver un accord lors de la prochaine conférence de l’IETF en mars à Vienne. Pour la première fois depuis l’apparition du virus SARS-Cov-2, cette conférence devrait se tenir de manière hybride. Le groupe de travail ADD y sera à nouveau confronté à la question de savoir s’il accepte le Split-DNS-Discovery présenté par Schwartz comme projet de norme officiel. Jusqu’à présent, il y a encore eu trop de résistance à ce sujet.