DNS : Serveurs publics, alternatifs, respectueux ... voire chiffrés

Trucs et Astuces
#1

Je ne sais pas trop comment je vais structurer ce post - donc, ne pas m’en vouloir … de plus, ce post existe de part cette information, qui provoque ce post en (ré?)action ! :smiley:
Je n’aborde pas, non plus, l’aspect de ceux qui hébergent par leur moyen leurs propres serveurs DNS.

Le but est d’informer des choix des DNS, hormis ceux fournis par votre FAI personnel, ceux de Google, voire ceux d’OpenDNS, dont je ne dirais pas plus …

Vous voulez faire confiance à ceux-là, très bien, c’est votre choix !

Mais … il existe des alternatives dont certaines respectent vos communications, faisant réellement partie de la communauté Open Source et/ou libristes, et oeuvrant au sein de celles-ci :

Pour tout le monde :

  • OpenNIC - la liste de serveurs disponibles : certains ne journalisent pas l’activité (les “Log Anon” et/ou permettent la connexion DNSCrypt - choisir de préférence, ceux qui offrent les deux services.

Pour nous autres français, il y a :

  • FDN
    ipv4: 80.67.169.12, 80.67.169.40
    ipv6: 2001:910:800::12, 2001:910:800::40
  • LDN
    ipv4: 80.67.188.188
    ipv6: 2001:913::8

Pour nos “amis les suisses”, il semble y avoir :

Plus haut, dans le contexte d’OpenNIC, j’ai fait allusion à DNSCrypt.
Ce projet est intéressant à plus d’un titre : le but est d’améliorer la sécurité des connexions et informations qui se “passent” entre un serveur DNS, et un client dns.
Bref, ça passe principalement par des requêtes TCP/UDP sur le port 443, en sortie, et utilise des signatures de “chiffrage”.
Pour en profiter, il existe l’outil dnscrypt-proxy, logiciel multi-OS.

Pour ceux qui hébergent leurs propres serveurs DNS, il existe une libraire qui permet de communiquer avec … il me semble avoir lu que le projet dnscrypt-proxy est capable de communiquer avec unbound. À vérifier …

Bref, si vous ne voulez pas que vos communications DNS soient “lisibles”, n’hésitez pas !

Pour en profiter, sur Debian, il faut utiliser Sid, ou Testing.

Oui, j’en ai parlé, il y a quelques semaines, dans ce mémo, utile pour les *Buntu !

“Enjoy-ID!”
“Enjoy-IT!”

2 J'aime
#2

Ahah,
Si tu arrive a me pondre un tuto fonctionnel de dnscrypt tu deviens mon dieu de la journée ou je le lirais ^^, comme je disait sur framasphère, disons que mes démeller passer avec lui me donne plus du tous envie de faire les test moi même (après avoir réinstallé 8 fois debian car dncrypt avait tuer ma connexion xD)

#3

Encore mieux ! pour les personnent utilisant le paquet tor en version 0.2.x , il existe un moyens a activé manuellement pour pouvoir utiliser le dns qu’utilise tor pour ce faire en mode super user :
modifier /etc/tor/torrc

y ajouter :

DNSPort 9053
AutomapHostsOnResolve 1
AutomapHostsSuffixes .exit,.onion

Sauvegarder et restart tor

service tor restart

tester

dig @localhost -p 9053 debian.org

si cela fonctionne dire a unbound de suivre 127.0.0.1@9053

restart unbound (vérifier que le system utilise le dns 127.0.0.1 (si ce n’est pas le cas changer et restart la connexion))

et voila vos utilitaire utiliseront un dns a traver tor (si tous c’est bien passer)

Edit : pour un autre test pour vérifier que sa fonctionne “service tor stop” et essayer d’ouvrir un “Nouveau” site que le cache unbound n’a pas encore stoqué, le site ne chargera pas

2 J'aime
#4

L’information de ce jour est l’ouverture des DNS de FDN à tous !

https://www.fdn.fr/actions/dns/

J’ai donc màj le premier post !

#5

Peut-être à noter aussi le récent article du Linux Journal : Own your DNS data.

En anglais certes. Dès que j’aurai eu le temps de le tester à la maison, j’essaierai d’en faire un tuto condensé en french :slight_smile:. Ou si une autre âme charitable se sent !

#6

Tester quoi? Bind?

#7

Ta réponse suggère que l’installation seule de BIND, et l’utilisation de 127.0.0.1 comme serveur DNS suffit, c’est le cas ? Comment le vérifier ?

#8

Je sais pas si c’est à moi que tu réponds? Si oui, alors dans ce cas ma réponse ci-dessus faisait référence à l’article en anglais que tu as posté et qui parle d’installer son propre serveur DNS, cache et/ou récursif… Et comme tu parlais de tester c’est pour ça que j’ai demandé tester quoi pour en faire un tuto… Mais je suppose qu’il s’agit bien de Bind :slight_smile:

Par contre ici je sais pas ce que tu veux dire par l’installation de Bind seule suffit…? Suffit pour quoi?

#9

Oui oui :slight_smile:

J’avais supposé, à tort apparemment, qu tu avais jeté un œil à l’article du Linux Journal et que tu le résumais à “Installer BIND”.

Pour ma part, il faut encore que je potasse l’article, notamment la config de BIND. Actuellement je l’ai d’installé et je sais qu’il me sert de cache, mais il me semble qu’en cas d’enregistrement DNS absent du cache, il interroge le serveur DNS de mon FAI et non un serveur DNS root comme c’est décrit dans l’article. Il faut que je voie comment m’y prendre :confused:.

#10

Non pas à tort au contraire, comme je te disais au-dessus, j’ai lu l’article :smiley:
Mais effectivement il se résume à installer bind9 en tant que serveur DNS cache et/ou recursif.

L’article est très léger quant à la config de BIND, c’est vraiment succint. Et d’ailleurs j’ai moi-même toujours pas trouvé de tuto complet qui explique en détail chaque option, mais bon j’imagine que c’est pour une bonne raison quand tu vois le man de “named.conf” et le nombre d’options qu’il y a…, j’imagine qu’il faudrait faire un bouquin entier, ce ne serait plus un tuto…
Après perso j’ai regardé sur plusieurs tutos puis j’ai ajouté perso ce qui me semblait pertinent, mais je pense que je peux encore optimiser la config ; en tous cas je suis sûr de ne plus passer par les DNS de mon FAI…

Tu peux toujours donner ici tes fichiers config pour qu’on jette un oeil :wink:

#11

Il suffit de laisser vide la liste des forwarders { } et de ne pas mettre forward only.
Note que BIND n’interrogera pas que les serveurs racine (qui ne connaissent pas tout mais seulement la liste des NS des domaines de premier niveau), mais aussi tout serveur faisant autorité pour une information nécessaire à la résolution de la requête traitée.

#12

Merci @GOGI et @PascalHambourg, j’ai fait mes petits tests et effectivement, en déclarant localhost comme seul serveur DNS dans mon resolv.conf, je résous bien les noms domaines. BIND fonctionne donc out of the box, c’est cool :slight_smile:.

J’ai du mal à saisir la subtilité :confused:. Dans le cas typique d’une requête HTTP GET vers un serveur www.toto.fr, qu’est-ce qu’il y a de plus à traiter que la résolution en cascade . -> fr -> toto -> www ? Quelles sont ces autres “informations nécessaires” ?

#13
  • Les nom et adresse IP d’un serveur faisant autorité pour la zone “fr”, obtenus auprès d’un serveur racine,
  • les nom et adresse IP d’un serveur faisant autorité pour la zone “toto.fr”, obtenus auprès d’un serveur faisant autorité pour la zone “fr” et éventuellement d’autres serveurs si ce nom n’est pas sous “fr”.
    Il faut donc interroger au moins trois serveurs pour résoudre “www.toto.fr”, et pas seulement un serveur racine.
1 J'aime
#14

@seb-ksl,

:wink:

@PascalHambourg,

Tu n’aurais pas une page internet sous la main avec un tuto qui détaille chaque option de config pour les fichiers BIND? Car après avoir fouillé sur le net depuis un certain temps les seules pages sur lesquelles je tombe ne font que donner une description succinte des options…

#15

Non. A mon avis le but d’un tutoriel n’est pas de détailler les options mais de décrire comment réaliser telle ou telle configuration.

J’utilise le “manuel de référence d’administration” de BIND (BIND ARM) au format PDF, récupéré sur le site de l’ISC.

#16

lapsus de ma part…

Je vais y jeter un oeil, merci.

#17

Salut
au test https://www.grc.com/dns/dns.htm

Que pensez-vous de https://www.verisign.com/fr_FR/security-services/public-dns/index.xhtml

Réferencé par https://www.icann.org/resources/pages/dnssec-qaa-2014-01-29-fr