Pour Pi-hole sur Ubuntu Server 24.04, configurez le routage de ses requêtes DNS vers dnscrypt-proxyle serveur local et configurez Pi-hole 127.0.0.1#5053pour qu'il utilise ce serveur. Cela chiffre le trafic DNS entre votre serveur et le résolveur DNS sélectionné grâce à DNS-over-HTTPS (DoH), tandis que Pi-hole continue de répondre aux clients de votre réseau local et d'appliquer ses listes de blocage. Par défaut, Pi-hole ne fournit pas de protocole DoH vers le serveur local ; c'est le proxy local qui assure cette connexion chiffrée.
Il est important de noter que Cloudflare a supprimé cette cloudflared proxy-dnscommande des nouvelles versions à partir du 2 février 2026. Les anciens tutoriels qui l'installent peuvent ne pas fonctionner avec la cloudflaredversion actuelle. La procédure ci-dessous utilise cette commande dnscrypt-proxy, conformément au guide DoH actuel de Pi-hole. Cette configuration convient lorsque Pi-hole et le proxy sont exécutés sur le même hôte Ubuntu. Une configuration Docker ou multi-hôtes nécessite une adresse d'écoute et des règles de pare-feu différentes.
Le DNS classique envoie généralement les requêtes de votre résolveur à un fournisseur DNS en amont sans chiffrement. Le protocole DoH, quant à lui, transporte les requêtes DNS via HTTPS, ce qui complique la tâche d'un observateur réseau situé entre votre serveur Pi-hole et le résolveur pour lire ou modifier ces requêtes. Pi-hole reste le serveur DNS annoncé aux appareils de votre réseau local ; seul son chemin en amont change.
Le protocole DoH ne rend pas l'activité DNS invisible pour le résolveur choisi. Le fournisseur d'accès en amont reçoit toujours les requêtes de votre serveur, et Pi-hole peut conserver l'historique des requêtes client conformément à ses paramètres de confidentialité et de journalisation. De plus, HTTPS ne chiffre pas le trafic web non lié au protocole. Si vous souhaitez utiliser un résolveur spécifique, consultez sa politique de confidentialité et sélectionnez son entrée DoH dans la liste des résolveurs compatibles.
Le proxy se liera uniquement à l'interface de bouclage (port 5053), laissant le port 53 à Pi-hole. Ceci évite tout conflit avec le service DNS de Pi-hole et le résolveur DNS local d'Ubuntu. Il est inutile de désactiver le systemd-resolvedproxy pour faire fonctionner cette architecture ; son port de bouclage dédié évite ce conflit.
Le projet dnscrypt-proxy documente la procédure d'installation d'un paquet Ubuntu. Avant d'installer ce paquet, vérifiez que vos dépôts Ubuntu configurés proposent un candidat :
sudo apt update
apt-cache policy dnscrypt-proxySi le résultat affiche une version candidate, installez-la :
sudo apt install dnscrypt-proxySi aucun candidat n'est affiché, n'ajoutez pas de dépôt tiers non pertinent simplement pour continuer. Utilisez la méthode d'installation décrite dans le guide Linux officiel du projet dnscrypt-proxy, vérifiez la version et l'architecture, puis adaptez la configuration du service à cette installation. Les chemins d'accès à l'unité de socket systemd et à la configuration ci-dessous s'appliquent à la configuration du paquet Ubuntu documentée par Pi-hole.
Pi-hole utilise déjà le port DNS standard 53. Configurez le socket du proxy pour qu'il écoute à la fois sur TCP et UDP à l'adresse 127.0.0.1:5053, accessible uniquement depuis le même hôte. Créez un fichier de configuration systemd :
sudo systemctl edit dnscrypt-proxy.socketSaisissez ces lignes dans l'éditeur et enregistrez :
[Socket]
ListenStream=
ListenDatagram=
ListenStream=127.0.0.1:5053
ListenDatagram=127.0.0.1:5053Les lignes vides ListenStream=effacent ListenDatagram=les valeurs par défaut du paquet avant de définir les adresses de remplacement. Ne les omettez pas : sinon, systemd peut conserver le port par défaut en plus de l’écouteur personnalisé.
Ouvrez le fichier de configuration du paquet :
sudoedit /etc/dnscrypt-proxy/dnscrypt-proxy.tomlPour l'activation des sockets systemd, utilisez une liste d'écouteurs vide dans la configuration du proxy. Choisissez un nom de résolveur parmi la liste des résolveurs publics signés. Par exemple, la configuration suivante sélectionne le résolveur Cloudflare standard ; le guide Pi-hole présente également cloudflare-securityun exemple lorsque le filtrage des logiciels malveillants au niveau du résolveur en amont est souhaité :
listen_addresses = []
server_names = ['cloudflare']Conservez intacte la configuration du reste du paquet. Les noms indiqués server_namessont des identifiants de registre, et non des noms d'hôtes ou des chemins d'URL arbitraires. Si vous préférez un autre fournisseur, vérifiez que son entrée de résolveur actuelle prend en charge DoH et copiez son nom exact. Un résolveur qui filtre les logiciels malveillants ou d'autres catégories peut produire des résultats différents d'un résolveur non filtré.
Configurez l'adresse DNS en amont de Pi-hole sur l'écouteur local :
sudo pihole-FTL --config dns.upstreams '["127.0.0.1#5053"]'Le #5053suffixe correspond à la notation de Pi-hole pour le port DNS non standard. Vous pouvez également vérifier cette information dans l'interface d'administration de Pi-hole, sous Paramètres > DNS . Supprimez les sélections prédéfinies de serveurs DNS publics en amont et conservez le serveur personnalisé 127.0.0.1#5053comme serveur en amont. Si vous conservez un résolveur public coché comme serveur en amont supplémentaire, certaines requêtes peuvent contourner le proxy chiffré. Par conséquent, supprimez ces entrées si vous souhaitez que toutes les requêtes en amont de Pi-hole utilisent le protocole DoH.
Redémarrez le socket, le service proxy et le démon Pi-hole FTL afin qu'ils chargent la nouvelle configuration :
sudo systemctl restart dnscrypt-proxy.socket
sudo systemctl restart dnscrypt-proxy.service
sudo systemctl restart pihole-FTL.serviceConsulter l'état du service :
sudo systemctl status dnscrypt-proxy.socket
sudo systemctl status dnscrypt-proxy.service
sudo systemctl status pihole-FTL.serviceChaque serveur doit être actif sans erreur de liaison ni échec de démarrage du résolveur. Testez le proxy directement via son écouteur DNS local :
dig @127.0.0.1 -p 5053 example.comUne réponse DNS indique que le proxy local répond. Testez ensuite Pi-hole sur le port 53 :
dig @127.0.0.1 example.comConsultez le journal des requêtes ou le tableau de bord de Pi-hole pour confirmer que la requête a bien atteint Pi-hole, et examinez le journal du proxy si le test échoue :
sudo journalctl -u dnscrypt-proxy.service -b --no-pagerPour une vérification supplémentaire, consultez les journaux de démarrage du proxy ou le journal des modifications pour trouver le résolveur sélectionné et l'état du protocole DoH. Une résolution DNS réussie digprouve à elle seule que la résolution DNS fonctionne ; elle ne prouve pas, en soi, que la requête a utilisé HTTPS.
sudo ss -lntup, examinez le fichier de configuration avec `ls` systemctl cat dnscrypt-proxy.socketet assurez-vous que les lignes de réinitialisation vides précèdent les entrées du port 5053.127.0.0.1#5053, puis redémarrez-le pihole-FTL. Assurez-vous que les options de configuration du serveur distant ne définissent pas automatiquement une route alternative./etc/resolv.conf. Évitez de remplacer ce fichier ou de désactiver systemd-resolvedPi-hole pour tenter de résoudre le problème rapidement.Pour revenir à la configuration précédente, rétablissez le paramètre DNS amont que vous avez enregistré dans Pi-hole et redémarrez-le pihole-FTL. Une fois que Pi-hole ne pointe plus vers le proxy, vous pouvez le désactiver ou le supprimer dnscrypt-proxyà l'aide du gestionnaire de paquets. Si ce serveur résout également son propre DNS via Pi-hole, assurez-vous de disposer d'une solution de récupération locale avant de modifier les services.
Utilisez cette configuration de proxy à hôte unique lorsque vous souhaitez un filtrage DNS centralisé dans Pi-hole et un trafic chiffré entre Pi-hole et un résolveur DNS spécifique. Son inspection est relativement simple car le proxy possède une seule adresse et un seul port locaux. Si vous exécutez Pi-hole dans un conteneur Docker, sur un autre serveur ou sur plusieurs réseaux, vous aurez peut-être besoin d'une adresse réseau dédiée au conteneur plutôt que d'une adresse de bouclage, et vous devrez restreindre l'accès au proxy afin qu'il ne soit pas exposé comme un résolveur DNS public. Si vous avez besoin d'un filtrage basé sur des règles, d'une identité par appareil ou d'un DNS chiffré pour les appareils mobiles, configurez ces clients ou une passerelle gérée séparément ; la connexion DoH en amont de Pi-hole ne chiffre pas automatiquement le chemin d'accès à Pi-hole pour chaque client.
Enfin, n'oubliez pas qu'un routeur ou un client peut contourner Pi-hole s'il annonce un second serveur DNS. Pour un filtrage à l'échelle du réseau, attribuez aux clients uniquement l'adresse de Pi-hole via DHCP et tenez compte des annonces DNS IPv6 ainsi que des annonces IPv4. Après avoir modifié les paramètres du routeur, effectuez des tests sur plusieurs appareils, car une configuration de proxy correcte sur le serveur ne peut empêcher un client d'utiliser directement un autre résolveur.
Corrigez les déchirures d'écran des cartes graphiques Intel sous Pardus Linux en vérifiant X11 vs Wayland, les paramètres du compositeur, le taux de rafraîchissement, le pilote Xorg actif et TearFree uniquement lorsque cela est approprié.
Configurer firewalld sur SLES 15 : vérifier les zones, autoriser les services ou les ports, enregistrer les règles permanentes, recharger en toute sécurité et vérifier l’accès.
Activez la mise à jour en direct du noyau sur SLES 15 SP7, appliquez les correctifs pris en charge sans redémarrer, vérifiez les correctifs actifs et comprenez quand un redémarrage du noyau est encore nécessaire.
Activez le mode FIPS sur SLES 15 avec l'utilitaire de configuration pris en charge par SUSE, redémarrez en toute sécurité, vérifiez l'état du noyau et de la politique de chiffrement, et vérifiez les limites de certification.
Installez Google Chrome sur Gooroom OS en toute sécurité grâce aux paquets .deb officiels, à APT, aux vérifications de politique, aux conseils de mise à jour et aux correctifs pour les appareils gérés.
Transférez en toute sécurité les journaux système SLES vers un serveur syslog distant grâce à rsyslog, aux certificats TLS, à la vérification du nom du pair, aux files d'attente, à la validation et aux tests.
Intégrez SLES 15 à Active Directory avec SSSD à l'aide de YaST. Configurez le DNS et l'heure, configurez les connexions au domaine, vérifiez Kerberos et comparez SSSD, Winbind et realmd.
Résolvez les problèmes de Wi-Fi RTL8821CE sur Pardus Linux en vérifiant le pilote rtw88 intégré, le firmware Realtek, rfkill, NetworkManager et les options de repli sécurisées.
Diagnostiquer et corriger les échecs de résolution DNS de Debian 12 avec systemd-resolved, y compris resolv.conf, NetworkManager, networkd, cache et vérification.
Installez Pardus 25.2 à côté de Windows 11 en sauvegardant, en réduisant le volume Windows, en démarrant sur une clé USB UEFI et en protégeant les partitions EFI et de récupération existantes.
