Stéphane Bortzmeyer a écrit 655 commentaires

Promotion, c'est un peu exagéré, je crois avoir bien indiqué les avantages et inconvénients.

Oui, c'est ce que j'ai tenté (comme pour les premières configs) mais ça échoue dans mon cas.

FUD

Mauvaise méthode. Pour comprendre pourquoi ça ne marche pas (c'est expliqué dans mon article mais je répète ici), prenons le cas d'un francophone qui parle anglais. Si le site Web a un texte original en français, traduit en anglais, il faudrait envoyer le français. Si le site Web a un texte original en englais, mal traduit en français, il faut envoyer l'anglais. Si le site Web a un texte original en chinois, mal traduit en anglais, tant pis, il faut quand même envoyer l'anglais.

Des règles naïves comme « toujours suivre Accept-Language: » ou bien « toujours envoyer la version originale » ne marchent pas. C'est pour cela que peu de sites Web se fient à Accept-Language.

Laisser un choix manuel à l'utilisateur.

Mauvaise idée que d'utiliser la langue du navigateur http://www.bortzmeyer.org/web-et-version-originale.html

Il faut le dire clairement : ce logiciel ne sert à rien. Il est donc absolument indispensable.

Et pour ceux qui, comme moi, trouvent ce terme de « design » fourre-tout et mal défini, une bonne explication :-)

Le compte-rendu de la table ronde (entre designers) qui a eu lieu à ce sujet.

Tiens, ça m'a motivé pour écrire pourquoi les résolveurs publics ne sont pas une bonne idée.

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).