Journal DNS anonyme

Posté par  . Licence CC By‑SA.
Étiquettes :
26
5
jan.
2017

Bonjour'nal
En ces temps de censure du net il est toujours intéressant d'utiliser des service qui respecte notre vie privée et nos libertés en évitant de stocker des informations nous concernant.
Une chose relativement simple et efficace (Nudge) est de se passer des DNS des gros FAI. Cela se fait soit au niveau de votre box, soit dans l'OS directement.Plusieurs solution s'offre actuellement a nous.

D'abord évacuons les faux amis :

  • DNS google : Ils sont rapide et non censuré, mais point de vue respect de la vie privée on a vue mieux, donc on évite.
  • OpenDNS : Service ouvert mais applique une censure, donc pas top. De plus il est passé sous le giron de Cisco dernièrement donc à éviter aussi.

Ceux qui «paraissent» correct ou que je n'ai pas testé :

  • FreeDNS.zone : service public, semble «anonymes»
  • FreeNomWorld : Pour ceux qui connaisse les domaines en «.tk» c'est le même fournisseur. Service ouvert et qui se dit «anonyme».
  • FreeDNS.afraid : Nécessite un compte (gratuit) et permet d'héberger ses enregistrement DNS

En fait sous le nom «FreeDNS» il y a plein de service plus ou moins correcte donc difficile de faire son choix

Ceux a qui je fait totalement confiance :

  • FDN : service public et respectueux de nos libertés (Merci Benjamin)
  • LDN : Lorraine Data Network propose un service similaire a FDN.

Pour ceux qui veulent une liste plus complète des DNS disponible ils peuvent commencer par explorer le resolv.conf de Chris Hills

Et vous quel DNS utilisez vous ?

  • # unbound

    Posté par  (site web personnel) . Évalué à 10.

    Unbound fonctionne chez moi. Pas besoin de ces relais dns.

    Sinon, les communications DNS transitent en clair meme signées. Donc niveau vie privée… C'est facile à logger pour l'admin sys ou la boite noire chez ton fai.
    Et si on veut du chiffré, il faut envoyer nos requetes à un relai dns externe que je ne connais pas. :/

    Je n'ai pas encore trouvé de solution ideale.

    • [^] # Re: unbound

      Posté par  . Évalué à 3.

      Je fais pareil. Un autre avantage étant d’avoir un cache en local.

      Cependant je me pose une question… Si tous les internautes faisaient de même, est-ce qu’on aurait pas un sérieux problème de saturation des serveurs DNS de premier niveau, voire des serveurs racines du DNS ?

      • [^] # Re: unbound

        Posté par  (site web personnel) . Évalué à 5. Dernière modification le 05 janvier 2017 à 14:38.

        Pas plus que ça.
        Il y a du cache un peu partout, et les serveurs racines et de 1er niveau sont assez nombreux et bien répartis sur la planète (via de l’anycast).
        Le mieux étant quand même de mettre un unbound unique pour tout ton LAN (sur une pi par exemple), qui servira de cache pour toutes tes machines.
        Ça a aussi l’avantage de pouvoir faire du vrai DNSSec, une validation DNSSec en dehors du LAN, ça vaut presque 0 en terme de sécurité (il suffit d’ajouter/virer le bit AD avec du MitM pour activer/désactiver la validité de la réponse).

      • [^] # Re: unbound

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        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 :-(

        • [^] # Re: unbound

          Posté par  . Évalué à 5.

          Je ne pige pas ce qu'espèrent ceux qui font du déni de service contre les dns. Ils pensent demander des rançons ?

      • [^] # Re: unbound

        Posté par  . Évalué à 2.

        Si tous les internautes faisaient de même, est-ce qu’on aurait pas un sérieux problème de saturation des serveurs DNS de premier niveau, voire des serveurs racines du DNS ?

        Tu fais aussi peu confiance aux admin. sys. pour faire évoluer leur infrastructure ? Triste.

        • [^] # Re: unbound

          Posté par  . Évalué à 2.

          Tu fais aussi peu confiance aux admin. sys. pour faire évoluer leur infrastructure ?

          Non. Constatant que tous les FAI faisaient utiliser le leur à leurs clients, je pensais que c’était une nécessité de répartir la charge.

          Mais c’est vrai qu’avant, les FAI proposaient tous un proxy web et que j’ai l’impression que plus personne n’en utilise (je parle pas de proxy en général mais d’un proxy web pour les abonnés d’un FAI).

          C’était une hypothèse saugrenue visiblement. Ce serait pas la première hypothèse saugrenue de ma part :)

    • [^] # Re: unbound

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      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.

  • # Autre DNS et utilisation

    Posté par  . Évalué à 4.

    J'agrémente la liste avec ce lien Prism-Break:DNS.

    Personnellement j'utilise FDN et OpenNIC.

    • [^] # Re: Autre DNS et utilisation

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      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.

      • [^] # Re: Autre DNS et utilisation

        Posté par  . Évalué à 0.

        TLD bidons, je ne sais pas.
        Est-ce qu'il na va pas y avoir de plus en plus de racines alternatives?
        Avec peut-être à terme une évolution de l'URL permettant le choix de la racine DNS à suivre?

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

        • [^] # Re: Autre DNS et utilisation

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          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

        • [^] # Re: Autre DNS et utilisation

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Ben euh, le DNS a déjà plusieurs niveaux. Tu proposes quoi? machin.com.racine1 et machin.com.racine2? mais du coup, ce ne sont plus des racines, juste des branches de l'arbre des DNS…

          On devrait pouvoir se contenter des TLDs existants (surtout qu'il y en a plein maintenant), et les gens peuvent faire ce qu'ils veulent en-dessous de leur propre domaine (truc.machin.com, bidule.machin.com, et ainsi de suite). Avoir plusieurs racines ne sert donc pas à grand chose.

  • # FDN

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    FDN bien sûr. Relayé sur mon LAN via un dnsmasq installé sur mon serveur maison (hop, un peu de pub).

  • # Opennic + DNSCrypt

    Posté par  . Évalué à 2.

    J'utilise les serveurs de Opennic: https://www.opennicproject.org/ Ceux qui ne loguent pas et peuvent etre utilises avec DNSCrypt sont disponibles.

    Il y a aussi DNSWatch: https://dns.watch/index

    De toute facon, il faut utiliser DNSCrypt pour crypter ses requetes: https://wiki.archlinux.org/index.php/DNSCrypt est une bonne doc.

  • # Le mien

    Posté par  (site web personnel) . Évalué à 10.

    Et vous quel DNS utilisez vous ?

    Le mien. J’utilise un résolveur récursif qui fait lui-même tout le travail de résolution (contacter les serveurs faisant autorité et suivre les différentes délégations), pas un stub resolver qui se contente de transmettre la demande à des résolveurs tiers (que ce soit ceux du FAI ou d’autres).

    Comme ça, la validation DNSSEC est faite sur ma machine, ça règle la question de la « sécurité du dernier kilomètre ».

    Question anonymat en revanche, ça ne change pas grand’chose vis-à-vis du FAI, qui voit de toute façon passer toutes les requêtes DNS, peu importe qu’elles soient destinées directement aux serveurs faisant autorité ou qu’elles passent par un résolveur tiers.

    Et vis-à-vis des serveurs faisant autorité, ça fait même perdre un peu d’anonymat par rapport à l’utilisation des résolveurs du FAI, puisque d’une part c’est ma machine (avec mon IP) qui le contacte et non plus le résolveur du FAI, et d’autre part je ne bénéficie plus du cache du résolveur du FAI.

    En ces temps de censure du net

    Si c’est la censure qui te préoccupe (et non la vie privée), alors a fortiori il faut éviter autant que possible les intermédiaires inutiles et procéder à la résolution soi-même. Tout intermédiaire est un levier potentiel pour les censeurs.

    • [^] # Re: Le mien

      Posté par  . Évalué à 4. Dernière modification le 05 janvier 2017 à 13:14.

      J'utilise moi aussi un résolveur récursif rien qu'à moi. Mais ce n'est pas un peu égoïste de faire ainsi ? Même si mon résolveur met bien les réponses en cache (en respectant les TTL définis sur les domaines) je dois quand même taper les serveurs racine chaque jour (et juste pour moi). Si tout le monde faisait comme nous en ayant chacun son résolveur récursif (disons si l'on mettait un résolveur récursif dans chaque "box"), il se passerait quoi concrètement ? Moi aussi je le fais, mais je me demande réellement si je suis censé le faire…

      Sinon pour l'anonymat, il y a la solution du tunnel SSH si ton résolveur se trouve chez quelqu'un en qui tu as plus confiance qu'en ton FAI, mais cela suppose de forcer le DNS en TCP (je n'ai pas encore réussi, mais cela doit être techniquement possible à configurer sur un Linux je pense).

      • [^] # Re: Le mien

        Posté par  (site web personnel) . Évalué à 4.

        Mais ce n'est pas un peu égoïste de faire ainsi ? […] je dois quand même taper les serveurs racine chaque jour (et juste pour moi).

        Pifométriquement, je pense qu’il n’y a guère de soucis à se faire du côté des serveurs racines. Ils encaissent plus ou moins régulièrement des tentatives de DDoS sans jamais s’écrouler, ils tiendraient probablement largement la charge même si tout le monde se mettait à utiliser son propre résolveur.

        C’est plutôt les serveurs faisant autorité pour les zones très populaires (au hasard, google.com., facebook.com., etc.) qui risqueraient de « prendre cher ». Mais là aussi, les hébergeurs DNS de ce genre de zones « à risque » savent probablement à quoi s’en tenir (ils se prennent probablement leur dose d’attaques DDoS eux aussi, comme les serveurs racines).

      • [^] # Re: Le mien

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

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

    • [^] # Re: Le mien

      Posté par  . Évalué à 1. Dernière modification le 07 janvier 2017 à 00:00.

      Pour l'anonymat, n'y aurait-il pas moyen, par exemple, de faire utiliser Tor à son résolveur maison pour consulter les serveurs faisant autorité ? (question de béotien, je n'ai jamais vraiment joué à configurer dnsmasq, bind, ou tout autre logiciel du genre)

      • [^] # Re: Le mien

        Posté par  . Évalué à 2.

        Pas mal comme idée.

        Tor ne fonctionne qu'en TCP.
        Les requêtes DNS sont souvent en UDP, mais la norme permet sans problème de passer uniquement par TCP. Il faut cependant un client DNS adapté (éventuellement un « simple » proxy).

      • [^] # Re: Le mien

        Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 07 janvier 2017 à 16:11.

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

  • # Un résolveur à la maison

    Posté par  . Évalué à 7.

    Alors là, quitte à se passer des relais du FAI, autant ne plus dépendre de personne, et installer un relais à la maison. De toutes façons, c'est ce que sont en train d'installer toutes les distributions Linux, vu que pour valider du DNSSEC, c'est presque inévitable.
    Et franchement, un résolveur DNS, c'est relativement facile à installer. Et à maintenir, c'est presque du niveau 0, y a juste les mises-à-jours de temps en temps.

    • [^] # Re: Un résolveur à la maison

      Posté par  (Mastodon) . Évalué à 4.

      Des liens ! Des liens !

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Un résolveur à la maison

        Posté par  (site web personnel) . Évalué à 3.

        • [^] # Re: Un résolveur à la maison

          Posté par  . Évalué à 6. Dernière modification le 05 janvier 2017 à 14:52.

          ok, comme je ne savais pas quoi faire cet après midi, j'ai mis ça en place sur mon raspberry pi3

          Je pense ma config ok, j'ai bien la résolution des noms de domaines :)
          Le cache est actif etc

          Par contre, je trouve les délais de résolution sur ma machine de bureau (qui pointe désormais sur mon RPI3 comme DNS) "assez" lent.
          Pour info, c'est à l'origine une image domoticz raspbian jessie.
          Le pi3 ne fait pas grand chose à l'heure actuelle à par servir domoticz et désormais unbound (activité ram et proc ok)

          Avec normalement le nom de domaine linuxfr.org déjà en cache : 188 msec
          En local sur le pi3, temps < 1msec

          [root@hyperion ~]# drill -D linuxfr.org
          ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 62684
          ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
          ;; QUESTION SECTION:
          ;; linuxfr.org. IN      A
          
          ;; ANSWER SECTION:
          linuxfr.org.    3476    IN      A       88.191.250.176
          
          ;; AUTHORITY SECTION:
          
          ;; ADDITIONAL SECTION:
          
          ;; Query time: 188 msec
          ;; EDNS: version 0; flags: do ; udp: 4096
          ;; SERVER: 192.168.0.12
          ;; WHEN: Thu Jan  5 14:17:45 2017
          ;; MSG SIZE  rcvd: 56

          Si je refais pointer mon resolv.conf sur le dns de google : 11msec

          [root@hyperion ~]# drill -D linuxfr.org
          ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 62967
          ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
          ;; QUESTION SECTION:
          ;; linuxfr.org. IN      A
          
          ;; ANSWER SECTION:
          linuxfr.org.    420     IN      A       88.191.250.176
          
          ;; AUTHORITY SECTION:
          
          ;; ADDITIONAL SECTION:
          
          ;; Query time: 11 msec
          ;; EDNS: version 0; flags: do ; udp: 512
          ;; SERVER: 8.8.8.8
          ;; WHEN: Thu Jan  5 14:17:22 2017
          ;; MSG SIZE  rcvd: 56

          Je précise que les deux machines sont en wifi, réseau géré par une freebox v6

          J'ai testé un peu plus, mon serveur pi3 donne quand même parfois des réponses de quelques msec
          Je ne vois rien qui corrèle entre les temps de réponse et l'activité du pi3

          #unbound local
          
          root@hyperion ~]# while true
          > do
          > drill -D linuxfr.org  | grep Query
          > sleep 5
          > done
          ;; Query time: 157 msec
          ;; Query time: 12 msec
          ;; Query time: 217 msec
          ;; Query time: 297 msec
          ;; Query time: 110 msec
          ;; Query time: 6 msec
          ;; Query time: 214 msec
          ;; Query time: 108 msec
          ;; Query time: 109 msec
          ;; Query time: 109 msec
          
          #dns google
          
          [root@hyperion ~]# while true; do drill -D linuxfr.org  | grep Query; sleep 5; done
          ;; Query time: 18 msec
          ;; Query time: 11 msec
          ;; Query time: 11 msec
          ;; Query time: 11 msec
          ;; Query time: 11 msec
          ;; Query time: 11 msec
          ;; Query time: 11 msec
          ;; Query time: 52 msec
          ;; Query time: 16 msec
          
          #sur le pi3
          /home/pi> while true; do drill -D linuxfr.org  | grep Query; sleep 5; done
          ;; Query time: 0 msec
          ;; Query time: 0 msec
          ;; Query time: 0 msec
          ;; Query time: 0 msec
          ;; Query time: 0 msec

          Avez vous des idées qui expliquent ces variations de temps de réponse, des test à faire ?
          Il faudrait peut être que je teste avec le pi3 en réseau filaire ?

          • [^] # Re: Un résolveur à la maison

            Posté par  (site web personnel) . Évalué à 8.

            ok, comme je ne savais pas quoi faire cet après midi, j'ai mis ça en place sur mon raspberry pi3
            (…) Le pi3 ne fait pas grand chose à l'heure actuelle à par servir domoticz et désormais unbound (activité ram et proc ok)

            J'imagine que le Pi3 est comme ses prédécesseurs dépourvu d'horloge matérielle, je préviens donc à l'avance : Unbound demande une horloge à l'heure afin d'effectuer les validations DNSSec. Ce qui généralement ne pose pas de souci quand le Pi est synchronisé avec NTP.

            Seulement voilà : au démarrage du système, NTP à besoin de résoudre un nom d'hôte avec DNS, qui demande lui-même d'être à l'heure… Je suggère fortement de vérifier comment les choses réagissent après un redémarrage, voire un arrêt complet.

            Il faudrait peut être que je teste avec le pi3 en réseau filaire ?

            Ça permettrait au moins d'avoir une connection réseau consistante.

  • # Quelques tests

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

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

    • [^] # Re: Quelques tests

      Posté par  (site web personnel) . Évalué à 4.

      Au sein de FFDN, il y aussi ARN qui fait le job correctement.

      Un petite synthèse incomplète est disponible ici: https://www.ffdn.org/wiki/doku.php?id=formations:dns des résolveurs proposés par les fai de FFDN.

      L'occasion est trop belle pour citer la page très bien faite des copains/copines d'ARN sur le sujet des résolveurs: http://arn-fai.net/recursif.

      Bonnes résolutions DNS à vous !

      • [^] # Re: Quelques tests

        Posté par  (site web personnel) . Évalué à 2.

        Une liste (AMHA) plus complète se trouve aussi ici: https://diyisp.org/dokuwiki/doku.php?id=technical:dnsresolver

      • [^] # Re: Quelques tests

        Posté par  (site web personnel) . Évalué à 1.

        Une occasion de signaler que j'ai compilé les resolvers ds FAI de la fédération FDN en enregistrements A et AAAA sur le domaine « mondns.eu.org ».

        S'il y a besoin d'avoir vite fait une liste de resolvers à utiliser autres que ceux de Google, un petit

        host mondns.eu.org

        vous évitera de devoir le retrouver dans une page de wiki.

        • [^] # Re: Quelques tests

          Posté par  (site web personnel) . Évalué à 1.

          S'il y a besoin d'avoir vite fait une liste de resolvers à utiliser autres que ceux de Google, un petit

          host mondns.eu.org

          Faudra quand même les utiliser un peu, les resolvers de Google, si on cherche des resolvers alternatifs pour cause de problème DNS, parce que sinon host va pas très très bien marcher… :-D

          • [^] # Re: Quelques tests

            Posté par  (site web personnel) . Évalué à 1.

            Ces resolvers ne sont pas « alternatifs ». Ils résolvent dans l'espace de nom de la racine très-très-officielle-sainte-et-infaillible de l'ICANN.

            À moins qu'on ne considère que les resolvers de Google sont la norme et utiliser autre chose comme une pratique pour personnes marginales.

            Sinon… si tu es en rade et que tu as besoin de vite fait changer les DNS pour un client parce que ceux de, au hasard, Orange, sont en rade… tu as pas un ordinateur de poche avec une carte SIM dedans pour un accès 3/4G et cet ordinateur de poche sais faire tourner host :-)

            • [^] # Re: Quelques tests

              Posté par  . Évalué à 3.

              Il veut surtout dire qu'il faudra bien résoudre mondns.eu.org. C'est pour moi l'intérêt du dns de google en 8.8.8.8

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # box du voisin

    Posté par  (site web personnel) . Évalué à 2.

    Utiliser le resolver de la box du voisin via son IP publique est aussi possible. Cela fait d'ailleurs parti des bonnes méthodes pour lancer une attaque par amplification.

    S'il a bien choisi son FAI tu pourras aussi profiter des protocoles chargen et echo

  • # Ceux du FAI

    Posté par  (site web personnel) . Évalué à 0.

    Le FAI peut écouter le trafic DNS donc dans tous les cas il peut tracer vos requêtes DNS.
    Utiliser un tiers permet à n'importe qui sur le chemin plus le tiers d'écouter, donc c'est de toutes façons pire.
    Une bonne raison de ne pas utiliser les serveurs DNS du FAI serait qu'ils soient menteurs.

    • [^] # Re: Ceux du FAI

      Posté par  (Mastodon) . Évalué à 2.

      Il est interdit aux FAI pour particuliers ayant pignon sur rue d’avoir des résolveurs DNS non menteurs en France, de plus, la plupart de nos gros FAI ne sont pas particulièrement « doués » dans le paramétrage et la gestion de leurs résolveurs…
      Ça leur fait de toute façon plus de boulot (et au réseau aussi) d’intercepter et analyser tout le trafic sur les ports TCP|UDP/53 que de mettre des logs sur leurs résolveurs. La seule bonne solution est d’avoir un résolveur récursif (avec au minimum validation DNSSEC et qname minimisation) sur son LAN.

  • # dnscrypt fr

    Posté par  . Évalué à 1.

    J'utilise ce resolveur DNSCrypt : https://fr.dnscrypt.org/

    Rapide, pas de censure, DNSSEC.

  • # Et ceux de verisign ?

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Verisign propose aussi des DNS public. Je ne sais par contre pas ce qu'ils valent côté vie privée…

    • [^] # Re: Et ceux de verisign ?

      Posté par  (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 06 janvier 2017 à 09:18.

      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 :-(

    • [^] # Re: Et ceux de verisign ?

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      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.

      • [^] # Re: Et ceux de verisign ?

        Posté par  . Évalué à 4.

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

        C'est une forme de sécurité de donner un peu d'information à différent groupe qui ne collaborent pas ensemble.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Résolveur dans la « box »

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    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.

  • # Sinon, y a tor

    Posté par  (site web personnel) . Évalué à 2.

    Tor permet de faire passer le DNS à travers le réseau.

    Il suffit d'ajouter par exemple dans le fichier torrc:

    DNSPort 127.0.0.125:53

    Et de mettre 127.0.0.125 dans la config. J'ai rajouté par dessus ça systemd-resolvd pour faire de la verif dnssec, mais je suis pas sur que ça soit déployer en pratique à beaucoup d'endroit.

  • # unboundé !

    Posté par  . Évalué à 1. Dernière modification le 08 janvier 2017 à 18:57.

    Ça faisait un moment que je pensais utiliser mon propre résolveur et ce sujet (ainsi que le sondage) m’a motivé à me lancer.

    J’avais un cache dnsmasq qui interrogait les DNS de Free sur mon routeur. J’y ai installé unbound à la place. C’est rapidement configuré et très simple.
    Bind9 m’avait fait renoncer il y a quelques mois.

    Par contre, tout comme littlebreizhman, j’ai des temps de réponse beaucoups plus importants.
    Est-ce une question de réglage ? Où simplement le fait de ne plus bénéficier du cache du FAI ?
    C’est visible dans le retour de drill, mais pour une utilisation « normale », je ne perçois pas de ralentissement particulier.

    Prochaine étape : DNSSEC !

    Merci Mimoza (et aux autres participants) !

    • [^] # Re: unboundé !

      Posté par  . Évalué à 3.

      Prochaine étape : DNSSEC !

      C'est activé (par défaut chez moi) dans unbound si on a, dans le fichier de conf, une ligne du genre

      auto-trust-anchor-file: "/var/lib/unbound/root.key"

      Ou alors, j'ai manqué quelque chose…

  • # mondns.eu.org

    Posté par  . Évalué à 0.

    Salut,

    La commande magique :
    dig A mondns.eu.org +short && dig AAAA mondns.eu.org +short

    Les DNS v4 et v6 affichés proviennent de FDN, LDN, Aquilenet, GRIFON, etc.. que du beau monde qui est là pour t'apporter du DNS neutre et fonctionnel :)

    • [^] # Re: mondns.eu.org

      Posté par  (site web personnel) . Évalué à 2.

      C'est la deuxième fois qu'il y a quelqu'un qui vient en faire la pub ici et le premier a visiblement pas compris ma remarque et a répondu encore plus à côté de la plaque, alors je la retente en plus clair :

      dig A mondns.eu.org +short && dig AAAA mondns.eu.org +short

      Vous avez bien conscience de l'incongruité de chercher un DNS de secours car celui de base ne fonctionne plus… par DNS ? Et là face au 8.8.8.8 de google c'est dur de lutter.

  • # Et directement sur modem/routeur ?

    Posté par  . Évalué à 0.

    Merci beaucoup pour toutes vos explications c'est très enrichissant.

    J'ai tenu compte des remarques sur le fait que ça n'est pas forcément la panacée. Mais je me posais la question de savoir si à travers un modem/routeur compatible OpenWRT on pouvait le faire, ce qui fait qu'on puisse changer les DNS dès la connexion… et limiterait le passage sur les DNS de la FAI…

    • [^] # Re: Et directement sur modem/routeur ?

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

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

      • [^] # Re: Et directement sur modem/routeur ?

        Posté par  . Évalué à -1.

        Merci de confirmer mon intuition. Je trouvais curieux que certains passaient par un Pi3 car au final la box elle, elle communique avec les DNS de la FAI.
        Je ne connaissais pas Turris, ça a l'air intéressant, mais je pense plutôt m'orienter vers des modem Asus auxquels on peut y mettre OpenWRT ou autre.

        • [^] # Re: Et directement sur modem/routeur ?

          Posté par  . Évalué à 2.

          Le PI3 fait serveur DNS et la box (après configuration pour remplacer les DNS par défaut) envoie son adresse IP à tous les pcs, smartphones et autres périphériques qui lui font une demande dhcp.
          Ils ne connaissent donc que le PI3 (dans cet exemple) comme serveur DNS pour leur requêtes.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.