Gazette Linux n°130 — Septembre 2006
Copyright © 2006 Ed Neville
Copyright © 2006 Deny
Copyright © 2006 Joëlle Cornavin
Article paru dans le n°130 de la Gazette Linux de septembre 2006.
Article publié sous Open Publication License. La Linux Gazette n'est ni produite, ni sponsorisée, ni avalisée par notre hébergeur principal, SSC, Inc.
Table des matières
- 1. Introduction
- 2. Obtention des éléments requis
- 3. Installation de ces éléments
- 4. Configuration du cache DNS
- 5. Configuration du serveur DNS
- 6.
data.cdb - 7. Démarrage des services
- 8. Journalisation
- 9. Test
- 10. Empoisonnement de DNS
- 11. Paramétrage du serveur « forgé »
- 12. Installation supplémentaire
- 13. Performances
Ce guide montre comment configurer djbdns pour un environnement SOHO (Small Office Home Office).
Named/BIND (Berkeley Internet Name Daemon) est un serveur DNS (Domain Name System, système de noms de domaine) prisé, mais peut-être a-t-il rencontré quelques problèmes généraux.
Avec une installation par défaut de named, vous vous mettez en position de proxy ouvert, en permettant à quiconque sur l'Internet d'effectuer des requêtes DNS à travers votre système, qui est un serveur de noms cache sur toutes les interfaces[1]. J'ai découvert plus tard que la suite d'outils DNS de DJB (c'est-à-dire D.J. Bernstein) était très efficace et facile à utiliser.
En dépit de ses mérites, il y a un inconvénient majeur : vous ne pouvez lancer un serveur DNS et un cache DNS dans la même instance sur la même interface. D'aucuns pourraient en concevoir à la fois confusion et irritation ; je le vois comme une sécurité. J'exécute une installation SOHO typique : j'ai une poignée de noms de domaine et une poignée d'ordinateurs sur le réseau local. Voici comment j'administre l'ensemble, ce sera la base de cet article.
Pour illustrer la disposition du réseau :
Dans cet exemple, vous devez décider si vous placez votre serveur DNS dans votre réseau local ou si vous le mettez au niveau du pare-feu. Comme les recherches de DNS (devraient) créer peu de charge sur votre réseau, il n'est pas nécessaire d'installer une machine dédiée. Si vous décidez cependant de le faire, il restera probablement inactif la majeure partie du temps, auquel cas vous pourriez être amené à l'utiliser également comme serveur de sauvegarde ; par conséquent, vous ne devriez pas manquer d'espace disque, ici.
Dans mon exemple, le nuage Internet est relié à une adresse IP 35.45.55.65 et les clients du réseau local sont sur un réseau 192.168.0.0-255 (autrement connu sous le nom de réseau privé 192.168.0.0/24 RFC 1918).
L'objectif ici est d'installer tinydns pour prendre en charge nos recherches de DNS en UDP, dnscache pour affecter au réseau local un cache pour des recherches de DNS et un serveur tinydns privé pour répondre avec NXDOMAIN[2] à des recherches dont un trafic Internet potentiellement dangereux pourrait résulter.
Un des obstacles immédiats pour quiconque n'a pas effectué d'installations de sources est que la suite entière de programmes que fournit DJB est en code source. Le code est très bien écrit et compile parfaitement sur la plupart des systèmes, mais sa licence ne permet pas de redistribuer son logiciel si modifié. C'est pourquoi la plupart des distributions ne peuvent pas fournir de paquetages exécutables.
Il y a trois étapes principales pour obtenir et installer les paquetages DNS de DJB :
http://cr.yp.to/daemontools/daemontools-0.76.tar.gz fournit une suite de programmes destinés à gérer des services système. La majeure partie de la suite se compose de programmes superviseurs, qui consistent en un « super » service et des utilitaires de surveillance. C'est ce qui maintiendra les services DNS en fonctionnement : même dans le cas d'un « plantage » du programme, le « super » service redémarrera les services à notre place.
ucspi fournit les programmes serveur et client TCP qui permettent aux appelants de faire dialoguer TCP par le biais de lectures/écritures similaires à stdin/stdout (entrée standard/sortie standard). Cette méthode supprime un risque élevé de sécurité contre lequel les appelants devraient autrement se prémunir (comme certains dépassements simples de tampon).
http://cr.yp.to/djbdns/djbdns-1.05.tar.gz est la suite de programmes et bibliothèques DNS qui fournit aux requêtes les informations DNS.
Nous placerons daemontools dans le répertoire /package , le répertoire du super-service sera dans /service, les outils ucspi seront placés dans /usr/local et les programmes DNS seront configurés dans /etc.
Les emplacements des deux répertoires suggérés ci-dessus, | ||
| -- Ben | ||
En suivant les orientations de base d'installation des pages de DJB :
mkdir -p /package
chmod 1755 /package
cd /package
wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
tar zxpf daemontools-0.76.tar.gz
cd admin/daemontools-0.76
La compilation et l'installation sont effectuées à l'aide d'une seule commande, package/install.
Nous devrions à présent pouvoir exécuter la commande supervise depuis/etc/inittab ; si ce n'est pas le cas, lancez svscan & manuellement.
Comme pour daemon-tools, nous suivrons les notes d'installation de DJB :
cd ~
wget http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz
tar zxpf ucspi-tcp-0.88.tar.gz
cd ucspi-tcp-0.88
Compilez les programmes ucspi-tcp en saisissant make. En tant que root, installez les programmes ucspi-tcp dans /usr/local avec make setup check.
cd ~
wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz
tar zxpf djbdns-1.05.tar.gz
cd djbdns-1.05
echo gcc -O2 -include /usr/include/errno.h > conf-cc
make
Il y a un léger bogue pendant la compilation, suite à quelques changements récents de glibc ; par conséquent, la cinquième ligne dans le bloc de commandes ci-dessus remplace les options de compilation originales. Une fois que tout est complet, nous pouvons poursuivre la configuration du système.
Comme nous devons créer un nouveau compte utilisateur pour dnscache, ce dernier peut fonctionner sous cet utilisateur, puisque l'exécution de services en tant que root favorise une multitude de problèmes de sécurité. Le même raisonnement s'applique pour la mise en place des groupes.
groupadd dnscache
groupadd dnslog
useradd -g dnscache dnscache
useradd -g dnslog dnslog
À présent, installons le répertoire de cache :
dnscache-conf dnscache dnslog /etc/dnscache
Choisissez une IP que le cache DNS devra écouter et écrivez-la dans /etc/dnscache/env/IP. Dans mon cas, comme je possède l'adresse IP privée 192.168.0.1 sur l'interface de réseau local de mon pare-feu, je place cette adresse IP ici :
echo 192.168.0.1 > /etc/dnscache/env/IP
Ensuite, nous ajouterons un paramètre pour indiquer à dnscache quelles adresses IP source prendre en charge ; pour ce faire, exécutons un touch sur les plages d'IP dans /etc/dnscache/env/IP :
touch /etc/dnscache/root/ip/192.168.0
La prochaine étape consisterait à lier ce répertoire au répertoire du super-service, ce que nous ferons dans un instant.
Le serveur DNS et le cache DNS ne peuvent pas opérer sur la même interface en utilisant le même protocole. BIND peut le faire ; cependant, ce n'est pas un comportement par défaut souhaitable. BIND a longtemps souffert d'être employé par des personnes qui ont transféré le travail de consultation sur des démons tiers.
Dans mon exemple ci-dessus, tinydns est paramétré pour opérer sur 35.45.55.65, prenant en charge le contenu de mon fichier de données DNS uniquement. Si la réponse que souhaite le client n'est pas dans le fichier de données, alors la consultation échoue.
groupadd tinydns
useradd -g tinydns tinydns
tinydns-conf tinydns dnslog /etc/tinydns 35.45.55.65
Nous devrions à présent avoir un répertoire tinydns dans /etc/tinydns. Assurons-nous qu'il est paramétré pour écouter sur l'adresse IP correcte en examinant le contenu de /etc/tinydns/env/IP, où devrait figurer votre adresse IP souhaitée de prise en charge de DNS. Dans mon cas, il s'agit de 35.45.55.65.
tinydns emploie un fichier de hachage de consultation de base de données, ce qui rend les consultations de requêtes extrêmement rapides et efficaces. Le fichier de hachage est stocké au format CDB (Constant DataBase). Ce fichier peut être transporté dans n'importe quelle architecture et restera compatible, ce qui rend les grappes de serveurs (clusters) DNS très faciles à maintenir.
Le répertoire /etc/tinydns/root/ contient un fichier de données et un Makefile et, lorsqu'on exécute ce dernier, le fichier data.cdb est créé. Les zones DNS contiennent (entre autres), A(+), MX(@), NS(&), Zones(Z) et Cnames(C).
Prenons un exemple des plus simples, l'enregistrement de type A :
+exemple.com:35.45.55.65:86400
Ci-dessus, nous avons positionné l'enregistrement de type A de l'hôte exemple.com sur l'adresse IP 35.45.55.65 avec un TTL (Time to live, durée de vie) d'un jour, en secondes.
Les enregistrements de type CNAME sont similaires ; ce sont des pointeurs sur un enregistrement d'adresse. Le problème avec les enregistrements d'adresses est que, quand l'adresse IP change, souvent l'administrateur DNS doit reconfigurer beaucoup d'enregistrements d'adresses, souvent en même temps que l'adresse IP est modifiée. Les enregistrements CNAME sont une façon de référencer les enregistrements A. Le seul problème avec un CNAME est qu'il provoque deux consultations plutôt qu'une seule, ce qui vous affecte évidemment si votre bande passante et votre temps sont réduits[3] :
Cwww.exemple.com:exemple.com.:60
La ligne ci-dessus indique que le nom d'hôte www.exemple.com pointe sur exemple.com avec un TTL d'une minute. Veuillez noter le . final placé à la fin de l'hôte cible.
Les enregistrements MX diffèrent légèrement des enregistrements CNAME car ils doivent généralement contenir les préférences de messagerie.
@exemple.com::mail.exemple.com.:10:86400
Ici nous voyons que l'enregistrement MX, par exemple, pointe sur l'enregistrement A d'exemple.com avec une préférence de 10. Notez le . final après l'adresse cible. Notez en outre qu'il est souvent peu judicieux de spécifier un enregistrement CNAME comme messagerie cible. Placer un enregistrement CNAME ici ne vous apportera rien d'autre que d'avoir trois consultations plutôt que deux chaque fois qu'une consultation MX est effectuée[4].
Lorsque vous organisez des DNS pour votre domaine, il est important que les enregistrements de serveur de noms (NS, Name Server) du serveur DNS de votre domaine correspondent à la liste des NS de la racine.
@exemple.com::ns0.exemple.com.:86400
Ci-dessus, nous indiquons que le NS pour exemple.com est l'enregistrement d'adresse ns0.exemple.com. Notez le . final !
L'enregistrement de zones contient également des informations autres que des enregistrements ; principalement, il fournit des détails de mise à jour de la zone. Ici, on doit indiquer le SOA (start of authority, serveur ayant autorité). Comme dans la plupart des cas, il s'agit de votre serveur de noms primaire, les serveurs de noms secondaires savent où trouver les informations mises à jour.
Zexemple.com:ns0.exemple.com.:hote-maitre.exemple.com.:2005090312:7200:7200:2419200:604800
La ligne ci-dessus établit que le nom de zone est exemple.com, avec le serveur de noms primaire de ns0.. L'adresse de courrier du responsable de domaine est exemple.comhote-maitre@exemple.com. Le premier . est supposé être un @.
Nous utilisons la date au format YYYYMMDDHH comme numéro de série pour la zone[5]. Ces valeurs sont indiquées en secondes et sont (dans l'ordre, de gauche à droite) :
refresh
retry
expire
minimum refresh
Nous disposons à présent d'une configuration de base. La disposition complète de la zone est la suivante :
Zexemple.com:ns0.exemple.com.:hote-maitre.exemple.com.:2005090312:7200:7200:2419200:604800
@exemple.com::ns0.exemple.com.:86400
@exemple.com::mail.exemple.com.:10:86400
Cwww.exemple.com:exemple.com.:60
+exemple.com:35.45.55.65:86400
+mail.exemple.com:35.45.55.65:86400
+ns0.exemple.com:35.45.55.65:86400
Une fois que vous avez écrit votre fichier de zone, vous devrez exécuter le programme make pour ajouter cette configuration dans le fichier data.cdb, comme noté ci-dessus.
Pour obtenir une documentation complète sur le format du fichier de données, visitez le site http://cr.yp.to/djbdns/tinydns-data.html.
Dès l'instant où la configuration vous convient, vous pouvez démarrer les services en les liant tous les deux au répertoire /service. Pour ce faire, exécutez simplement les deux commandes suivantes :
ln -s /etc/tinydns /service
ln -s /etc/dnscache /service
Attendez quelques secondes puis saisissez ps -aux ; vous devriez voir une sortie similaire à celle-ci :
root 2241 0.0 0.0 1276 256 ? S Jul27 0:00 supervise dnscache
root 2250 0.0 0.0 1276 256 ? S Jul27 0:00 supervise tinydns
dnscache 2252 0.0 0.1 2860 1588 ? S Jul27 7:02 /usr/local/bin/dnscache
dnslog 2254 0.0 0.1 1416 328 ? S Jul27 0:42 multilog t ./main
tinydns 2265 0.0 0.0 1532 320 ? S Jul27 0:31 /usr/local/bin/tinydns
dnslog 2272 0.0 0.0 1416 328 ? S Jul27 0:10 multilog t ./main
Si vous ne voyez pas ce qui précède, alors il se peut que votre programme supervise ne tourne pas. Vous devrez vous assurer que votre fichier /etc/inittab contient cette ligne :
SV:123456:respawn:/services/svscanboot
Envoyez alors à init un signal HUP :
kill -HUP 1
Vérifiez ensuite que supervise démarre réellement. Dans la négative, il y aura un message à propos de l'échec du processus readproctile dans la sortie de votre ps.
Il est à présent important de vérifier l'état des processus en cours d'exécution ; nous pouvons le faire grâce à la sortie de multilog, qui se trouve dans /etc/tinydns/log/main/current et /etc/dnscache/log/main/current.
La meilleure façon d'étudier ces fichiers est d'utiliser la commande suivante (depuis le répertoire log) :
tail -F current
Comme ces fichiers peuvent être fréquemment modifiés, employer le paramètre -F permettra au programme tail de surveiller les modifications des fichiers et de repositionner le pointeur de fichier au début du fichier lors de la rotation des journaux.
Nous devrions voir la sortie suivante (pour tinydns) :
@4000000044e38ce704a37e0c starting tinydns
et celle-ci pour dnscache :
@4000000044e38d0f165dc2ec starting
Si vous voyez des erreurs, alors vous pourriez devoir passer par les instructions d'installation ci-dessus, en vérifiant que tout a été suivi correctement. Si vous voyez une sortie, alors c'est encore mieux, puisque cela signifie que vos programmes fonctionnent (on l'espère) comme prévu.
Pour vérifier que le cache DNS fonctionne correctement, vous pouvez saisir les instructions suivantes :
nslookup – 192.168.0.1
set q=mx
yahoo.com
La ligne set q=mx indique à nslookup d'effectuer des requêtes MX, lesquelles retourneront les serveurs de messagerie de Yahoo© :
yahoo.com mail exchanger = 1 mx2.mail.yahoo.com.
yahoo.com mail exchanger = 1 mx3.mail.yahoo.com.
yahoo.com mail exchanger = 5 mx4.mail.yahoo.com.
yahoo.com mail exchanger = 1 mx1.mail.yahoo.com.
Pour vérifier que le serveur DNS fonctionne correctement, nous pouvons saisir les instructions suivantes :
nslookup – 35.45.55.65
set q=mx
exemple.com
Il existe d'autres outils que vous pourriez utiliser pour le débogage de DNS, nommés host et dig : ils sont très puissants et très amusants à programmer[6]. S'il s'avère que vous savez programmer en Perl, vous pourriez obtenir le module Perl Net::DNS, qui fournit une quantité de fonctions de consultations de DNS.
L'empoisonnement de DNS est la méthode par laquelle on corrompt des résultats pour convenir à la requête. Par exemple, si vous deviez découvrir un site Internet problématique, vous pourriez empêcher des consultations de ce site en indiquant au cache DNS d'employer un serveur DNS donné pour toutes ces requêtes. Le serveur DNS dans ce cas serait paramétré pour répondre avec NXDOMAIN pour chaque consultation ; de ce fait, nous pouvons envoyer ici n'importe quelle requête à notre gré et nous savons qu'elle va toujours donner le même résultat, NXDOMAIN. C'est le résultat idéal, car la consultation n'attend pas de délai imparti.
Dans le répertoire /etc/dnscache/root/servers/, vous pouvez placer l'adresse IP du serveur empoisonné dans le fichier correspondant au nom de domaine que vous souhaitez empoisonner. Par exemple, dans /etc/dnscache/root/servers/doubleclick.net, j'ai 127.0.0.7.
Nous allons répéter l'installation ci-dessus pour le serveur tinydns, mais à l'exception minime du fichier de données et de l'emplacement de son installation :
tinydns-conf tinydns dnslog /etc/tinyforge
cd /etc/tinyforge/root
echo '.:' > data
Cette ligne dans le fichier de données affecte toutes les consultations :
make
echo '127.0.0.7' > /etc/tinyforge/env/IP
La ligne ci-dessus indique à tinyforge quelle l'adresse IP écouter.
Nous devons installer une interface locale pour que tinyforge s'y connecte :
ifconfig lo:1 127.0.0.7
(Vous devrez ajouter la ligne suivante à la configuration de votre système) :
ln -s /etc/tinyforge /service
Et à présent, nous démarrons le service en le liant au répertoire /service ; vous pourriez être amené à répéter le test ci-dessus, pour vérifier que les consultations renvoient correctement NXDOMAIN.
Quand vous exécutez svc -h /service/dnscache, le répertoire des serveurs est rechargé et les domaines indiqués redirigés vers le serveur DNS « forgé ».
Il existe un projet sur http://www.bleedingsnort.com/blackhole-dns/files/ où une liste de sites inappropriés est maintenue. On peut facilement le placer dans un script, dans un répertoire de serveurs DNS. Ce script n'est pas inclus ici, car la disposition du fichier est sujette à modification.
Si vous êtes comme moi, vous souhaiterez des statistiques sur les domaines les plus fréquemment recherchés sur votre serveur tinydns : vous pouvez obtenir ces informations très facilement dans /etc/tinydns/log/main/. Je suggère de le consulter périodiquement à l'aide d'un script Perl et de répercuter les informations dans une base de données MySQL normalisée.
Il y a de nombreux avantages à avoir tous les paramètres DNS dans un seul fichier. Dans mon cas, ce fichier unique est généré depuis une base de données, que je ne détaillerai pas ici, mais cela permet aux amis ou aux clients d'effectuer des modifications via une interface web.
Avec BIND, les zones sont stockées dans des fichiers uniques. Si vous deviez avoir un grand nombre de fichiers dans un seul répertoire, il faudrait que le système d'exploitation ouvre le répertoire lors au moment du rechargement pour procéder au traitement. L'opération pourrait prendre du temps si vous avez un grand nombre de fichiers de zones[7].
Cela pourrait sembler insignifiant, peut-être, mais si votre activité consiste à fournir des DNS, vous pourriez être amené à programmer vos rechargements plutôt qu'autoriser des clients à mettre en file d'attente leur processus de rechargement.
Le fichier de hachage de données unique est très efficace. Pendant l'exécution de make, le fichier de données est nommé data.cdb.tmp jusqu'à ce que la compilation soit complète, puis il est renommé en data.cdb. Ce comportement permet la création d'un fichier de données sans interrompre le fonctionnement du serveur tinydns.
Né en 1980 à Reading, Royaume-Uni, diplômé de l'université de Reading avec un Bachelor of science honours d'informatique dans le domaine des Technologies Internet, mes langages de programmation favoris sont Perl, C, PHP, Java. M'étant intéressé à
Linuxvers 1997, je travaille professionnellement sousLinuxdepuis 2001 avec Debian, souvent comme responsable de la conception de réseaux d'entreprise.À ses moments perdus, Ed aime faire de la gymnastique, apprendre le russe, aider les utilisateurs sur de multiples listes de diffusion consacrées à
Linuxet à la programmation et faire de la recherche sur le noyauLinux. Ed préfère vivre sainement.
Adaptation française de la Gazette Linux
L'adaptation française de ce document a été réalisée dans le cadre du Projet de traduction de la Gazette Linux.
Vous pourrez lire d'autres articles traduits et en apprendre plus sur ce projet en visitant notre site : http://wiki.traduc.org/Gazette_Linux.
Si vous souhaitez apporter votre contribution, n'hésitez pas à nous rejoindre, nous serons heureux de vous accueillir.
[1] Rick Moen ajoute : c'est un sujet intéressant et bien mené. Si vous utilisez BIND9, le document Secure BIND Template de Rob Thomas est un point de départ bien meilleur que la configuration normale de BIND9 et, parmi beaucoup d'autres améliorations, fait appel à un système de partitionnement visuel pour limiter les accès DNS récursifs à des IP de réseaux plus sécurisés spécifiées, uniquement.
[2] RM : la valeur de retour de cette chaîne DNS est une abréviation de no such domain.
[3] RM : il y a un autre problème très sérieux avec les enregistrements CNAME. On ne peut pas s'en servir pour définir un nom d'hôte qui est également utilisé pour un enregistrement NS, MX ou tout autre enregistrement DNS (reportez-vous aux RFC1912 2.4 et RFC2181 10.3).
Les nouveaux administrateurs DNS abusent presque toujours largement des enregistrements CNAME : la raison semble être un manque de connaissance des taux de performances provenant de cette seconde consultation ainsi que des restrictions de la RFC, à quoi s'ajoutent des incertitudes quant à savoir si des enregistrements A multiples pointant sur une seule IP sont valides. Ce dernier est presque toujours, en fait, la bonne solution, sauf quand il pointe sur un FQDN (Fully Qualified Domain Name, nom de domaine pleinement qualifié en dehors du domaine. Oui, il est plus rapide de faire re-pointer les enregistrements CNAME quand/si les adresses IP changent, mais c'est l'objectif des fonctions de recherche et de remplacement.
[4] RM : en raison d'une même interdiction de la RFC, le courrier sortant de votre domaine peut également être refusé.
[5] RM : si vous travaillez sur des fichiers de zone avec d'autres administrateurs système, vous constaterez que les S/N de la forme YYYYMMDDnn (où nn commence à « 00 ») prédominent et sont presque une norme industrielle — autorisant comme actuellement 99 modifications de fichiers de zones par jour. Quoi qu'il arrive, ne vous mettez jamais dans une situation où vous seriez amené à changer pour un S/N numériquement inférieur, car une tâche fastidieuse vous attend si jamais il est nécessaire de propager un tel changement aux serveurs secondaires qui, normalement, n'agissent que sur les duplications de S/N.
[6] RM : en fait, l'utilisation du vénérable, pour ne pas dire quelque peu désuet, outil nslookup est à présent déconseillée au profit de dig et de host. Il y a un certain nombre de raisons à cela, qui sont abondamment (si ce n'est avec une certaine joie sardonique) cataloguées ici avec intelligence par le fabuleux Jonathan de Boyne Pollard de djbdns ici : http://homepages.tesco.net/J.deBoynePollard/FGA/nslookup-flaws.html. Heureusement, dig et host sont vraiment de bons outils et vous serez heureux (par la suite) de vous affranchir de l'usage de nslookup.
[7] RM : quiconque employant BIND9 en tant que serveur de noms primaire sur 5 000 zones utiliserait effectivement probablement la variante BIND DLZ (BIND Dynamically Loadable Zones, chargement dynamique de zones), http://bind-dlz.sourceforge.net/ ou le correctif LDAP sdb, (http://www.venaas.no/ldap/bind-sdb/) plutôt que BIND9, l'un et l'autre adossant BIND9 dans une base de données SQL au lieu de son stockage par défaut dans un fichier plat. Cependant, de gros sites pourraient préférer des paquetages de serveurs de noms spécialisés et plus performants tels que NSD (http://www.nlnetlabs.nl/nsd/), MyDNS (http://mydns.bboy.net/) ou PowerDNS (http://www.powerdns.com/products/powerdns/) — tous également open source.
J'ai catalogué tous les choix connus pour Linux dans ma base de connaissances à la rubrique « DNS Servers » sur http://linuxmafia.com/kb/Network_Other/.