Bonjour,
J'ai vu sur une revue le site OpenNIC, qui est un serveur dns différent de Google et de OpenDNS : https://www.opennicproject.org/
Pour tester, j'ai modifier mes dns dans mon routeur, et je suis assez surpris : ma navigation est à la fois plus rapide et plus fluide.

Quelqu'un a des retours (négatifs ou positifs) sur ces dns ?

Personnellement j'ai mis 5.135.183.146 comme dns préféré et 87.98.175.85 comme dns de remplacement.
Je les utilise depuis quelques années sans soucis.
eclipseo wrote:Je les utilise depuis quelques années sans soucis.
Merci de ton avis.
Pour le moment chez moi je n'ai aussi aucun soucis avec ces dns.
Je suis aussi en train d'essayer opennic, et maintenant que dnscrypt est dans les dépôts, j'ai essayé de passer par lui.
(aidé du site: http://www.nurdletech.com/linux-notes/dns/dnscrypt.html)

Voici ce que j'ai actuellement:

* installation de: dnscrypt-proxy -> dnf install dnscrypt-proxy

* création d'un utilisateur/groupe dédiés: dnscrypt (compte système, en /sbin/nologin)

* unit systemd pour dnscrypt (/etc/systemd/system/dnscrypt.service + un restorecon sur ce fichier):
(les infos de ExecStart vienne en partie de: https://github.com/KenKundert/generate-dnscrypt-cmdline.git)
[Unit]
Description=DNScrypt
Wants=network-online.target
After=network.target network-online.target

[Service]
PermissionsStartOnly = true
RuntimeDirectory=dnscrypt
ExecStart=/usr/sbin/dnscrypt-proxy --provider-key=E801:B84E:A606:BFB0:BAC0:CE43:445B:B15E:BA64:B02F:A3C4:AA31:AE10:636A:0790:324D --provider-name=2.dnscrypt-cert.fr.dnscrypt.org --resolver-address=212.47.228.136 --local-address=127.0.0.1:2053 --pidfile=/var/run/dnscrypt/dnscrypt.pid --daemonize
Restart=always
Type=forking
User=dnscrypt
PIDFile=/var/run/dnscrypt/dnscrypt.pid

[Install]
WantedBy=multi-user.target
* Si le parefeu gère les ports sortants, il faut ouvrir le port 443 en UDP (car dnscrypt-proxy fait passer les requêtes par ce port et plus par le 53 UDP)

* Modification du DNS dans NetworkManager par: 127.0.0.1 , et un: systemctl restart NetworkManager

* systemctl start dnscrypt

* systemctl enable dnscrypt

Cela fonctionne chez moi, mais il faut voir si c'est correct 🙂
Et j'ai pas encore activé le cache DNS

EDIT:

Modification pour lancer dnscrypt avec un utilisateur/groupe dédiés, et non avec nobody
Et je viens de prendre connaissance de RuntimeDirectory= , qui me permet de retirer la gestion du dossier dans /var/run ...
J'ai modifié un peu le service, car j'avais 2 processus avant: root et nobody
Je passe par unbound pour le cache (et ai dû mettre dnscrypt sur le port 2053)
un mois plus tard
Bon, re-changement, que j'ai fait il y a quelque temps, et qui ne semble pas poser de problème chez moi en tout cas (je ne passe plus par unbound mais par dnsmasq)

/etc/dnsmasq.d/dnscrypt.conf
listen-address=127.0.0.1
except-interface=virbr0
user=dnsmasq
port=53
bind-dynamic
bogus-priv
no-resolv
clear-on-reload
domain-needed
strict-order
log-queries

server=127.0.0.1#2053
J'ai mis: bind-dynamic , car dnsmasq utilisé par libvirtd est en bind-dynamic, et ne pas le mettre dans cette conf pour dnscrypt crée un problème de démarrage de service
(car dnsmasq semble être en static par défaut)

Avec cette config dnscrypt/dnsmasq, je pourrai fermer le port 53 UDP, car il n'y en a plus besoin, mais cela bloquerait les postes connectés chez moi qui n'ont pas cette config ^^

Par contre, ça écrit pas mal dans rsyslog chez moi, ce cache dns, donc je me demande s'il ne faut pas mettre /var/log ailleurs que sur le SSD...
(ou ne pas mettre: log-queries)

EDIT:
et ai changé l'utilisateur utilisé pour dnsmasq aussi
Comme mon installation est un upgrade, j'en ai profité pour changer manuellement le uid/gid de nobody
2 ans plus tard
bon bah ce que j'ai marqué là est obsolète sur f29, avec dnscrypt-proxy à la v2, qui possède enfin un service.
La partie dnsmasq est fonctionnelle par contre.

J'ai toutefois remarqué que des fois, après avoir changé des paramètres, il fallait redémarrer le système pour que systemd les prenne en compte
(ou j'ai pas trouvé quel service redémarrer, systemctl daemon-reload ne semblant pas suffire).