Soudain, sans annonce préalable, DNS sur TLS a
commencé à travailler sur
8.8.8.8 . Auparavant, Google annonçait uniquement la prise en charge du
DNS sur HTTPS.Le résolveur public de CloudFlare avec l'adresse IP
1.1.1.1 prend en charge DNS sur TLS depuis le démarrage du projet.
Pourquoi est-ce nécessaire
En utilisant le schéma DNS classique, les fournisseurs peuvent ramper leurs pattes sales dans vos paquets DNS, parcourir les domaines que vous demandez et échanger les réponses à votre guise. Les fraudeurs font de même, remplaçant les résolveurs sur les routeurs piratés afin de diriger l'utilisateur vers un faux serveur.
Avec DNS sur TLS / HTTPS, les demandes sont envoyées dans un tunnel chiffré afin que le fournisseur ne puisse pas remplacer ou afficher la demande.
Et avec l'avènement du cryptage des noms de domaine dans les certificats X.509 (
ESNI ), il deviendra impossible de bloquer via DPI via SNI (Server Name Indication, un champ spécial dans lequel le nom de domaine est transmis dans le premier paquet TLS), qui sont maintenant utilisés par certains grands fournisseurs.
Comment ça marche
Une connexion TLS est établie avec TCP: 853 et le certificat du résolveur est vérifié à l'aide des certificats racine du système, tout comme HTTPS dans un navigateur. Cela élimine le besoin d'ajouter des clés manuellement. À l'intérieur du tunnel, une requête DNS régulière est effectuée. Cela crée moins de surcharge que DNS sur HTTPS, ce qui ajoute des en-têtes HTTP à la demande et à la réponse.
Malheureusement, actuellement, uniquement dans Android 9 (Pie), la prise en charge DNS sur TLS est intégrée au résolveur système.
Instructions de configuration pour Android 9 .
Pour les autres systèmes, il est proposé d'utiliser un démon tiers et d'envoyer le résolveur système à localhost (127.0.0.1).
Configuration sur macOS
Analysons DNS sur TLS sur le dernier macOS, en utilisant le résolveur de
nœuds comme exemple
L'installation
brew install knot-resolver
Par défaut, knot fonctionnera comme un résolveur récursif ordinaire, comme dnsmasq.
Modification de la configuration
nano /usr/local/etc/kresd/config
Et ajoutez à la fin du fichier:
policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} })))
En conséquence, ma configuration ressemble à ceci:
Développer le spoiler -- Config file example useable for personal resolver. -- The goal is to have a validating resolver with tiny memory footprint, -- while actively tracking and refreshing frequent records to lower user latency. -- Refer to manual: https://knot-resolver.readthedocs.io/en/latest/daemon.html#configuration -- Listen on localhost (default) -- net = { '127.0.0.1', '::1' } -- Drop root privileges -- user('knot-resolver', 'knot-resolver') -- Auto-maintain root TA trust_anchors.file = 'root.keys' -- Load Useful modules modules = { 'policy', -- Block queries to local zones/bad sites 'hints', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Smaller cache size cache.size = 10 * MB policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} })))
En savoir plus sur le nom d'hôte et l'authentification par certificat TLS.Dans ce cas, le paramètre de
hostname est le nom commun (CN) ou le nom de l'objet secondaire (SAN) du certificat. Autrement dit, le nom de domaine pour lequel le certificat est émis. Il vérifie l'authenticité du certificat de serveur.
Voici les valeurs SAN du certificat utilisé lors de la connexion à 8.8.8.8:853
dns.google 8888.google 8.8.4.4 8.8.8.8 2001:4860:4860:0:0:0:0:64 2001:4860:4860:0:0:0:0:6464 2001:4860:4860:0:0:0:0:8844 2001:4860:4860:0:0:0:0:8888
N'importe laquelle de ces valeurs peut être utilisée comme paramètre de nom d'hôte. Si vous déployez votre propre résolveur récursif public, il est peu probable que vous parveniez à émettre un certificat X.509 pour une adresse IP, vous devrez donc spécifier un nom de domaine dans le paramètre hostname.
Lancement du démon
sudo brew services start knot-resolver
Vous pouvez vérifier si le démon a démarré avec succès en utilisant la commande:
sudo lsof -i -P -n | grep kresd
Le processus kresd doit écouter sur le port 53 sur localhost.
En cas de problème, consultez le journal des erreurs:
cat /usr/local/var/log/kresd.log
Vérification du fonctionnement du résolveur
dig @127.0.0.1 habr.com
Vérifiez que le résolveur local répond correctement.
Installation en tant que résolveur de système
Si tout fonctionne correctement, vous pouvez affecter un résolveur système dans les propriétés de la carte réseau:
UPDQuelle est la différence entre DNSCrypt, DNSSEC, DNS sur TLS / HTTPS.
DNSCrypt peut fonctionner sur UDP et TCP. Connexion au port 443. Pour le chiffrement, son propre protocole est utilisé, qui diffère de HTTPS. Il peut être facilement mis en évidence à l'aide de DPI. Il s'agit plutôt d'un brouillon, qui a été testé avant l'introduction du DNS sur TLS / HTTPS, car il n'a pas de RFC, c'est-à-dire qu'il n'est pas une norme Internet officielle. Très probablement, bientôt, il sera complètement remplacé par ce dernier.
DNS sur TLS (DoT) - La connexion TCP se produit sur le port 853, une requête DNS régulière est transmise à l'intérieur du tunnel. Le fournisseur voit qu'il s'agit d'une requête DNS mais ne peut pas interférer avec elle. Toutes choses étant égales par ailleurs, dans DNS sur TLS, il devrait y avoir un peu moins de surcharge pour chaque demande que sur HTTPS.
DNS sur HTTP (DoH) - Connexion TCP au port 443, similaire au HTTPS standard. L'intérieur est un format de demande différent, avec des en-têtes HTTP. Cependant, pour le fournisseur, une telle demande sera considérée comme une connexion HTTPS normale. Je suppose que ce protocole a été inventé au cas où les requêtes DNS vers des serveurs étrangers sont bloquées afin de masquer sous le trafic Web normal. Et aussi, afin que les navigateurs puissent résoudre eux-mêmes les domaines et ne pas créer de trafic anormal.
En fait, DNS sur HTTPS et TLS sont la même chose, avec un format de requête légèrement différent. Ces deux protocoles sont acceptés comme normes et possèdent un RFC. Très probablement, dans un avenir proche, nous verrons la distribution de masse des deux.
DNSSEC est un protocole de signature numérique des enregistrements DNS. Il n'est pas lié au chiffrement, car toutes les demandes sont transmises en texte clair. Il peut fonctionner à la fois sur l'ancien protocole DNS classique, c'est-à-dire UDP / TCP sur le port 53, et à l'intérieur de DNS sur TLS / HTTPS. DNSSEC a pour but d'authentifier un enregistrement DNS. Un propriétaire de domaine peut ajouter une clé publique aux serveurs racine de sa zone de domaine et signer toutes les entrées sur l'assistant de serveur NS. En fait, à chaque enregistrement DNS, par exemple, un enregistrement A ou un enregistrement MX, est ajouté un autre enregistrement de type RRSIG contenant la signature. La procédure de validation DNSSEC sur un résolveur récursif vous permet d'établir si cet enregistrement a vraiment été créé par le propriétaire du domaine.
Une comparaison plus détaillée de tous les protocoles
dnscrypt.info/faq (paragraphe Autres protocoles)