GuiGui's show search

ACCUEIL MON SHAARLI SSL MENTIONS LÉGALES FLUX RSS

Archives :
Mettre en place un résolveur DNS sur un WRT54GL équipé
d’OpenWRT août 2010
Posté le 27 août 2010 à 20h24 par GuiGui L Ma Me J V S D
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
Table des matières 16 17 18 19 20 21 22
23 24 25 26 27 28 29
Table des matières
30 31
Pourquoi vouloir un résolveur DNS à la maison ? « juil oct »
Avec quel logiciel ?
Avant l'installation Catégories
Installation de dnscache
Administration réseau
Configuration de dnscache
Administration système
Test de la configuration

Changer l'adresse du résolveur DNS sur les machines grâce à DHCP et sur Blog

le routeur Cinéma/TV
Désactiver la fonctionnalité DNS de dnsmasq
Développement
Mettre en place durablement notre résolveur
Assembleur 8086+
Si dnscache plante lorsqu'une déconnexion survient sur l'interface WAN (ÉDIT du
open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 08/08/2011 à 14h00 ) Divers

Hardware
Pour suivre cet article, je vous conseille de connaitre les bases de l'administration sous OpenWRT
Embarqué
(GNU/Linux quoi) et les bases du DNS. Pour le Domain Name System, je vous recommande Wikipédia et
un cours vidéo sur lalitte.com. OpenWRT

Humeur
Pourquoi vouloir un résolveur DNS à la maison ?
Jeux vidéo
Il y a plusieurs raisons qui peuvent amener à mettre en place un résolveur DNS at home. Je vais vous
Logiciels
donner les miennes :

le "défi" technique.
éviter les DNS menteurs.
améliorer la réactivité de vos applications internet : les réponses étant mises en cache sur
un périphérique à l'intérieur du réseau local, les temps de réponses sont excellents lorsque
vous demandez plusieurs fois la même résolution (1 à 2 msec(s)).

Avec quel logiciel ?

Le facteur limitant sera ici la taille du logiciel : il doit loger dans l'espace libre (233 kb) qui reste sur mon
routeur (il faudra que je vois pour ajouter une carte MMC/SD). Faisons le tour des logiciels que je connais :

Bind : un standard de fait. Mais je voulais quelque chose de plus exotique. De plus, le
paquetage nécessite 1868kb pour être installé : il est donc trop gros pour mon WRT54GL.
MaraDNS : lui aussi est trop lourd : 612kb sont réclamés.
Dnsmasq : il est installé par défaut sur OpenWRT. Mais comme l'indique son man :
"Dnsmasq is a DNS query forwarder: it it not capable of recursively answering arbitrary
queries starting from the root servers but forwards such queries to a fully recursive upstream
DNS server which is typically provided by an ISP.". En clair : ça va pas être possible.
DjbDNS. Celui-là répond à tous les critères. Après son installation sur mon routeur, il reste
open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 encore 188kb d'espace libre.

Avant l'installation
Comme nous l'avons vu, le paquetage dnsmasq est installé par défaut sous OpenWRT. C'est un logiciel
multi-fonctions : DHCP, TFTP et "résolveur" DNS (enfin ... pas tout à fait puisqu'il se contente de transférer
les requêtes DNS vers un vrai résolveur DNS sur internet).

Rappel : il ne peut pas y avoir deux logiciels qui utilisent un même port sur une même interface réseau.

Il va donc falloir soit désinstaller dnsmasq et donc se priver d'un serveur DHCP, soit lui demander
d'abandonner uniquement sa fonction de "résolveur" DNS. Réponse 2, Jean-Pierre !

Nous allons donc installer dnscache, le configurer puis désactiver la fonctionnalité dns de dnsmasq.

Installation de dnscache
Rien de compliqué ici :

root@OpenWRT:~# opkg update

root@OpenWRT:~# opkg install djbdns-dnscache

Configuration de dnscache
Si vous lancez dnscache maintenant et que vous faisez un netstat -lep, vous verrez que dnscache écoute
sur le port 53 en UDP et TCP mais sur l'interface WAN. Or, ce que nous voulons, c'est un résolveur qui
écoute uniquement sur le réseau local. Il va donc falloir configurer dnscache.

C'est ici que j'ai pas mal galéré. En effet, si vous cherchez de la documentation sur internet, vous trouverez
qu'il faut créer des comptes utilisateur, ajouter ou modifier des fichiers dans /etc/dnscache. J'ai essayé :
ça ne fonctionne pas. J'ai donc décidé de lire le readme qui se trouve dans le paquetage. Il est disponible à

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 cette adresse : https://dev.openwrt.org/browser/packages/net/djbdns/README. Tout devient alors clair : il
faut utiliser uci pour configurer dnscache.

Allons-y pour la configuration :

root@OpenWRT:~# uci set djbdns.@dnscache[0].interface=lan

root@OpenWRT:~# uci set djbdns.@dnscache[0].defaultallowif=lan
root@OpenWRT:~# uci set djbdns.@dnscache[0].forwardonly=0
root@OpenWRT:~# uci set djbdns.@tinydns[0].interface=lan
root@OpenWRT:~# uci set djbdns.@axfrdns[0].interface=lan
root@OpenWRT:~# uci set djbdns.@rbldns[0].interface=lan
root@OpenWRT:~# uci set djbdns.@walldns[0].interface=lan

Commentons un peu ces lignes. Dans l'ordre :

on demande à dnscache d'écouter que sur le réseau local.

on demande à dnscache de ne répondre qu'à des périphériques membres du réseau local
on demande à dnscache de résoudre lui-même les noms de domaine en partant des
serveurs qui gèrent la racine.
on demande aux autres composants de djbdns d'écouter que sur sur le réseau local.
Même si nous ne les avons pas installés, cela est plus prudent : si vous souhaitez les
installer, vous pourrez les configurer tranquillement sans les exposer directement sur
internet. Il vaut mieux prévoir le coup plutôt que de s'en remettre à la bonne configuration du
firewall.

Note : pour voir l'intégralité des variables de configuration propres à djbns présentent dans le système, vous
pouvez taper :

root@OpenWRT:~# uci show | grep "djbdns"

Test de la configuration
Comme nous l'avons dit, on ne peut pas avoir deux logiciels qui écoutent sur le même port. Donc on arrête
open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 dnsmasq temporairement :

root@OpenWRT:~# /etc/init.d/dnsmasq stop

Lançons dnscache :

root@OpenWRT:~# /etc/init.d/dnscache start

Pour tester le serveur, il suffit de lui envoyer une requête. Sous GNU/Linux, je préfère utiliser dig alors que
sous Windows, nslookup fera l'affaire.

Sous GNU\Linux :

dig @192.168.1.1 www.guiguishow.info.

Vous devez obtenir une réponse dont le status est "NOERROR".

Sous Windows :

nslookup www.guiguishow.info. 192.168.1.1

Vous devez obtenir aucune erreur.

Note : 192.168.1.1 est à remplacer par l'adresse IP LAN de votre routeur.

Ensuite, vous pouvez vous demandez "comment être sûr que mon serveur ne se contente pas de transférer
ma requête à un autre DNS ?" Il y a manière simple de vérifier cela.

Il suffit de capturer le trafic réseau qui sort du routeur sur l'interface WAN (eth0.1).

Si vous avez encore assez d'espace libre dans la mémoire de votre routeur, vous pouvez installer tcpdump
(660kb) ou tcpdump-mini dessus. Il suffit alors de lancer le sniffer :

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 tcmpdump -n -i eth0.1 port 53

Sinon, vous pouvez brancher un autre ordinateur sur le port WAN du WRT54GL et capturer le trafic réseau
avec un logiciel comme Wireshark. Pour que cela fonctionne, l'ordinateur que vous avez branché au port
WAN doit prendre la même adresse IP que le modem qui est habituellement branché à votre routeur (ou
redéfinir la route pas défaut sur le routeur, mais c'est une autre histoire). Si vous ne la connaissais pas,
regardez la capture réseau : vous verrez des trames ARP "Who has x.x.x.x tell y.y.y.y". Il vous suffit de
donner à votre ordinateur l'adresse IP x.x.x.x . Vous pouvez ensuite lancer la capture.

Dans tous les cas, une fois cela fait, revenez sur l'ordinateur qui est toujours connecté sur un des ports
LAN du routeur. Lancez un dig/nslookup en direction de votre résolveur personnel. Dans la capture réseau,
vous devez voir des adresses IP qui appartiennent à l'un des serveurs qui gèrent la racine DNS ou les TLD
comme 192.26.92.30 ou 192.54.112.30.

Pour savoir si une adresse IP appartient à l'un des serveurs en charge de la racine ou des TLD, vous
pouvez utiliser la commande host sous GNU/Linux ou nslookup sous Windows. Dans le cas de
192.54.112.30, nous obtenons "30.112.54.192.in-addr.arpa domain name pointer h.gtld-servers.net.". Il
s'agit donc d'un des serveurs qui gère le domaine de premier niveau .net. .

Si tout va bien, vous pouvez passer à l'étape suivante.

Changer l'adresse du résolveur DNS sur les machines grâce à DHCP

et sur le routeur
Les Unixiens se seront précipités pour éditer le fichier /etc/resolv.conf . C'est un bon réflexe en temps
normal mais, dans le cas présent, ce fichier est généré à chaque démarrage du routeur, ou plus
précisément à chaque démarrage de dnsmasq.

Il faut donc éditer le script de démarrage : /etc/init.d/dnsmasq. A la 5éme ligne, vous pouvez lire :

DNS_SERVERS= ""

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 Saisissez ici l'adresse ip LAN de votre routeur.

Note : dnsmasq ajoutera le résolveur 127.0.0.1 automatiquement à la fin de la liste. Si vous trouvez ça
inconcevable, que ça vous empêche de dormir la nuit, supprimez la 5eme ligne du fichier puis cherchez
cette ligne dans la fonction start :

DNS_SERVERS= "$DNS_SERVERS 127.0.0.1"

Enlevez tout ce qu'il y a entre guillemets et mettez la ou les adresse(s) IP de votre(vos) résolveurs, séparés
par un espace.

Il ne reste plus qu'a redémarrer dnsmasq :

root@OpenWRT:~# /etc/init.d/dnsmasq restart

Notez que les modifications ne prendront effet sur vos périphériques que lors du renouvellement du bail
DHCP. Vous pouvez le forcer (ipconfig /renew sous windows, désactiver/activer l'interface réseau, reboot,
etc.).

Désactiver la fonctionnalité DNS de dnsmasq

A présent, nous pouvons désactiver la partie DNS de dnsmasq. Le man de dnsmasq nous dis ("Listen on
<port> instead of the standard DNS port (53). Setting this to zero completely disables DNS function,
leaving only DHCP and/or TFTP.") qu'il suffit de configurer le port à 0 pour désactiver la fonction DNS. Pour
mettre cela en application, il suffit d'aller dans l'interface web, dans "Services", "Dnsmasq", d'ajouter un
champ "port DNS", de le configurer à 0 et d'appliquer les changements.

Pour les True Warrior qui veulent le faire depuis le shell, ça donne :

root@OpenWRT:~# uci set dhcp.@dnsmasq[0].port=0

root@OpenWRT:~# /etc/init.d/dnsmasq restart

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 Mettre en place durablement notre résolveur
En effet, dans l'état actuel, djbdns ne se relancera pas au prochain reboot du routeur et les paramètres
seront perdus .

Pour que le serveur se lance tout seul au démarrage du routeur vous pouvez créer un lien de
/etc/init.d/dnscache vers /etc/rc.d/Sxxdnscache (ou xx représente l'ordre de boot) avec la commande ln ou
plus simplement taper la commande :

root@OpenWRT:~# /etc/init.d/dnscache enable

Pour enregistrer les paramètres que nous avons donnés à uci, il faut taper ceci dans ash (le shell par
défaut d'OpenWRT) :

root@OpenWRT:~# uci commit network.lan

root@OpenWRT:~# uci commit dhcp
root@OpenWRT:~# uci commit djbdns
root@OpenWRT:~# uci commit

Détaillons un peu, toujours dans l'ordre :

On enregistre le changement de serveur DNS pour le réseau local.

On enregistre le fait que dnsmasq ne doit plus faire office de résolveur DNS ainsi que le
changement de serveur DNS pour le réseau local, le cas échéant.
On enregistre toutes les modifications faites à djbdns.
On enregistre tout. Pas utile mais je le fais par mesure de précaution.

Et voila, votre résolveur DNS personnel est en place sur votre routeur équipé avec OpenWRT.

Si dnscache plante lorsqu'une déconnexion survient sur

l'interface WAN (ÉDIT du 08/08/2011 à 14h00 )

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 J'ai rédigé un billet à ce sujet : OpenWRT : relancer automatique dnscache en cas de déconnexion du net

Catégorie: Administration réseau, Administration système, OpenWRT / Tags: aucun tag / Ajouter un
commentaire

Aucun commentaire. Ajoutez votre commentaire

Votre commentaire

Nom* : Email* : URI :

Soumettre

Le contenu de ce blog est mis à disposition sous un contrat Creative Commons BY-SA 3.0 France. Exception faite des commentaires, des extraits de textes, médias et
marques qui restent la propriété de leurs auteurs respectifs. Toute copie de ce site doit mentionner http://www.guiguishow.info. Publié avec WordPress. Pyrmont V2

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com