Qu’est-ce que le DNS over DLS (DoT) ?

DNS over TLS (Transport Layer Security) ou « DoT » est une norme de l’IETF qui fournit un chiffrement complet entre un client DNS et un serveur DNS.

Le DNS a toujours souffert d’un problème de sécurité au niveau du « dernier kilomètre » : les communications entre un client DNS et le serveur DNS sont presque toujours non chiffrées, et donc sujettes à l’usurpation d’identité, à l’interception, etc. DNS over TLS est documenté dans le document IETF RFC 7858 – Specification for DNS over Transport Layer Security (TLS).

FONCTIONNEMENT DU DNS SUR TLS (DoT)

L’initiation de DNS over TLS est très simple. En établissant une connexion sur un port TCP 853, les clients et les serveurs s’attendent et acceptent de négocier une session TLS pour sécuriser le canal.

Le RFC 7858 définit la méthode suivante pour l’utilisation de DNS over TLS afin d’établir des sessions sécurisées :

Initiation de la session

Un serveur DNS qui supporte DNS over TLS écoute et accepte les connexions TCP sur le port 853, à moins qu’il n’ait un accord mutuel avec son serveur pour utiliser un port différent pour DoT. Lors de l’utilisation de DNS over TLS, toutes les connexions TCP sur le port 853 doivent être chiffrées, car le mélange de données chiffrées et non chiffrées pose d’importants problèmes de sécurité.

Handshake TLS et authentification

Une fois que le client DNS s’est connecté avec succès, il procède à la négociation TLS et s’authentifie auprès du serveur DNS, si nécessaire. Une fois la négociation TLS terminée, la connexion est chiffrée.

DNS SUR TLS (DoT) VS DNS SUR HTTPS (DoH)

DNS over HTTPS (DoH) est un deuxième protocole de sécurité de l’IETF qui traite de la sécurité des communications entre le client DNC et le serveur DNS.

DoH est documenté dans la RFC 8484 de l’IETF. Les protocoles DNS over TLS et DNS over HTTPS prévoient tous deux le chiffrement entre le client DNS et le serveur DNS, ce qui permet d’assurer la confidentialité et l’intégrité des données. Cependant, DoH utilise le même port TCP que le reste du trafic HTTP-S, le port 443. Par conséquent, il peut être difficile d’identifier DoH d’un autre trafic HTTP-S.

DoH a ses limites, car certaines applications qui prennent en charge DoH peuvent ignorer délibérément la configuration du client DNS local. Le navigateur Firefox de Mozilla, par exemple, prend en charge DoH à titre expérimental dans certaines versions. Lorsqu’il est activé, Firefox ignore toute configuration DNS locale et envoie les requêtes DNS par HTTP-S directement à Cloudflare.

• Cela permet de contourner les mécanismes de sécurité locaux, tels que les zones de protection contre les intrusions, et de rendre la résolution DNS d’un utilisateur opaque pour son service informatique.
• Cela complique également la résolution des problèmes DNS, car une application (Firefox, par exemple) sur un appareil utilise désormais des serveurs DNS différents de ceux des autres applications.

DNSSEC ET DNS SUR TLS (DoT)

DNSSEC, les extensions de sécurité DNS, ajoutent l’authentification et le contrôle de l’intégrité des données au DNS, ce qui manque généralement au client DNS : le serveur DNS local effectue la validation DNSSEC et établit l’authenticité et l’intégrité des données, puis transmet le résultat au client DNS.

Cette dernière étape de la communication peut toutefois être usurpée.

RECOMMANDATIONS DE MISE EN ŒUVRE POUR DNS OVER TLS (DoT)

Il est souvent recommandé aux entreprises de bloquer le trafic DNS direct (y compris DoT) entre les adresses IP internes et les serveurs DNS sur Internet, y compris ceux de Cloudflare. Cela empêche certains types de logiciels malveillants, dont DNSChanger, de fonctionner et oblige les hôtes internes à utiliser l’infrastructure DNS gérée par le service informatique.

Cette infrastructure DNS interne peut appliquer une politique de résolution des noms à l’aide de mécanismes de sécurité tels que les zones de politique de réponse (RPZ).

Le blocage du trafic DNS standard et DoT entre les adresses IP internes est simple. Des règles de pare-feu comme celles qui suivent devraient suffire :

• autoriser tcp/udp in/out sur le port 53
• refuser l’entrée/sortie de tcp/udp vers toutes les adresses IP sur le port 53
• refuser l’entrée/sortie de tcp/udp à toutes les adresses IP sur le port 853

Contourner l’infrastructure DNS interne semble être une mauvaise idée, mais il est utile de résoudre le problème du « dernier kilomètre » du DNS.

Avantages de DNS-over-TLS

1. La portée de DNS-over-TLS est limitée par rapport à l’authentification de bout en bout fournie par DNSSEC, mais elle est beaucoup plus facile à déployer progressivement et offre des avantages en matière de protection de la vie privée que DNSSEC n’offre pas.
2. Du point de vue de la sécurité, le DNS-over-TLS empêche les FAI d’injecter de fausses informations dans les réponses DNS, par exemple pour vous envoyer sur une page de recherche contenant des publicités pour des domaines mal saisis. Pour de telles attaques de type « man-in-the-middle » , la barre est placée à un certificat TLS/SSL falsifié, ce qui est probablement à la portée des gouvernements, mais de peu d’autres.
3. Du point de vue de la protection de la vie privée, le DNS sur TLS dissimule votre trafic DNS aux FAI et aux sites de surveillance de masse entre votre routeur et le résolveur public. Cependant, la connexion à l’adresse IP récupérée via DNS donne aux fouineurs de fils beaucoup d’informations, même si le DNS est chiffré.

Performances

Le DNS est sensible à la latence (il se trouve souvent dans le chemin critique de la navigation sur le web), ajustez donc vos performances.

Sources