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 tuxicoman (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 Marotte ⛧ . É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 Aeris (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 Stéphane Bortzmeyer (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 Kerro . É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 Anonyme . Évalué à 2.
Tu fais aussi peu confiance aux admin. sys. pour faire évoluer leur infrastructure ? Triste.
[^] # Re: unbound
Posté par Marotte ⛧ . Évalué à 2.
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 Stéphane Bortzmeyer (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 GreyXor . É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 Stéphane Bortzmeyer (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 marc.audefroy . É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 Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
Ben, c'est écrit sur leur propre site :
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.
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.)
Je suggère mon article
[^] # Re: Autre DNS et utilisation
Posté par marc.audefroy . Évalué à 1.
Thanks!
[^] # Re: Autre DNS et utilisation
Posté par pulkomandy (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 Nanawel (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 zeb . É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.
[^] # Re: Opennic + DNSCrypt
Posté par Naabster . Évalué à 3.
Wabon O° ? Il faut forcement un élément constitutif d'une église chrétienne (cf. Wikipédia) pour pouvoir utiliser DNSCrypt…
Cela va forcement freiner son utilisation en masse, dommage…
[^] # Re: Opennic + DNSCrypt
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
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
# Le mien
Posté par gouttegd . Évalué à 10.
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.
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 elf32 . É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 gouttegd . Évalué à 4.
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 Stéphane Bortzmeyer (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 Parleur . É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 Kerro . É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 Stéphane Bortzmeyer (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 Glandos . É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 gUI (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 David Marec . Évalué à 3.
juste fais le.
[^] # Re: Un résolveur à la maison
Posté par littlebreizhman . É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
Si je refais pointer mon resolv.conf sur le dns de google : 11msec
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
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 Ellendhel (site web personnel) . Évalué à 8.
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.
Ça permettrait au moins d'avoir une connection réseau consistante.
[^] # Re: Un résolveur à la maison
Posté par littlebreizhman . Évalué à 2.
Bonnes remarques, merci
Pour ntp, ça devrait aller, j'ai défini en forward-zone un autre serveur (en forward-addr). Si le mien ne trouve pas, la requête ira chez lui, non ? ou alors je n'ai rien compris…
J'ai testé un reboot, pas de soucis a priori.
Pour l'arrêt complet, je vais attendre que ça ce réchauffe, le pi3 et domoticz gèrent mon chauffage :)
Mais globalement et peut être subjectivement, je trouve que les accès aux pages web sont quand même plus rapides.
Pour la latence, je pense que ça vient du wifi et/ou du pi3, j'ai aussi un léger lag en ssh quand je tape mes commandes.
[^] # Re: Un résolveur à la maison
Posté par Larry Cow . Évalué à 4.
Je suppose que tu peux spécifier un de tes serveurs NTP de référence via son IP, pour limiter cet effet. Non?
[^] # Re: Un résolveur à la maison
Posté par Ellendhel (site web personnel) . Évalué à 2.
Probablement ; je n'ai pas encore testé ça. Je suis parti sur une solution un peu plus "solide" en prévoyant d'ajouter une horloge (DS3231 de son petit nom) à mon Pi. La commande est passée, reste à tester quand la livraison sera effectuée.
[^] # Re: Un résolveur à la maison
Posté par Misc (site web personnel) . Évalué à 2.
Sauf erreur de ma part, certains serveurs ntp (chrony par exemple) sont capable de stocker la date/heure sur le disque pour la reprendre quand ça redémarre. Ce qui fait que sauf si tu éteint la raspberry pi pendant longtemps (ie plus que quelques minutes), ça contourne le fait de ne pas avoir de RTC.
Une autre solution, c'est de mettre un GPS dessus:
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
Ou d'acheter une add on pour la raspberry pi. J'ai une cryptocape pour beaglebone (plus pour le TPM que pour le RTC), et y a la puce dont tu parles plus loin dessus: https://cryptotronix.com/products/cryptocape/
(mais intégré pour les boulets qui savent pas faire d’électronique comme moi)
[^] # Re: Un résolveur à la maison
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 1.
On peut aussi utiliser les signaux radio DCF77 (https://fr.wikipedia.org/wiki/DCF77) ou celui d'Allouis (https://fr.wikipedia.org/wiki/%C3%89metteur_d%27Allouis#Signaux_horaires). L'avantage sur le GPS est qu'ils sont plus faciles à recevoir depuis l'intérieur d'un bâtiment.
[^] # Re: Un résolveur à la maison
Posté par Benjamin Henrion (site web personnel) . Évalué à 1.
"NTP à besoin de résoudre un nom d'hôte avec DNS"
Pas forcément, tu peux lui spécifier des addresses IP.
http://serverfault.com/questions/701371/ntp-conf-pool-vs-server-directives
Maintenant il faut trouver une addresse IP d'un serveur NTP qui ne bouge pas. Et en mettre plusieurs.
# Quelques tests
Posté par Stéphane Bortzmeyer (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 petit (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 Misc (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 thy (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
vous évitera de devoir le retrouver dans une page de wiki.
[^] # Re: Quelques tests
Posté par Sufflope (site web personnel) . Évalué à 1.
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 thy (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 barmic . É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 Joris Dedieu (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 paulez (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 Hobgoblins Master (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 usbplug . Évalué à 1.
J'utilise ce resolveur DNSCrypt : https://fr.dnscrypt.org/
Rapide, pas de censure, DNSSEC.
# Et ceux de verisign ?
Posté par gilles renault (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 Stéphane Bortzmeyer (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 Stéphane Bortzmeyer (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 barmic . Évalué à 4.
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 Stéphane Bortzmeyer (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 Misc (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.
[^] # Re: Sinon, y a tor
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
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.
# unboundé !
Posté par sub0 . É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 littlebreizhman . Évalué à 3.
C'est activé (par défaut chez moi) dans unbound si on a, dans le fichier de conf, une ligne du genre
Ou alors, j'ai manqué quelque chose…
# mondns.eu.org
Posté par Noobinux . É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 Sufflope (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 :
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 AlexTérieur . É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 Stéphane Bortzmeyer (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 AlexTérieur . É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 littlebreizhman . É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.