Stéphane Bortzmeyer a écrit 645 commentaires

Non, seulement on peut, mais c'est certainement la bonne solution (je le fais sur mon Turris).

Ce ne sont pas forcément des pressions de l'État, cela peut être des décisions de justice (cas de The Pirate Bay ou, en général, des domaines qui embêtent les ayant-trop-de-droits), ou bien un ordre (pas une pression) comme http://www.bortzmeyer.org/censure-francaise.html …

Et pas besoin d'un « état encore plus voyou que le notre », la redirection se fait déjà (cf. article ci-dessus.)

Et, même s'ils le faisaient, comme le lien avec eux n'est pas sécurisé (aucune authentification, pas d'intégrité cryptographiquement vérifiée), cela n'aurait guère de valeur.

Il y a des tas de solutions équivalentes à Pi-Hole, le RPZ de BIND, par exemple.

Cisco OpenDNS est situé aux USA, donc toutes les données persos filent chez un pays qui a zéro protection des données personnelles (idem avec Google Public DNS, bien sûr).

C'est une racine alternative (ils ajoutent des TLD « bidons », qui ne marcheront que chez eux), donc mauvaise idée.

Hmmm, j'ai l'impression que vous confonderz la racine et les TLD. La racine peut ajouter (ou supprimer) un TLD. Le TLD peut ajouter (ou supprimer) les SLD (domaines de second niveau) et ainsi de suite.

D'abord, il faut vraiment éviter de parler de « serveur DNS » sans précision ou, encore pire, de « DNS » tout court.

Il existe en effet deux sortes de serveurs DNS radicalement différents, les serveurs faisant autorité, et les résolveurs.

Ici, je suppose qu'on parle des résolveurs, ces serveurs récursifs qui ne connaissent pas d'informations au démarrage et qui apprennent en interrogeant les serveurs faisant autorité.

Ces résolveurs partent de la racine (ils doivent donc avoir « en dur » les adresses des serveurs racine) et apprennent petit à petit les adresses des autres serveurs (« hey, serveur racine, tu connais linuxfr.org ? Non, mais voici les serveurs de .org » « hey, serveur de .org, tu connais linuxfr.org ? ») Notez que l'explication Wikipédia est fausse https://fr.wikipedia.org/wiki/Domain_Name_System#R.C3.A9solution_du_nom_par_un_h.C3.B4te

Pour assurer la fiabilité de ces informations, les domaines sérieux (pas linuxfr.org) sont signés cryptographiquement.

Oui, cela serait possible, mais en TCP seulement et certaines zones ont encore des serveurs DNS qui n'acceptent pas TCP.

Tor a d'énormes limitations dans ses relais DNS. Il ne transmet pas les signatures DNSSEC, par exemple (ainsi que tous les types DNS inconnus). C'est un sous-DNS.

Au passage, je suis bien d'accord avec tous ceux et celles qui ont dit que la bonne solution n'était pas ces résolveurs publics, mais un résolveur sur son infrastructure, qu'on contrôle, mais je voudrais rajouter que cela ne veut pas dire un résolveur par machine, ce qui serait beaucoup de travail, pas Michu-compatible, un gaspillage de ressources réseaux (pas de cache partagé) et parfois difficile (Android…) voire impossible (objets connectés fermés).

La bonne solution est donc un résolveur DNS validant avec DNSSEC et tournant sur une machine du réseau local (la « box » est l'endroit idéal). Cela assure un résolveur non-menteur et sécurisé. Si on veut en plus de la vie privée, il faut lui faire suivre les requêtes non-résolues à un résolveur public de confiance (donc pas Google ou Verisign) et accessible par un canal chiffré (DNS sur TLS, RFC 7858). Les vrais paranos ajouteront Tor :-)

Si votre box est fermée et ne permet pas ce genre de manips, remplacez la par un engin ouvert, libre et tout ça, comme le Turris Omnia qui a par défaut un résolveur DNSSEC.

TLD bidons, je ne sais pas.

Ben, c'est écrit sur leur propre site :

Top-Level Domains published and maintained by OpenNIC

Est-ce qu'il na va pas y avoir de plus en plus de racines alternatives?

J'ai plutôt l'impression que plus personne n'en fait. C'était à la mode aux débuts des années 2000, et plein d'escrocs s'y étaient mis mais aujourd'hui, ça semble bien mort.

Avec peut-être à terme une évolution de l'URL permettant le choix de la racine DNS à suivre?

J'attends de lire l'Internet-Draft :-) (Mais je ne retiens pas ma respiration : l'idée est mauvaise car on ne part pas toujours d'un URL.)

Finalement, qu'est ce qui empêcherait le développement de racines alternatives?

Je suggère mon article

Il y a aussi les résolveurs de Yandex. J'aime bien leur système de configuration par l'adresse IP du résolveur (la censure est donc optionnelle).

Et au lieu de filer ses données à Obama ou à Cazeneuve, on les file à Poutine, ce qui est plus exotique.

Comme avec tous les résolveurs publics, il y a deux risques de confidentialité (RFC 7626 pour les détails). Le premier est celui que le résolveur vous espionne. Là, pas d'autre solution que la confiance. Faites-vous confiance à Verisign / Google / FDN / etc ? À vous de voir.

Le second risque de confidentialité est celui de l'écoute du trafic par un tiers, d'autant plus grave que le résolveur public est souvent loin de vous, créant ainsi plein d'occasions d'écoute sur le trajet. Là, il faut chiffrer. Verisign Public DNS, Google Public DNS et FDN ne fournissent aucun mécanisme de chiffrement :-(

Ou, plutôt que le tunnel SSH, le tunnel DNS-sur-TLS. Exemple (si vous avez IPv6).

Chiffrer et pas crypter.

Sinon, le problème de DNScrypt est que c'est une solution non-standard. La solution standard est décrite dans le RFC 7858

OpenNIC est aussi une racine alternative donc ils ajoutent des TLD bidons, qui ne marchent qu'avec OpenNIC (vous passez un URL à un copain et ça marche pas parce qu'il utilise la « vraie » racine). À éviter.

Normalement, sur LinuxFr.org, on s'exprime à titre individuel, mais je vais faire une exception et mettre ma casquette d'employé d'un registre de TLD : les serveurs faisant autorité sont largement surdimensionnés (pour faire face aux attaques par déni de service) et peuvent donc encaisser une augmentation du nombre de clients. De toute façon, aujourd'hui, le trafic légitime n'est plus qu'ujne petite fraction du trafic DNS :-(

Le problème des requêtes qui passent en clair est bien connu et documenté (RFC 7626). Pour limiter les possibilités d'espionnage, deux approches (complémentaires, pas concurrentes), réduire les données (RFC 7816) et chiffrer (RFC 7858).

Pour des détails pratiques sur le chiffrement des requêtes DNS, voir le futur portail du projet DNS privacy.

Alors, déjà, FreeDNS.zone ne transmet pas les enregistrements DNSSEC donc on ne peut pas valider. À fuir.

Freenom.world a un comportement bizarre lorsque le nom est incorrectement signé : il timeoute (au lieu de renvoyer SERVFAIL).

LDN : l'un des rares qui n'utilise pas que le protocole du siècle dernier. Il est accessible en IPv6. En outre, il valide (vraiment) avec DNSSEC. Techniquement, c'est le seul qui tient la route, avec Google Public DNS.

Je n'ai pas compris comment marchait FreeDNS.afraid : c'est vraiment un résolveur ? J'ai plutôt l'impression que c'est un serveur faisant autorité.

Enfin, si le but est d'éviter la censure, tout service qui ne fournit pas d'intégrité cryptographique (le serveur de Google, celui de FDN, etc) est dangereux car les requêtes peuvent être non seulement écoutées mais les réponses peuvent être modifiées).

https://lists.opendnssec.org/pipermail/opendnssec-user/2017-January/003868.html

C'est vrai que le site Web est une catastrophe mais, oui, des gens travaillent réellement sur les RMLL. Confiance et courage !

Je faisais allusion à http://linuxfr.org/users/tankey/journaux/turris-omnia-en-passe-de-doubler-son-objectif-de-financement-participatif#comment-1631435

C'est l'ancienne Turris, pas l'Omnia.

Non, c'est bien un ARM.
```
root@turris:~# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 50.00
Features : half thumb fastmult vfp edsp vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x4
CPU part : 0xc09
CPU revision : 1

processor : 1
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 50.00
Features : half thumb fastmult vfp edsp vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x4
CPU part : 0xc09
CPU revision : 1

Hardware : Marvell Armada 380/385 (Device Tree)
Revision : 0000
Serial : 0000000000000000
```