Faut-il avoir son propre résolveur
DNS, sur
sa machine (ou, au moins, sur son réseau local à soi) ? Question
compliquée à laquelle je réponds désormais
oui,
en raison de l'intensification de la censure utilisant le DNS.
D'abord, un petit rappel : la quasi-totalité des activités sur
l'
Internet commencent par une requête
DNS, une demande faite au
résolveur DNS par les applications « quelle est
l'
adresse IP de
www.slate.fr ? » Le résolveur, après
interrogation des
serveurs DNS faisant autorité
(gérés, dans le cas de ce nom de domaine, par la racine, par l'
AFNIC
et par
Slate), va répondre aux applications et
le reste de l'activité Internet pourra continuer. Comme tout commence
par le DNS, ce service est particulièrement tentant pour tous ceux qui
veulent censurer / dévier / détourner les activités de
l'utilisateur. Il y a donc une histoire déjà ancienne de tentatives de
filtrage via le DNS et une histoire
tout aussi ancienne de
textes
expliquant pourquoi c'est une très mauvaise idée. Le filtrage
via le DNS peut se faire dans le réseau,
comme en Chine. Mais le plus
courant est de le faire dans le résolveur. Cette machine est
typiquement gérée,
pour un accès Internet par un particulier, par son
FAI. En raison de la concentration du marché,
en contraignant les quatre ou cinq plus gros FAI à effectuer ce
filtrage, on pourrait frapper un bon nombre des
MM. Michu. Techniquement; c'est simple à faire, avec des systèmes
comme RPZ. Et cette voie
a déjà été suivie, en France
par l'ARJEL.
Une solution évidente à ce filtrage est d'avoir son propre
résolveur DNS, de ne plus compter sur celui du FAI. Cette solution a
deux défauts, le premier est temporaire : sa mise en œuvre est encore
trop complexe, comme
déjà expliqué
dans un de mes articles. La deuxième est moins visible : si
chaque utilisateur de l'Internet a son propre résolveur DNS, ils ne
partageront plus leur mémoire (leur « cache ») et la charge sur les
serveurs faisant autorité s'aggravera. Pour cette raison, je prônais
plutôt des systèmes comme
dnssec-trigger qui installaient un
résolveur local mais faisaient suivre les requêtes non résolues aux
résolveurs (et donc aux caches) des FAI. C'est une solution simple et
élégante (et qui permettait aussi de faire de la
validation DNSSEC proprement).
Mais dnssec-trigger a une limite. Certes, avant d'utiliser les
résolveurs du réseau local comme relais, il les teste pour s'assurer
qu'ils transmettent les données DNSSEC correctement. Mais il ne teste
pas s'ils
mentent ou pas. Si le
résolveur officiel du réseau local applique la censure, dnssec-trigger
ne pourra plus accéder aux données (si DNSSEC est utilisé, on aura un
code d'erreur,
SERVFAIL, plutôt qu'une réponse
mensongère comme l'adresse IP 127.0.0.1 dans l'exemple ci-dessous,
mais cela ne change pas grand'chose ; DNSSEC protège contre le
détournement, pas contre le déni de service qu'est la censure).
Or, l'usage du DNS pour la censure se répand. Ainsi, le 28 novembre
2013, un tribunal français a ordonné
la
censure par le DNS de sites Web de diffusion de films. Et cette
censure semble effectivement appliquée. En testant depuis un très gros
FAI français, avec
dig :
% dig +short @192.168.2.254 A alloshare.com
127.0.0.1
Or, cette adresse IP bidon (127.0.0.1 désigne la machine locale, donc
ce mensonge renvoie votre navigateur Web vers votre machine) n'est pas
la vraie. Avec mon résolveur personnel :
% dig +short A alloshare.com
204.236.239.5
Cela
vous semble exagéré de parler de censure, pour une affaire
essentiellement commerciale (les intérêts des ayant-trop-de-droits) ?
Sauf que cela
commence
comme ça puis, une fois que l'outil est au point, on pourra de
la même façon demander la censure de n'importe quel nom qui déplait
aux autorités. Il est donc normal que les citoyens se détournent des
résolveurs DNS menteurs et veuillent configurer leur propre résolveur.
Donc, d'abord, pour les systèmes que je connais le mieux, les
Unix. Il faut 1) installer le logiciel
résolveur 2) configurer la machine pour l'utiliser et surtout 3) faire
en sorte que
DHCP ne vienne pas écraser ce
réglage. Pour le logiciel résolveur, on a plusieurs choix, notamment
BIND et
Unbound,
disponibles sous forme de
paquetage dans
n'importe quel Unix. Un
exemple de configuration BIND pour un résolveur, validant avec DNSSEC
pendant qu'on y est :
options {
// N'écouter que sur l'interface locale. Autrement, faites
// attention à interdire l'accès aux machines non-locales, pour
// ne pas faire un résolveur ouvert.
listen-on {127.0.0.1;};
dnssec-enable yes;
dnssec-validation yes;
};
trusted-keys {
"." LA CLÉ DNSSEC DE LA RACINE EST EN GÉNÉRAL DISTRIBUÉE AVEC BIND (fichier bind.keys)
};
Et pour Unbound :
server:
interface: 127.0.0.1
auto-trust-anchor-file: "/var/lib/unbound/root.key"
Pour récupérer de manière sûre la clé de la racine avec Unbound, le
plus simple est un
unbound-anchor -a "/var/lib/unbound/root.key".
Une fois le résolveur démarré, testez avec dig qu'il peut résoudre les
noms :
% dig @127.0.0.1 A www.techn0polis.net
...
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
www.techn0polis.net. 2917 IN CNAME gpaas6.dc0.gandi.net.
gpaas6.dc0.gandi.net. 1156 IN A 217.70.180.136
...
;; SERVER: 127.0.0.1#53(127.0.0.1)
...
Testez aussi depuis des machines extérieures que votre résolveur ne
répond
pas aux machines extérieures. Autrement,
c'est un
résolveur
ouvert, ce qui est très dangereux. Si vous voulez rendre
accessible votre joli résolveur depuis tout votre réseau local, vous
devez également écouter sur les adresses IP du réseau local (et bien
utiiser le contrôle d'accès de votre serveur -
acl dans BIND et
access-control: dans
Unbound - pour ne pas devenir un
résolveur ouvert).
Une fois que c'est fait, configurez votre machine pour interroger
le serveur/résolveur en question. Mais attention, le problème est que
DHCP vient souvent dans votre dos changer ce
réglage. Donc, simplement éditer
/etc/resolv.conf, comme on le lit parfois sur des
forums de neuneus, n'est pas suffisant. Il faut modifier la
configuration du client DHCP. Cela dépend du client mais, par exemple,
sur une
Debian, éditer
/etc/resolvconf/resolv.conf.d/head pour y
mettre :
nameserver 127.0.0.1
suffit. Une fois que c'est fait, vous pouvez tester avec dig sans
indiquer
@127.0.0.1 et la ligne
SERVER dans la sortie doit vous indiquer quel
serveur vous utilisez.
Pour
Mac OS X, je n'ai pas d'expérience de
ce système mais je suggère l'
article de
hukl. Experts OS X, si vous avez d'autres idées ?
Et pour
Windows ?
Apparemment, Unbound tourne sur Windows (si quelqu'un a une expérience
d'utilisation à raconter...) Je ne connais pas assez Windows pour le reste
mais je vous suggère une solution pour la partie « configurer sa
machine pour accéder au résolveur local ». Un certain nombre de services
commerciaux vous fournissent des résolveurs alternatifs, pour accéder
plus rapidement à
certains services
bridés comme YouTube. Je ne vous dis pas d'utiliser ces
résolveurs, qui sont aussi menteurs (même si c'est pour la bonne
cause) mais tous viennent avec une documentation, conçue pour un large
public, indiquant comment changer de résolveur. Par exemple, c'est le
cas de la
documentation de
Unlocator.
Quelle sera la prochaine étape de la course aux armements entre les
censeurs et les utilisateurs de l'Internet ? Peut-être d'essayer de
faire
filtrer le port 53. En
attendant, voici d'autres documents sur le thème de cet article :
agrandir la photo