[DNSCRYPT] [DNSSEC] [Unbound] : Chiffrer, sécuriser et optimiser les requêtes DNS

J'ai publié avant sur ce blog, 2 articles concernant OpenDNS :
OpenDNS pour surfer plus vite et Surfer plus vite/Se protéger du phishing

Mais est ce qu'on peut faire vraiment confiance à OpenDNS ?

Sur les conditions d'utilisation de ce service, les parties qui nous intéressent pour le moment, sont :

OpenDNS's DNS service collects non-personally-identifying information such as the date and time of each DNS request and the domain name requested.

OpenDNS also collects potentially personally-identifying information like Internet Protocol (IP) addresses of website visitors and IP addresses from which DNS requests are made. For its DNS services, OpenDNS is storing IP addresses temporarily to monitor and improve our quality of service.

In addition, we may combine non-personally-identifiable information with personally-identifiable information in a manner that enables us to attribute website and DNS service usage to an individual customer's computer or network.

Other than to its employees, contractors and affiliated organizations, as described above, OpenDNS discloses potentially personally-identifying and personally-identifying information only when required to do so by law, court order, or when OpenDNS believes in good faith that disclosure is reasonably necessary to protect the property or rights of OpenDNS, third parties or the public at large.

Donc la réponse est : non. Sans trop compliquer les choses, il suffit de savoir que ce service enregistre des fichiers logs des requêtes, pour dire non :-)

Je connais bien d'autres alternatives, mon choix va se poser sur deux critères :

1. Pas de logs 
2. Compatibilité avec DNSSEC 

Et ça donne :

CloudNS (no logs)  : Australia 

OpenNIC (no logs) : Japan 

DNSCrypt.eu (no logs) : Holland

En testant le temps de réponse d'une requete ping sur les 3 serveurs, j'ai décidé de choisir DNSCrypt.eu, évidemment si tu habite dans les îles Cocos de l'océan indien, tu va choisir CloudNS.

Dans ce tutoriel on va utiliser DNSCrypt, Unbound et DNSSEC .

On va utiliser un script pour automatiser l'installation de DNSCrypt. Sur un terminal, commencez par taper :

# wget --no-check-certificate https://raw.github.com/simonclausen/dnscrypt-autoinstall/master/dnscrypt-autoinstall.sh
# chmod +x dnscrypt-autoinstall.sh
# ./dnscrypt-autoinstall.sh

Tapez votre choix, et laissez le script jouer.

De la même façon que SSL peut sécuriser une requête HTTP simple en envoyant une requête HTTPS chiffré, DNSCrypt crypte le trafic DNS pour assurer plus de protection et d'intégrité. Sauf que les requêtes entrantes ne seront pas mises en cache et pour chaque requête il faudra un aller-retour vers le serveur DNS. Et c'est pour cette raison qu'on va utiliser Unbound.

Le choix de Unbound, vient du faite qu'il est plus facile à configurer que Bind pour un petit réseau local.

Pour installer :

# apt-get install unbound

Et ensuite pour configurer :

# vi /etc/unbound/unbound.conf

Voici un exemple de fichier de configuration simple pour 3 machines du LAN : xbox, freeboxplayer et freebox (trouvé à la base sur Ubuntu-fr et modifié pour fonctionner avec DNSCrypt) :

server:
verbosity: 1
num-threads: 4                                                      
port: 533
interface: 0.0.0.0
 do-ip4: yes
 do-udp: yes
 do-tcp: yes
 access-control: 192.168.0.0/24 allow              
 do-not-query-localhost: no
 chroot: ""    
 logfile: "/var/log/unbound.log"          
 use-syslog: no
 hide-identity: yes
 hide-version: yes
 harden-glue: yes
 harden-dnssec-stripped: yes
 use-caps-for-id: yes    
 private-domain: "localhost"    
 local-zone: "localhost." static
 local-data: "freebox.localhost. IN A 192.168.0.254"                                            
 local-data-ptr: "192.168.0.254 freebox.localhost"
python:
remote-control:
forward-zone:
  name: "."
  forward-addr: 127.0.0.1@40

La configuration dépend de la nature de votre serveur DNS : autoritaire ou récursif . Pour un serveur autoritaire, supprimez 

name:"."forward-addr: 127.0.0.1@40

et ajouter à la place : 

root-hints: /etc/unbound/named.cache

sur votre fichier /etc/unbound/named.cache, exécuter cette commande :

# wget ftp://FTP.INTERNIC.NET/domain/named.cache -O /etc/unbound/named.cache

et finalement, on va activer DNSSEC.

Selon wikipedia : DNSSEC permet de sécuriser les données envoyées par le DNS. Contrairement à d'autres protocoles comme SSL, il ne sécurise pas juste un canal de communication mais il protège les données, les enregistrements DNS, de bout en bout. Ainsi, il est efficace même lorsqu'un serveur intermédiaire trahit. 

C'est simple, il suffit d'ajouter ces lignes à /etc/unbound/unbound.conf :

server:
# The following line will configure unbound to perform cryptographic
# DNSSEC validation using the root trust anchor.
auto-trust-anchor-file: "/var/lib/unbound/root.key"

ps : Le fichier /var/lib/unbound/root.key peut être dans un autre emplacement . 

Update : Avant de démarrer quoi que ce soit, vérifiez s'il y a la ligne suivante dans votre fichier /etc/resolv.conf :

nameserver 127.0.0.1

Actuellement, Unbound est configuré de se lancer à chaque démarrage. Pour lancer le service tapez : 

# service unbound start  

Attention si vous avez Bind installé, le service ne démarrera pas et affichera un truc de ce genre : 

unbound[8878:0] error: bind: address already in use[1382606879]
unbound[8878:0] fatal error: could not open ports

En tapant :

lsof -nPi | grep \:53

Vous allez voir que Bind et Unbound utilisent tous les deux le port 53, ce qui crée un conflit.
Pensez alors à changer ce port et ajouter un numéro de port non utilisé au fichier /etc/unbound/unbound.conf (je choisis ici 533) :

port: 533 

Enfin, partagez cet article si vous l'avez apprécié .
Si vous avez aimé cet article vous pouvez vous inscrire au flux RSS
Inscrivez vous à mon flux RSS Ou bien partager cet article pour vos amis !