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.1Or, 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.5Cela 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.
La situation technique n'est pas aujourd'hui tellement meilleure
qu'à l'époque de mon précédent article sur
le changement de résolveur. Mais le problème devenant plus
crucial, il faut quand même se lancer.
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.1suffit. 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 :
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette
page est distribuée sous les termes de la licence GFDL)
