AdGuard est le premier résolveur DNS over QUIC !

14 décembre 2020 Lecture 6 min

AdGuard DNS est devenu le premier résolveur DNS public à prendre en charge le nouveau protocole DNS-over-QUIC. Nous sommes sûrs que DNS-over-QUIC (ou simplement DoQ) est le futur du chiffrement DNS et nous sommes donc particulièrement fiers d'être les premiers à vous offrir l'opportunité d'essayer ce protocole.

Au début de cet article on expliquera ce qu'est le DNS-over-QUIC, puis on présentera ses avantages par rapport aux alternatives, s'il y a des inconvénients ou non, et comment le mettre en place.

Si vous souhaitez en savoir plus sur le DNS et sur la manière dont il peut être utilisé pour améliorer votre confidentialité en ligne, consultezcet article, datant d'il y a presque deux ans.

Qu'est ce que c'est QUIC ?

Pour être en mesure de comprendre les subtilités du DNS-over-QUIC, il est logique que vous compreniez d'abord ce qu'est QUIC. Faisons donc un petit pas en arrière pour ensuite faire deux pas en avant. QUIC est donc un protocole de réseau à couche de transport (relativement) nouveau. En termes simples, QUIC sert de protocole pour transmettre des paquets de données entre des serveurs ou entre un serveur et un client. Il existe d'autres façons - et d'autres protocoles - de faire cela, vous avez probablement au moins entendu parler du bon vieux TCP, qui a été utilisé principalement sur le web au cours des dernières années et même des dernières décennies.
En termes simples, QUIC sert de protocole pour transmettre des paquets de données entre des serveurs ou entre un serveur et un client. Il existe d'autres moyens - d'autres protocoles - pour faire cela, vous avez probablement au moins entendu parler du bon vieux TCP, qui a été principalement utilisé sur le web au cours des dernières années et même des dernières décennies.

Par rapport à TCP, QUIC est plus rapide, plus fiable et offre un meilleur cryptage. Le fait qu'il ait été développé assez récemment et non à l'époque des dinosaures numériques, signifie qu'il résout également plusieurs problèmes cruciaux qui n'étaient pas du tout évidents à l'époque. Je vais vous donner quelques exemples pour vous montrer pourquoi QUIC est supérieur à ses prédécesseurs.

Blocage en tête de file

Comme nous l'avons mentionné, ça fait longtemps que nous sommes à la merci du protocole de la couche transport TCP et des autres protocoles que nous utilisons - TLS, SSL, HTTP. Sûrement tous ces acronymes nous disent quelque chose, et c'est parce qu'ils existent depuis longtemps et qu'ils font bien leur travail. Mais il y a un hic : ils le font bien dans les conditions quasi parfaites d'une connexion stable à haute bande. Sortez de chez vous dans le désert de la 4G, de la LTE et des données mobiles en général, et vous rencontrerez inévitablement des problèmes tels que la faiblesse du signal, la lenteur de la connexion, etc. Même les normes modernes comme la 5G ne vous protégeront pas de ces nuisances — essayez de prendre un ascenseur, par exemple.

Des années d'acceptation nous ont fait considérer cela comme quelque chose de naturel — le réseau est mauvais, donc les pages se chargent lentement ou ne se chargent pas du tout. Mais pourquoi exactement ? Nous abordons le problème dit du "blocage en tête de file". Sous TCP, les paquets de données sont transmis par lots. L'un des paquets est perdu à cause de la faiblesse de la connexion et le château de cartes s'effondre. Les autres paquets ne peuvent pas être traités et doivent faire la queue pour que le paquet perdu soit renvoyé, en espérant qu'il passe cette fois.

Avec TCP, si un paquet de données est perdu, les autres dervopnt attendre

Sans plonger dans les détails, la réalisation de QUIC permet de traiter les données sans ordre particulier. Si le premier paquet de données est perdu en raison d'un signal faible, le reste sera néanmoins traité sans délai.

Sous QUIC, les autres paquets de données peuvent être traités même si le premier tombe en cours de route

Migration de connexion

Nous sommes habitués à l'idée que chaque appareil sur Internet est défini de façon unique par son adresse IP, et c'est exact, en partie. Mais imaginez une journée ordinaire d'une personne normale. Prenons même mon exemple. Chaque matin de jour ouvrable, je quitte le confort de ma maison (et son Wi-Fi stable) pour aller au travail. Dès que mon téléphone quitte la zone de couverture du routeur domestique, mon téléphone passe du Wi-Fi à la 4G. Son adresse IP change également, et toutes les connexions actives sont interrompues. Je rouvre le navigateur dans le train pour continuer à lire l'article que j'ai commencé à la maison - le navigateur doit rétablir toutes les connexions au site web et au serveur de mon DoH qui fonctionne sur AdGuard Home. Cela prend du temps et je perds rapidement patience. Finalement j'arrive au bureau, je me connecte au réseau Wi-Fi local, et l'histoire se répète.

QUIC a été conçu en tenant compte de tout cela. Lorsque QUIC est utilisé, votre téléphone survivra a la commutation d'une adresse IP à une autre, aussi appelée "Migration de connexion", sans aucun inconvénient notable pour vous en tant qu'utilisateur. Bien sûr, c'est plus complexe, et QUIC permet aux connexions de surmonter toute modification de l'adresse du point de sortie, et pas seulement de l'adresse IP (par exemple, les changements de port également). Vous pourrez facilement trouver plus d'informations en ligne sur le sujet si vous le souhaitez.

DNS-over-QUIC

Nous arrivons à présent au plat principal. DNS-over-QUIC est un protocole DNS qui tire parti du protocole de la couche de transport QUIC et l'utilise pour transmettre des requêtes DNS. Actuellement, la norme DoQ est au stage de projet, mais cela ne nous empêche pas d'expérimenter.

Pourquoi pas DNS-over-HTTPS

C'est ici que ça se complique : à un certain moment, le DNS sur HTTPS supportera également QUIC, grâce à l'utilisation future du protocole HTTP/3 qui a été construit autour de QUIC. Et cela soulève d'autres questions : pourquoi avons-nous besoin de DoQ dans ce cas ?

En fait, il y a plusieurs raisons, mais elles découlent toutes du seul fait que HTTP n'est pas un protocole de couche transport. Il a été conçu pour différentes raisons, et bien qu'il puisse servir de substitut à un protocole de transport approprié, cela soulèverait de nombreux risques inutiles. En particulier dans le domaine de la confidentialité et vie privée, l'utilisation de HTTP pour transférer des requêtes DNS entraînera :

des cookies HTT
d'autres en-têtes HTTP (Authentification, Agent-utilisateur, Accept-Language)
davantage d'opportunités pour des malfaiteurs de prendre vos empreintes numériques
Suivi en ligne par aide de ETag

Si du côté client, tous ces problèmes peuvent être expliqués au niveau du DoH, les clients eux-mêmes sont très différents : navigateurs, systèmes d'exploitation, toutes sortes d'autres logiciels. Il est quasiment impossible d'avoir une solution côté client pour chacun d'entre eux.

DNS-over-QUIC signé AdGuard

Nous sommes fiers d'être les premiers parmi les résolveurs de DNS publics à mettre en œuvre la spécification actuelle de DNS-over-QUIC dans nos serveurs DNS. Et nous vous offrons la chance d'être parmi les premiers à l'essayer ! Actuellement, le moyen le plus simple est d'utiliser l'une de nos applications mobiles : AdGuard pour Android ou AdGuard pour iOS.

Utilisation de DoQ dans AdGuard pour Android

Lancez l'application, puis ouvrez le menu latéral
Allez sur Paramètres > Filtrage DNS et activez-le
Selectionnez le serveur DNS de votre choix dans la liste des serveurs disponibles
Dans l'onglet Type de serveur selectionnez DNS-over-QUIC (experimental)

Utilisation de DoQ dans AdGuard pour iOS

Lancez l'application, allez dans l'onglet Protection
Activez Protection DNS et ouvrez en le menu
Dans Serveur DNS choisissez un parmi les serveurs DNS AdGuard disponibles
Selectionnez DNS-over-QUIC (experimental) de la liste des protocoles disponibles

Besoin de plus d'info ?

Et bien en voila plus! Vous trouverez ci-dessous une compilation de liens utiles, d'autant plus si vous souhaitez de Here's a compilation of doubler votre DoQ et si vous possédez aussi quelque prouesse technique :

dnslookup — un outil de base pour lancer des requêtes DNS. Prend en charge tous les protocoles modernes populaires : DoH, DoT, DoQ, DNSCrypt.
AdGuard Home — vous envisagez de créer votre propre serveur DoQ ? Facile ! AdGuard Home a bénéficié du soutien de DoQ dans la dernière version. Si votre AdGuard Home fonctionne comme un serveur public, vous pouvez y configurer le cryptage.
dnsproxy — pour les cas où AdGuard Home est un peu trop compliqué et que vous êtes en quête d'un simple transitaire. Utilisez dnsproxy - un simple proxy DNS avec le soutien de DoH, DoT, DoQ et DNSCrypt.
DnsLibs —une bibliothèque C++ que nous utilisons dans nos produits AdGuard. N'hésitez pas à l'emprunter pour incorporer DoQ dans votre propre application.