DNS sur TLS avec résolu par systemd

Question

J'essayais d'activer DNS sur TLS via systemd-resolved. J'ai changé /etc/systemd/resolved.conf comme suit:

[Resolve] DNS=1.1.1.1 #FallbackDNS= Domains=~. #LLMNR=no #MulticastDNS=no #DNSSEC=no DNSOverTLS=opportunistic #Cache=yes #DNSStubListener=yes

Lors de la surveillance du réseau (avec tcpdump) pour voir si le comportement résultant était celui voulu, il semble qu'une session TLS soit établie avec le serveur cible; mais, le serveur ferme la connexion. J'obtiens les mêmes résultats avec 1.1.1.1, 8.8.8.8 et autres.

Des idées pour résoudre le problème?

P.S .: systemd-resolved finit par faire une résolution parallèle avec le DNS traditionnel (malgré le réglage de "Domaines" ci-dessus). Mais ma principale question pour ce post est ce qui peut mal tourner avec celui de TLS.

opinion_no9 · Answer

DNS sur TLS dans Ubuntu 18.04

D'après mon expérience, cela ne fonctionnera pas de la manière mentionnée ci-dessus sur Ubuntu 18.04+ (c'est-à-dire U19).

Depuis Ubuntu 18+ utilise Netplan en parallèle avec NetworkManager, les choses ont radicalement changé: plus de configuration manuelle de manière traditionnelle ; La documentation est .... clairsemé.

l'accrochage peut apporter d'autres changements. Il établit des fichiers resolution.conf supplémentaires. Cependant, ce qui suit a réellement fonctionné (/ w bonnes performances).

Pour des informations sur Netplan, regardez --- (ici .

Quel DNS-over-TLS fonctionnait avec succès (works4me):

1. Dans /etc/systemd /olved.conf , changez UNIQUEMENT DNSOverTLS = en

DNSOverTLS=opportunistic

Il n'y a AUCUNE autre option (voir l'explication ici: DNS sur TLS

Utilisez un serveur DNS compatible. Je préfère les serveurs Digitalcourage

46.182.19.48 resp. 2a02: 2970: 1002 :: 18

Pourquoi? Intimité!

Cela devrait être fait dans Network-Manager via GUI !

Saisissez l'adresse du serveur DNS dans le champ GUI de votre connexion sous Paramètres IPv4/Serveurs DNS et v6 respectivement.

Les entrées n'apparaîtront PAS dans /etc/resolv.conf !! Qui est correct. Au lieu de cela, vous verrez le serveur de noms 127.0.0.53

C'est le nouveau Ubuntu .... ne convient plus aux hobby-admins.

Non recommandé mais possible alternative

La configuration des serveurs DNS appropriés peut être effectuée directement dans /etc/resolv.conf au format habituel, supprimez le 127.0.0.53 ou autre chose.

Problème: obtient écrasé par Network-Manager dans Ubuntu!

Remède: En tant que vrai root (!) chattr le fichier /etc/resolv.conf

chattr +i /etc/resolv.conf

C'est la force brute et peut désactiver la mise en cache DNS automatique via résolu.

Crédit à la Documentation Arch

Cependant, fonctionne bien ;-) mais nécessite une maintenance manuelle en tant que véritable racine!

Pointe:

Vous êtes bien avisé de faire resolv.conf un lien. Ceci est requis par résolu pour fonctionner correctement. Comme Sudo-root éloigne l'ancien fichier puis

Sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf

Je n'aime pas cette façon mais fonctionne intrinsèquement correctement.

.

Redémarrez ensuite. Ou redémarrez le réseau.

.

# Comment vérifier

Quelques vérifications de base:

Vérifiez le DNS réellement utilisé par résolu par systemd:

resolvectl status

Vérifiez si DNS se résout avec resolvectl:

resolvectl query archlinux.org

(Essayez quelques exemples)

Vérifiez quel DNS est réellement utilisé, vérifiez les fuites dans le VPN:

https://dnsleaktest.com/

. 2. Démarrez Wireshark et filtrez le "port 53" et effectuez le trafic Web.

Cela ne devrait plus montrer les connexions sur le port 53. Ensuite, filtrez pour le port 853. Ici, beaucoup devrait continuer.

Important: Si tout le trafic utilise le port 853 et qu'aucun trafic n'utilise 53, vous l'avez fait avec succès!

Exemples de Wireshark ici .

# Remarque: j'ai essayé trapu. stubby ne s'intègre pas bien dans Ubuntu mais vous pouvez le faire fonctionner même avec NetworkManager. Il y a un manuel pour le faire avec succès: Comment utiliser DNS sur TLS sur Ubuntu Linux Problème: les performances étaient un peu pénibles. Quelque chose est bizarre et je n'ai pas trouvé la cause.

L'activation de DNSSEC = yes dans /etc/systemd/resolved.conf devrait être possible maintenant.

Important:

Cette solution améliore considérablement la confidentialité.

MAIS n'est PAS suffisant si votre intégrité personnelle dépend de la confidentialité et de la sécurité des données !! Voir les mises en garde dans la description de resolvd. Il ne suffit PAS d'avoir un mode opportuniste. Mieux vaut alors faire attention à Tails Linux. Un triste salut à tous les prisonniers politiques du monde entier.

Terry Wang · Answer

Récemment, j'ai implémenté DNS sur TLS pour le réseau domestique (en utilisant un routeur alimenté par AsusWRT-Merlin). En explorant les approches pour implémenter DoT pour les postes de travail et serveurs Linux (dans le cloud - je veux dire les ordinateurs de quelqu'un d'autre lol) en dehors du réseau domestique, j'ai trouvé systemd-resolved Comme recommandé par le DNS Privacy Project.

Alors que @ opinion-no9 fournissait une solution spécifique à Ubuntu 18.04 (limitée par la version systemd livrée avec le LTS), j'aimerais partager une solution plus générique et proche de l'amont:

Un peu de contexte - chronologie de la prise en charge DNS sur TLS dans `systemd`

236 Prise en charge DNSSEC pour RFC 8080 (clés et signatures ed25519)
239 systemd-resolved Prend désormais en charge opportunistic DNS-over-TLS, Off par défaut
243 systemd-resolved A pris en charge un nouveau mode strict DNS-over-TLS

Oh NON! Ubuntu 18.04 LTS est livré avec systemd 237 ...

Utiliser DNS sur TLS (DoT) sur des systèmes Linux génériques

Donc, pour une distribution Linux générique avec un noyau relativement proche de l'amont, systemd, glibc, toolchain, GNU utils, etc.

modifier /etc/systemd/resolved.conf

[Resolve] DNS=1.1.1.1 1.0.0.1 8.8.8.8 #FallbackDNS=1.1.1.1 9.9.9.10 8.8.8.8 2606:4700:4700::1111 2620:fe::10 2001:4860:4860::8888 #Domains= #LLMNR=yes #MulticastDNS=yes #DNSSEC=allow-downgrade #DNSOverTLS=opportunistic DNSSEC=yes DNSOverTLS=yes #Cache=yes #DNSStubListener=yes #ReadEtcHosts=yes

Supposons que systemd-resolved Est activé, redémarrez le service

systemctl restart systemd-resolved

Utiliser le résolveur de talon local

systemd-resolved Fournit un écouteur de stub DNS local sur l'adresse IP 127.0.0.53 sur l'interface de bouclage locale, donc pour utiliser le résolveur de stub compatible DNS sur TLS, nous devons en quelque sorte gérer /etc/resolv.conf Et faire assurez-vous que 127.0.0.53 est utilisé comme serveur de noms.

REMARQUE: systemd maintient /run/systemd/resolve/stub-resolv.conf Pour la compatibilité avec les programmes Linux traditionnels. Nous pouvons simplement créer un lien symbolique vers ce fichier ;-)

ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

REMARQUE: Pour Arch Linux, je dois remplacer openresolvconf par systemd-resolvconf.

Terminé.

Validation

Générez une requête DNS, puis vérifiez TCP au serveur DNS en amont spécifié via le port 853, dans l'exemple suivant, nous avons explicitement utilisé 1.1.1.1 De Cloudflare.

root@netbook:/etc# uname -a Linux netbook 5.4.5-Arch1-1 #1 SMP PREEMPT Wed, 18 Dec 2019 19:48:51 +0000 x86_64 GNU/Linux root@netbook:~# kdig -d github.com ;; DEBUG: Querying for owner(github.com.), class(1), type(1), server(127.0.0.53), port(53), protocol(UDP) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 55366 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION: ;; github.com. IN A ;; ANSWER SECTION: github.com. 58 IN A 13.236.229.21 ;; Received 44 B ;; Time 2019-12-21 22:55:13 AEDT ;; From 127.0.0.53@53(UDP) in 58.0 ms root@netbook:~# ss -tuna | grep :853 tcp ESTAB 0 0 192.168.1.150:50504 1.1.1.1:853 tcp ESTAB 0 0 192.168.1.150:50506 1.1.1.1:853

Ou, si vous voulez être simple et grossier, utilisez tcpdump ;-)

tcpdump -tttt -nn -XX -vv -i <interface> dst 1.1.1.1 and port 853

Conclusion

Dernier point mais non le moindre: il s'agit d'un guide générique pour activer DNS sur TLS sur un hôte Linux, il n'est pas spécifique à la distribution ou à l'environnement de bureau (car nous n'avons même pas touché NetworkManager ou ses alternatives ;-). Des ajustements peuvent être nécessaires pour différentes distributions et différents DE/WM.