Lors de chaque action volontaire et involontaire sur internet (navigation, email, …) votre ordinateur, votre smartphone ou encore votre tablette va demander à des serveurs DNS que vous ne connaissez pas où se trouvent les serveurs qui se cachent derrière un nom de domaine X ou Y. La création d’un résolveur DNS privé vous procure au moins trois avantages : la protection de votre vie privée, l’assurance que les informations obtenues sont vraies, et la rapidité.

Introduction

DNS est un constituant essentiel d’internet que tout le monde utilise quotidiennement sans trop se soucier de son fonctionnement. Avant chaque échange réseau lors de la navigation ou de l’envoi d’un email, votre ordinateur demande à un serveur extérieur les adresses IP qui se trouvent derrières leurs noms de domaine. C’est assez hallucinant, car même avant d’effectuer le moindre échange réseau, votre ordinateur est susceptible d’être écouté ou détourné pour des raisons publicitaires ou de censure.

L’objectif de cet article est de configurer un serveur DNS qui agisse en tant que « résolveur », c’est à dire capable de résoudre n’importe quelle requête DNS et de les conserver en cache, afin de répondre à vos propres besoins ou à ceux de votre entreprise.

L’image associée à cet article est une couverture d’un ouvrage des éditions O’Reilly qui n’a pas été utilisé pour la rédaction de cet article.

 

Pourquoi monter son propre serveur DNS ?

La vie privée

Comme cela est précisé en introduction, le serveur DNS fait le lien entre les domaines que vous souhaitez contactez et les adresses IP que vous contactez effectivement. Ainsi la personne ou l’entreprise qui gère le serveur DNS sait absolument tout de vos comportements sur internet.

En plus de cela, les échanges n’étant pas chiffrés, toutes les passerelles et tous les opérateurs réseau qui se situent sur le chemin entre vous et votre serveur DNS sont susceptibles de savoir également ce que vous faites sur internet et qui vous contactez.

Le serveur DNS le plus répandu sur internet est probablement 8.8.8.8 , le service DNS fourni par Google gratuitement et sans publicité, accessible depuis n’importe quel opérateur internet. Ce service de qualité respecte bien la philosophie de Google qui cherche officiellement à accélérer le web par différents moyens. Pour eux, la fourniture du service DNS est surtout un moyen de vous espionner un peu plus et de recouper votre utilisation DNS avec toutes les autres données amassées sur votre compte Google+, Gmail, vos données de géolocalisation, votre smartphone Android et bien entendu vos recherches sur internet.

Par les temps qui courent, c’est probablement cet aspect qui est déterminant pour monter son serveur DNS personnel.

Attention cependant, à ce jour Bind9 ne gère pas la fonctionnalité QNAME Minimization. Donc si vous utilisez Bind9 en tant que récurseur DNS, il communiquera la requête DNS complète au serveur TLD. Finalement, je ne sais pas si c’est mieux que forwarder les requêtes à son FAI. Pour bénéficier de ladite fonctionnalité, utiliser unbound ou bien knot.

 

Les serveurs DNS menteurs

En dehors de Google, on trouve des serveurs DNS gratuits mis à disposition par les grands d’internet comme Comodo, Level3, OpenDNS. Ces serveurs DNS ont l’inconvénient d’être menteurs, c’est à dire que si vous cherchez un domaine qui n’existe pas, au lien d’indiquer une erreur, ces serveurs vous renvoient vers leurs propres pages jonchées de publicité. Créer de la publicité sur du contenu qui n’existe pas, il fallait y penser !

Cela est fort désagréable et peut même vous causer de gros désagréments. Un cas de figure tout bête : il suffit que vous cherchiez à joindre une machine avec un diminutif absent de /etc/hosts pour que vos requêtes finissent sur un serveur inconnu avec des comportements incompréhensibles.

Enfin, de plus en plus de censure est réalisée par le biais de serveurs DNS menteurs, comme par exemple les états qui demandent aux FAI de bloquer l’accès à certains sites gênants ou illégaux. C’est une pratique controversée et vivement déconseillée par l’AFNIC, mais cela n’empêche pas les FAI de pratiquer cette censure. ZDnet explique justement qu’il faut utiliser un résolveur autre  pour contourner cette mesure.

 

La rapidité de résolution sur des requêtes en cache

Tous les résolveurs DNS ont la faculté de stocker l’information de résolution en mémoire cache afin que la prochaine requête identique soit accélérée. Configurer votre serveur DNS local peut accélérer toutes vos connexions réseau et notamment la navigation internet qui fait appel à de plus en plus de domaines avec les services externalisés d’annonces publicitaires et autres.

 

Le spam

Quel est le rapport entre DNS et le spam ? J’aurais du mal à l’expliquer rationnellement mais j’ai déjà remarqué sur un serveur mail d’entreprise que l’utilisation d’un resolveur DNS externe (8.8.8.8) avait entraîné une recrudescence de spam sur le serveur mail. La plupart ne passaient pas les filtrages anti-spam, mais c’est quelque chose qu’on veut éviter. Je ne connais pas en détails l’utilisation que fait le serveur email de DNS, notamment sur la résolution inverse.

Il faut croire que les demandes de résolution DNS laissent des traces sur le réseau, et il faut croire aussi que les spammeurs ont les moyens de les écouter.

En gros : si vous avez un serveur de mail je vous conseille d’utiliser également votre propre serveur DNS.

 

Installation de bind

Le serveur DNS bind a la particularité d’être à peu près aussi vieux qu’internet, c’est le serveur DNS de référence qui s’appuie directement sur les RFC pour implémenter le protocole DNS. C’est assez logiquement la référence du secteur.

Sous debian, son installation se fait par apt-get install bind9 . Il y a également d’autres paquets forts utiles à installer pour tester le serveur comme : bind9-host , bind9utils  et dnsutils . Le fichier de configuration par défaut se trouve dans /etc/bind8/named.conf.options .

En l’état ce fichier est suffisant pour faire fonctionner le serveur, mais il y a tout de même des paramètres à définir, à fortiori si le serveur se trouve sur internet.

Configuration du serveur DNS

Les permissions d’accès au serveur DNS

Même si DNS n’est pas un protocole réseau gourmand en ressources, vous n’avez pas intérêt à ce que votre serveur fonctionne pour n’importe qui. Voici les restrictions que j’utilise pour définir qui a le droit d’utiliser mon serveur.

Chaque directive peut être renseignée avec une adresse IP ou un groupe d’adresses IP avec masque CIDR. Voici à quoi elles correspondent :

• listen-on : adresses IPv4 sur lesquelles le serveur va écouter.
• listen-on-v6 : adresses IPv6 sur lesquelles le serveur va écouter.
• filter-aaaa-on-v4 : ne pas répondre sur les requêtes AAAA même si bind répond sur son interface ipv4.
• allow-recursion : adresses IPv4 pour lesquelles les réponses vont être données même sur des zones DNS qui ne sont pas directement gérées par le serveur sur des domaines étrangers.
• allow-query : adresses IPv4 autorisées à joindre le serveur
• allow-query-cache : adresses IPv4 autorisées à joindre le serveur pour des demandes déjà stockées en cache

 

L’activation de DNSSEC

DNSSEC est la version sécurisée de DNS un peu comme https pour http. Ce protocole permet de s’assurer que les réponses correspondent effectivement à ce que le propriétaire du domaine a défini. Il rend impossibles ou difficiles les attaques par DNS spoofing qui consistent à détourner un trafic avec un serveur DNS menteur.

Pour activer DNSSEC sans que le serveur ne nous assaille d’insultes dans les logs, il faut définir trois paramètres.

Ces lignes correspondent aux paramétrages suivants.

• dnssec-enable : pour activer tout simplement DNSSEC
• dnssec-validation : le résolveur va valider les réponses DNSSEC faites depuis des zones signées
• dnssec-lookaside : le serveur DNS va lire le fichier de clés bind.keys, pour conserver la chaîne de validation même si le TLD ne gère pas les zones signées. Ce réglage m’a permis à l’époque d’éviter une multitude de messages d’erreurs dans les logs.

A l’inverse pour désactiver DNSSEC sans s’embêter avec la configuration :

 

L’ajout d’un forwarder

Par défaut le serveur bind va résoudre toutes les requêtes DNS tout seul en se référant au serveur DNS racine pour l’extension (.fr, .com, .org, …) puis au serveur DNS en charge de la zone demandée (mon-domaine.fr, mon-domaine.com, mon-domaine.org, …).

Pour accélérer la résolution, on peut exploiter un autre serveur DNS, un résolveur DNS vers lequel on va forwarder (ou rediriger) les requêtes.

Par défaut, bind ne va forwarder que quand la résolution absolue a échoué. Pour modifier ce comportement on peut utiliser la ligne forward first; ou encore forwarder toutes les requêtes sans chercher à les résoudre depuis le serveur racine, on peut utiliser la ligne forward only; . Mais si vous avez suivi, ce n’est pas trop l’esprit ce cet article.

 

Modification du fichier de dump

Au tout début du fichier, on peut spécifier un fichier de dump personnalisé. La ligne qui suit est facultative car cet emplacement est celui par défaut.

Ce fichier sera utilisé lorsque la commande de dump des informations DNS en mémoire est demandé avec la commande suivante.

Modification des fichiers de log

Par défaut, bind9 ne logue pas les requêtes DNS sauf celles en erreur, et c’est probablement une bonne chose pour la confidentialité.

Vous pouvez néanmoins spécifier un fichier de log par catégorie de messages : default, general, database, security, config, resolver, queries, network, … Voir Bind9 sur le wiki Debian pour plus d’informations sur le logging. Le manuel Bind sur Zytrax.com indique toutes les catégories possibles.

Sur un serveur DNS de production, activer le queries logging est une entorse à la confidentialité des utilisateurs du réseau. Cela dit les serveurs DNS des opérateurs réseaux et les systèmes d’écoute des gouvernements ne doivent pas se priver.

Sur un serveur DNS privé, dans un but de tests, le log des requêtes DNS est très instructif pour se rendre compte à quel point la navigation internet et le flicage des outils de statistiques (Analytics, Xiti, Doubleclick, etc) requièrent de domaines différents. En effet chaque domaine interrogé par HTTP correspond à une demande de connexion pour récupérer un contenu, une image, un pixel caché, une fonte, avec un header HTTP qui contient la plupart du temps un champ « Referer: » qui indique la page source (sauf lien http sur page https).

Le cache

A chaque redémarrage du serveur, le cache DNS est remis à zéro et il se reconstitue en mémoire au fil des requêtes. Il n’y aurait aucune raison de vouloir un cache persistant car les informations DNS sont susceptibles de changer dans le temps et doivent être rechargées à intervalle régulier auprès du serveur maître passé un délai qu’on appelle le TTL (time to live).

A ma connaissance il n’existe pas d’autre méthode pour remplir le cache que d’effectuer des requêtes avec dig ou tout autre outil.

 

Si votre serveur DNS est une passerelle

En bonus, si votre serveur DNS a la particularité d’être également votre passerelle, voici une règle iptables qui permet d’intercepter les requêtes qui transitent par la passerelle et de les dérouter pour que le serveur DNS local y réponde plutôt que le serveur DNS demandé par le client.

Cela a l’avantage d’exploiter votre serveur DNS tout neuf, même pour les membres du réseau qui voudraient aller chercher l’information DNS ailleurs. Comme le navigateur Chrome par exemple qui a été critiqué pour utiliser ses propres serveurs DNS.

A mon avis les FAI utilisent ce genre de méthodes pour optimiser leur réseau. On peut appeler cela le proxy DNS transparent.

La seule raison qui fait que ce type de redirection barbare fonctionne sans provoquer d’échec, c’est que le protocole DNS n’est absolument pas sécurisé du point de vue de l’authentification (hors DNSSEC).