Mise à jour 19/12/2021 : Utilisez plutôt Pi-Hole pour ça maintenant !
Sous-titre : "Mais continuez à gérer les DNS locaux via votre box".
Si vous avez suivi l'actualité ces derniers mois, vous savez certainement que l'accès Internet par les principaux FAI en France (Orange, Bouygues, Free, SFR) vient d'en prendre un (premier ?) coup au niveau de sa neutralité.
La cause ? Un ordre du TGI de Paris qui leur a demandé d'interdire les accès à plusieurs sites web dont - évidemment - ThePirateBay et ses nombreux miroirs.
En termes techniques, l'application de ces restrictions par les opérateurs a consisté à modifier leurs DNS afin qu'il ne résolvent plus les adresses des domaines concernés. C'est évidemment très idiot - autant sur le plan technique que politique - donc je ne m'attarderai pas sur cet aspect, d'autres le font mieux que moi.
RÉ-PON-SE--IN-VA-LI-DE. DOIT-DÉ-TRUIRE-LE-PI-RA-TA-GE. BIP.
Étant client chez le FAI au carré rouge®™, je subis donc ces restrictions depuis mon accès ADSL. Ce n'est pas que je télécharge des tera-octets de données quotidiennement sur TPB, mais plutôt le principe qui me dérange. Comme je ne suis pas encore prêt à passer par un FAI associatif type FdN, il me reste soit à faire avec, soit à trouver une solution de contournement.
Alors oui, il y a la réponse classique copyright jeuxvideo.com : b1 c simpl, change le DNS 2 ton PC é utiliz cui de Google a la place lol xpdr.
Oui, mais non, pour les raisons suivantes.
- Tout d'abord, ce n'est pas un problème de "mon PC", mais de "mon cheptel". Car oui, derrière ma box se cachent une dizaine de machines, plus ou moins actives à un moment donné. Si je pouvais centraliser la gestion du DNS comme le fait ma box actuellement, ça serait quand même mieux (cache DNS, etc.).
- Ensuite, si contourner une restriction de son opérateur qui se torche allègrement avec la neutralité du Net signifie se jeter dans les bras de Google (si chauds et confortables qu'ils soient), alors la morale de l'histoire a des relents de poisson pourri. Donc non, si je dois utiliser un autre serveur DNS, ça sera en priorité celui d'une organisation un peu plus regardante niveau respect de la vie privée (tiens, celui de FdN par exemple).
- Pour finir, et c'est la raison principale de cet article, je dépends étroitement des "DNS personnalisables" de ma box pour y inscrire les noms des machines de mon cheptel, afin que ceux-ci soient connus de toutes sur mon LAN. Ces noms sont évidemment privés, et peuvent être qualifiés de domain-less (car ce sont de simples noms de machines, sans domaine associé). Cette situation a des raisons historiques, et en tant que telle, tout changement pourrait faire sortir la Terre de son axe (voire pire). Or, utiliser un DNS public à la place de la box me fera perdre ces correspondances et m'obligera à les ajouter dans les fichier /etc/hosts de chacune des machines. Galère !
Une petite liste de DNS internes sur ma box...
Je me suis donc dit qu'il serait plus pratique de confier la gestion des DNS à une autre machine centrale de mon réseau, toujours disponible, et qui utiliserait comme résolveur final un serveur DNS public qui ne serait pas celui de mon FAI.
Mais !
Uniquement pour les noms avec domaines évidemment ! Car je souhaite continuer à utiliser ma box pour gérer les (nombreux) noms de machines depuis cet endroit. Elle doit également continuer à gérer le DHCP - ce qui impliquera de devoir préciser le serveur DNS manuellement sur les machines, mais uniquement lui. Ces contraintes sont liées à différents facteurs, dont une factrice (j'me comprends ^^).
Le principe étant d'altérer le moins possible l'infrastructure du réseau, et de ne surtout pas toucher à ce qui marche.
La machine centrale qui gèrera ce relai DNS est toute trouvée : Usul, mon serveur sous Debian dispo 24/7/365 et qui ne craint pas d'héberger un petit serveur DNS ou tout autre logiciel nécessaire.
En résumé, mon plan est donc celui-ci (en vue logique "trafic DNS") :
Le but ici sera simplement de ne plus avoir ces requêtes qui partent vers le DNS du FAI
Installation du serveur
Quid à présent de la mise en place de ce relai DNS ?
Vu que je ne connais pas grand chose dans le domaine, j'ai fait quelques recherches et je suis initialement parti avec BIND9, référence dans le domaine et présent sur toutes les distros GNU/Linux...
Ô l'erreur. Totalement hors de portée pour moi, surtout vu l'usage que je comptais en faire, d'autant que je me suis rendu compte après-coup que ce n'était d'ailleurs même pas possible ! (faire du relai DNS si, bien sûr, mais pas de manière sélective avec mes noms domain-less)
J'ai galéré un moment avant de me tourner vers... dnsmasq. Un serveur DNS justement spécialisé dans le relai, et beaucoup plus simple à mettre en place.
Avec celui-ci, il est possible de définir des serveurs DNS finaux par domaine, et également de définir un serveur DNS pour les noms simples, donc domain-less. Dans mon cas, les requêtes concernant des FQDN seraient donc routées vers le serveur DNS public neutre, et les requêtes vers des noms de machines seraient résolues - comme c'est le cas actuellement - par la box.
Pour l'installation sur une Debian (ou Ubuntu, ne soyons pas raciste), c'est très simple :
# apt-get install dnsmasq
Le daemon devrait être lancé à la fin de l'installation. Personnellement ce package était déjà présent sur mon installation, même si je n'avais pas le souvenir de l'avoir installé manuellement.
Il faut ensuite s'assurer que le daemon est bien configuré pour être lancé au boot. Pour cela, éditez le fichier /etc/default/dnsmasq et passez la variable ENABLE à 1.
On passe ensuite à la configuration du serveur proprement dite. Par convention, on ne touchera pas au fichier /etc/dnsmasq.conf. On créera à la place un fichier /etc/dnsmasq.d/custom-lan.conf (le nom importe peu) qui viendra surcharger proprement les directives du premier fichier.
Je me suis basé sur les la présentation disponible ici et évidemment sur le manuel là.
Quelques explications sur chacune des directives :
bogus-priv
Empêche les requêtes inversées (IP vers nom) d'être retransmises vers le serveur DNS distant pour tous les réseaux privés (ex : 192.168.x.x) si aucune correspondance n'est trouvée dans /etc/hosts.
cache-size=512
Je précise une taille de cache de 512 entrées pour les résolutions DNS effectuées. Toute entrée présente dans le cache et encore valide (TTL) sera renvoyée directement au lieu d'interroger le serveur DNS distant. C'est donc un point important pour mutualiser les résolutions, comme le faisait la box jusque-là.
no-resolv
no-hosts
Ici c'est particulier, car on va rendre dnsmasq autonome, "coupé" du système qui l'héberge : mon serveur Usul.
La première ligne lui interdit de se servir du fichier /etc/resolv.conf pour connaître les serveurs DNS à interroger, ceci car les serveurs en questions seront définis plus loin.
La seconde lui interdit également de se servir du fichier /etc/hosts. En effet, ce fichier est réservé aux surcharges (ou aux définitions plus généralement) des DNS pour la machine elle-même. Je ne souhaite pas que ces définitions soient renvoyées aux requêtes envoyées par les autres machines de mon LAN. C'est un choix personnel, à adapter au besoin.
log-queries
log-dhcp
log-facility=/var/log/dnsmasq.log
Ces lignes-ci sont plus optionnelles : elles activent simplement le log des requêtes traitées dans le fichier spécifié (et aussi des demandes DHCP, mais ici je ne l'utilise pas - encore). C'est en consultant ce fichier que j'ai découvert la technique spéciale mais un peu étrange de Chrome/Chromium pour détecter les DNS menteurs.
#Neufbox
server=//192.168.1.1
#FDN
server=80.67.169.12
# Google
#server=8.8.8.8
C'est (enfin) la partie importante. Ici sont définis les serveurs DNS à utiliser pour résoudre les deux types de noms que nous aurons à gérer : les domain-less, et les autres.
La syntaxe complète de la directive server est la suivante :
[/[<domain>]/[domain/]][<ipaddr>[#<port>][@<source-ip>|<interface>[#<port>]]
Elle permet de définir pour un ou plusieurs domaines (précisés entre les slashes), un serveur à interroger.
On pourrait donc avoir :
server=/gouv.fr/8.8.8.8
pour interroger le serveur DNS 8.8.8.8 pour tout domaine situé sur gouv.fr.
Et si les deux slashes sont vides ? Eh oui, on définit un serveur à interroger pour les noms domain-less. Ici c'est donc l'adresse IP de la box qui est précisée pour ces requêtes.
Pour toutes les autres, c'est le serveur DNS de FdN qui sera utilisé. Celui de Google est présent mais commenté, si jamais j'en ai besoin, je n'aurai qu'à le décommenter.
Pour donner des chiffres, le serveur de FdN me répond généralement entre 47 et 55ms, quand celui de Google oscille entre 45 et 100ms. La proximité géographique du premier doit y être pour quelque chose j'imagine.
Ne reste plus à présent qu'à appliquer les changements, ce qui se résume à un classique
# /etc/init.d/dnsmasq restart
À partir de cet instant, dnsmasq écoute les requêtes entrantes sur le port standard UDP/53.
Configuration des clients
La partie "serveur" étant terminée, il faut à présent modifier les clients (donc les autres machines du LAN) afin qu'ils utilisent désormais notre dnsmasq et plus celui fournit via DHCP par la box.
Avec NetworkManager
On retrouve cette configuration généralement sur toute machine disposant d'un environnement graphique (mais pas exclusivement). Des applets permettent ensuite depuis le bureau de configurer le réseau.
C'est donc très facile, il suffit d'ouvrir le gestionnaire de connexion, puis de modifier le profil pour utiliser l'attribution de l'adresse via DHCP avec un DNS manuel. Sur mon exemple l'adresse IP de la machine hébergeant dnsmasq est 192.168.1.254.
Dans mon cas, c'est ma machine de bureau "Leto" sous Archlinux qui doit être configurée ainsi.
Avec /etc/network/interfaces
Ici tout se fait via les fichiers de configuration.
Pour configurer une interface réseau en DHCP on pourra lire la doc de Debian ici.
Et pour configurer le serveur DNS, toujours sur la même page un peu plus loin ici.
Afin qu'Usul bénéficie lui aussi du nouveau DNS, j'ai d'ailleurs dû le configurer lui aussi grâce à cette méthode pour que les requêtes DNS passent par localhost (donc par dnsmasq) au lieu du DNS fourni par la box. Mon fichier /etc/resolv.conf contient donc à présent la ligne
nameserver 127.0.0.1
(et non plus 192.168.1.1).
Résumé
À ce jour, la box conserve son rôle central sur le LAN dont :
- l'attribution des adresses IP via DHCP
- la gestion des DNS pour les machines du LAN
Toute machine qui se connecte au réseau en mode "full-DHCP" utilisera donc la box comme serveur DNS, qui relaye - si nécessaire - vers celui du FAI, avec les restrictions associées. Pas de changement à ce niveau, on conserve donc le fonctionnement existant.
Si par contre on souhaite, disons "un peu plus de liberté" dans sa résolution de noms, il est possible de configurer son poste en DHCP tout en précisant manuellement le serveur DNS hébergé sur Usul (daemon dnsmasq). Celui-ci est configuré de telle sorte que les requêtes portant sur des noms de domaines pleinement qualifiés seront relayées vers le serveur DNS externe (neutre), alors que les requêtes portant sur des noms de machine seront relayées vers la box, qui saura les résoudre directement.
La seule contrainte de la seconde méthode est de devoir configurer manuellement sur chaque poste le serveur DNS à utiliser, plutôt que celui fourni par DHCP. Cette technique présente cependant l'avantage de ne pas modifier le fonctionnement du LAN, et d'apporter simplement une "alternative".
Il est important de préciser que ce qui est fait ici sur un PC "normal" utilisé comme serveur (x86 avec carte mère mini-ITX), peut être également et aussi facilement mis en place sur une plateforme beaucoup plus réduite, type Raspberry Pi par exemple. La méthodologie sera exactement la même en utilisant alors Raspbian. Il est donc extrêmement simple et abordable d'utiliser un serveur DNS alternatif à celui fourni par son FAI, tout en continuant à centraliser la gestion des DNS internes sur la box ainsi que le DHCP.