Bind est un logiciel complexe qui demande une connaissance minimale du fonctionnement du système DNS. Si la correspondance IP ‹-> Nom de domaine ‹-> URL ne vous dit rien du tout, il est inutile de poursuivre (mais c'est peu probable sinon vous ne seriez pas ici). Pour ce tutoriel, nous travaillerons avec bind 9.2.1, mais bind 8 n'est pas très différent (il utilise ndc à la place de rndc par exemple) et est encore très présent.

Ce document est incomplet et sans doute inexact sur certains points. Toutefois, ayant utilisé de la documentation provenant de plusieurs sources différentes , j'ai été surpris du peu d'informations simples et précises disponibles. Plusieurs questions immédiates (et basiques) sont restées sans réponse. A force d'expérimenter, j'ai fini par trouver une procédure qui fonctionne.

Nous voyons ici la configuration de Bind 9 depuis les sources. Il existe des packages RPM ou DEB par exemple qui peuvent simplifier considérablement le travail. Si vous souhaitez installer un DNS rapidement sans vous casser la tête, je vous recommande le très beau travail de Christian Caleca qui fait des merveilles sur son increvable Mandrake.

En revanche, si vous souhaitez jouer en mode "Nightmare", restez ici :-)

1. Sommaire

2. Installation

L'installation de Bind 9.x causera probablement peu de soucis... Récupérez les sources disponibles sur le site isc.org. Il suffit ensuite de décompresser le .tar.gz. Jetez un oeil au README qui donne les détails des nouveautés. La procédure d'installation se résume à ./configure, make et make install

Nous pouvons tout de même passer quelques options dans le ./configure, par exemple "--disable-ipv6" (à moins que vous soyez en IPv6, inutile de charger le programme pour rien...)

C'est après le make et le make install que les problèmes vont commencer ...

Haut

3. Premières questions

Où sont les fichiers de configuration ?

Nulle part si ce n'est les fichiers exemples inclus dans les sources ! Avec une installation standard (c'est à dire sans toucher aux options du ./configure), vous devrez créer:

  • /etc/named.conf
  • /etc/rndc.conf

Vous devrez aussi créer le répertoire /var/named dans lequel iront se loger les fichiers de zone.

Quels sont les exécutables ?

/usr/local/sbin/named
c'est le démon
/usr/local/sbin/named-checkconf
Utilitaire de contrôle de la syntaxe du fichier de configuration
/usr/local/sbin/named-checkzone
Utilitaire de contrôle de la syntaxe des fichiers de zone
/usr/local/sbin/rndc
Utilitaire de contrôle du démon (stopper, redémarrer etc. named)
/usr/local/sbin/rndc-confgen
Utilitaire permettant de générer le rndc.conf

Haut

4. Comment ca marche

Voici en gros ce que j'ai compris: l'usine à g..., heu le serveur DNS fonctionne ainsi:

Au démarrage de la machine, named est lançé et écoute les requêtes sur le port 53.

Il répondra aux requêtes de trois manières différentes:

  • Soit il a un fichier de zone pour le domaine sur lequel porte la question auquel cas il va chercher l'information dedans
  • Soit il interroge lui-même les serveurs DNS primaires (dont la liste se trouve dans /var/named une fois que vous l'y aurez mis)
  • Soit il forward la requête à des serveurs de votre choix indiqués dans le /var/named.conf

Vous pourrez contrôler le démon named au moyen de rndc. Ce dernier utilise une clé cryptée dans son /etc/rndc.conf qu'il comparera à la clé cryptée figurant dans /etc/named.conf (nous verrons plus loin comment la générer).

Haut

5. Créer le rndc.conf

Par défaut, il se trouve dans /etc (enfin non: par défaut vous allez le mettre dans /etc). En fait, pour créer ce fichier, on peut faire appel à l'utilitaire /usr/local/sbin/rndc-confgen. Ce dernier va afficher à l'écran une configuration toute prête.

oxygene:/etc# /usr/local/sbin/rndc-confgen
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "UWYjkfy/bHWRzzQBw2cjuQ==";
};

options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
# End of rndc.conf

# Use with the following in named.conf, adjusting the allow list as needed:
# key "rndc-key" {
# algorithm hmac-md5;
# secret "UWYjkfy/bHWRzzQBw2cjuQ==";
# };
#
# controls {
# inet 127.0.0.1 port 953
# allow { 127.0.0.1; } keys { "rndc-key"; };
# };
# End of named.conf

Vous remarquez que le résultat se décompose en deux parties: entre les lignes "# Start of rndc.conf" et "# End of rndc.conf" se trouve ce que vous devez mettre dans le fichier /etc/rndc.conf.

Et entre "# Use with the following in named.conf, adjusting the allow list as needed:" et la dernière ligne "# End of named.conf" se trouve ce que vous devrez placer dans le named.conf. Attention, il s'agit simplement de copié/collé dans le cas du rndc.conf mais vous devrez retirer les # en début de lignes pour la partie concernant le named.conf.

Haut

6. Comprendre le named.conf

Dans /etc créez le fichier named.conf à l'aide de votre éditeur préféré. La syntaxe du fichier de configuration est simple, sauf si vous lisez la "documentation" fournie avec Bind. J'insiste: oubliez cette documentation pour commencer, n'y retournez que lorsque vous aurez compris le principe de fonctionnement.

Le principe est le suivant: le fichier est décomposé en directives: par exemple la directive "options".

options {
directory "/var/named";
};

On met le nom de la directive suivie d'une ouverture d'accolade. Les lignes qui suivent contiennent tous les paramètres de cette directive. Chaque paramètre est suivi d'un ; pour indiquer qu'on passe à un autre paramètre. Lorsque tous les paramètres de la directive sont entrés, on crée une ligne avec fermeture de l'accolade et ;

Voyons maintenant quelques directives qui vont nous servir à bâtir notre named.conf :

La directive "options"

Elle définit des paramètres concernant le serveur de nom en général, par exemple pour définir le répertoire où se trouve le fichier de configuration. Voici ce que nous utiliserons pour le moment:

options {
directory "/var/named";
};

La directive "logging"

Par défaut, Bind ne log quasiment rien. Un choix parfaitement judicieux de la part des programmeurs de Bind puisque grâce à leur FORMIDABLE documentation, vous êtes quasiment sûr que cela ne marchera pas du premier coup. Si Bind logguait les problèmes par défaut cela risquerait d'aider au débuggage, ce qu'il faut A TOUT PRIX éviter. Bref, si vous souhaitez comprendre pourquoi ca ne marche pas, utilisez les lignes suivantes:

logging {
category "unmatched" { "null"; };
category "default" { "default_syslog"; "default_debug"; };
};

Vous disposerez ainsi d'informations dans /var/log/syslog (un tail -f /var/log/syslog durant les premiers lancements de Bind est lourdement recommandé pour comprendre ce qui plante). Il faut noter que Bind dispose de possibilités de logging avancées: si vous y entravez quelque chose, la documentation donne beaucoup d'informations à ce sujet.

Les directives "key" et "control"

Comme nous l'avons vu un peu plus haut, l'utilitaire rndc va générer pour vous toute cette partie du fichier named.conf. Copiez donc le résultat de votre commande rndc-confgen ici.

key "rndc-key" {
algorithm hmac-md5;
secret "UWYjkfy/bHWRzzQBw2cjuQ==";
};

controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};

Attention: Comme à chaque lancement de la commande rndc-confgen vous obtenez une clé différente, il est important de copiez les éléments obtenus lors du lancement qui vous a servi à créer le /etc/rndc.conf

La directive zone

C'est elle qui va vous permettre de définir les domaines que votre DNS va gérer. Voici un exemple:

zone "domaine.com" {
type master;
file "master/domaine.com";
};

Détaillons un peu ces quatre lignes:

zone "domaine.com" {
Ouverture de la directive concernant le domaine "domaine.com"
type master;
Le type "master" indique que votre serveur a autorité complète sur ce domaine.
file "master/domaine.com";
"file" précise dans quel fichier se trouvent les informations concernant domaine.com, ici dans /var/named/master/domaine.com. En fait, named.conf utilise le paramètre directory "/var/named" (que nous avons mis dans la directive "options" au début du fichier) comme préfixe et le paramètre file "master/domaine.com" de la directive "zone "domaine.com" pour composer le chemin complet du fichier domaine.com. Il faudra donc créer un sous-répertoire "master" dans /var/named et y placer le fichier domaine.com que nous allons créer plus tard.
};
fermeture de la directive zone "domaine.com"

La suite du named.conf sera composée d'autres directives zone, nous allons voir cela plus loin.

Haut

7. Lancer named

Nous l'avons déjà dit, rndc permet de contrôler named. Cependant il ne permet pas de lancer ce dernier. Le mieux pour cela est d'utiliser la commande "named", tout simplement. Une fois named lançé, vous pouvez contrôler qu'il tourne correctement avec la commande rndc status. Voici ce que cela peut donner:

# rndc status
number of zones: 3
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running

Pour lancer named au démarrage, vous pouvez fabriquer votre propre script de démarrage, mais un simple "named" dans le rc.local (sur Redhat/Mandrake) ou dans un script bash configuré avec update-rc.d (sur Debian) suffira, puisque ensuite rndc vous permettra de contrôler named.

Enfin, si vous avez besoin de relancer named à la hussarde (par exemple pour tester vos modifications) un bon "killall -HUP named" suffira.

Haut

8. Deux cas réels

Premier cas: un serveur DNS local servant de cache

Définissons le réseau sur lequel nous allons travailler: il s'agit d'un LAN de 3 machines relié à Internet par une connexion quasi-permanente (ADSL) sans IP fixe ni domaine public. Les IP internes sont du type 10.0.0.X. Le domaine est "sweethome.maison" (Il ne s'agit donc pas d'un domaine valable sur le NET mais peu importe puisque c'est juste pour le réseau interne.)

Nous souhaitons que le serveur DNS soit dans un premier temps capable de servir de DNS à notre LAN pour la navigation sur le WEB. Cela nous permettra de nous affranchir des DNS de notre FAI. Par ailleurs, nous désirons que notre DNS soit capable de résoudre les noms de nos machines en interne.

Voici ce que nous aurons dans /etc/named.conf

options {
directory "/var/named";
};


zone "0.0.127.in-addr.arpa" {
type master;
file "master/127.0.0";
};


zone "." {
type hint;
file "named.root";
};


zone "sweethome.maison" {
type master;
file "master/sweethome.maison";
};


zone "0.0.10.in-addr.arpa" {
type master;
file "master/10.0.0";
};

key "rndc-key" {
algorithm hmac-md5;
secret "UWYjkfy/bHWRzzQBw2cjuQ==";
};

controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};

Pas de panique, nous allons expliquer tout cela !

La directive "options" ne nous est pas inconnue, elle définit les caractéristiques globales de notre named.

Arrive ensuite la première directive zone: 0.0.127 Elle définit la loopback, la fameuse adresse 127.0.0.1. En fait, c'est une zone standard qu'on définit toujours et qui ne change pas.

La zone "." est plus intéressante. Le "." signifie "tout". Cela veut dire que pour tout domaine, notre named va aller chercher les informations dans cette directive. C'est cette directive qui va permettre de résoudre les domaines internet. Elle s'appuie sur le fichier zone /var/named/named.root que nous allons voir bientôt.

La zone "sweethome.maison" concerne le LAN. Elle est donc de type master et nous allons logiquement placer le fichier zone correspondant dans /var/named/master. C'est cette zone qui permettra au serveur DNS de fournir l'ip d'une machine en fonction de son nom.

Enfin, la zone "0.0.10.in-addr.arpa" correspond également au LAN mais permettra la recherche inverse, c'est à dire trouver le nom d'une machine du LAN par son IP.

Suivent ensuite les directives key et controls qui ont été générées par rndc-keygen comme nous l'avons vu plus tôt.

Passons maintenant aux fichiers de zone:

Toute zone définie dans notre /etc/named.conf doit avoir un fichier de zone correspondant dans /var/named. Reprenons donc chacune de nos directives "zone" et créons les.

127.0.0 (correspond à la directive zone "0.0.127.in-addr.arpa")

Comme nous l'avons vu, cette zone correspond à l'adresse loopback, identique sur tout ordinateur utilisant TCP/IP. Le fichier est donc lui aussi quasiment immuable. Le voici:

$TTL    3h

@               IN      SOA     localhost. root.localhost. (
                                1
                                3H
                                15M
                                1W
                                1D )
       	                        NS      localhost.
1                               PTR     localhost.

Examinons un peu tout cela:

Sur la première ligne, "$TTL 3h" indique le Time To Live, c'est à dire la durée de validité de l'information.

La seconde ligne commence par un "@" obligatoire qui désigne la zone décrite par le fichier de configuration 0.0.127. Deux tabulations plus loin nous avons "IN" qui veut dire qu'il s'agit de la zone Internet (c'est presque toujours cela). Une tabulation plus loin nous avons SOA (Start Of Authority), elle sert à donner des informations sur la gestion de la zone. Enfin, une tabulation plus tard, le serveur de nom qui possède le fichier de référence (en l'occurence, localhost signifie que c'est l'ordinateur lui même). Notez qu'il y a un "." à la fin du nom, il empêche Bind d'ajouter un suffixe au nom, il ne faut surtout pas l'oublier. Enfin root.localhost. signifie root@localhost (le "@" est exprimé par un "."): vous pouvez ici mettre l'adresse mail de votre choix. En fin de ligne nous ouvrons une parenthèse.

La seconde ligne comporte le numéro de série. Pour 127.0.0, on se contente de mettre "1". Les 4 lignes suivantes indiquent divers délais que je ne détaillerai pas ici: les valeurs proposées dans cet exemple sont acceptables. Notez quand même que nous fermons la parenthèse à la ligne 1D (qui signifie 1 jour).

Nous définissons ensuite le serveur de nom capable de résoudre le domaine localhost (qui est bien entendu la machine elle même).

Enfin la dernière ligne commence par 1, cela signifie que nous décrivons le nom de machine correspondant à 127.0.0.1, en l'occurence toujours localhost.

Jusque là ce n'est pas très passionnant car le fichier 127.0.0 ne permet pas vraiment grand chose: mais cela permet de bien saisir les bases pour comprendre la suite.

Internet (correspond à la directive zone ".")

Cette zone va permettre de résoudre tous les noms des domaines publics. Le fichier correspondant est /var/named/named.root. Ce n'est pas vous qui créez ce fichier. En effet il référence l'ensemble des serveurs de noms "primaires", ceux qui font la justice sur Internet. Il est plutôt simple à récupérer, il faut utiliser la commande dig en redirigeant sa sortie sur /var/named/named.root:

# dig @a.root-servers.net. > /var/named/named.root

Voilà vous disposez de votre fichier de zone named.root. Notez qu'il faudra le remettre à jour de temps en temps.

Le LAN coté nom de machines (zone "sweethome.maison")

Présentons un peu mieux ce fameux LAN: il est composé de 3 machines, une station de jeu appellée gaming (ip 10.0.0.1), un serveur qui fait office de passerelle sur le net, de serveur SMTP, de firewall et bientôt... DNS :-). Son IP interne est 10.0.0.2. Enfin une station de travail bureautique en 10.0.0.3. C'est dans cette zone que nous allons enfin pouvoir donner les noms de nos machines à Named. Le fichier correspondant est /var/named/master/sweethome.maison

$TTL    1D
@       IN      SOA  serveur.sweethome.maison. root.sweethome.maison (
                2002121101
                8H
                2H
                1W
                1D )

@	IN      NS   serveur.sweethome.maison.

gaming	IN      A    10.0.0.1
serveur	IN      A    10.0.0.2
travail IN      A    10.0.0.3
localhost IN      A   127.0.0.1

La syntaxe est identique à celle du fichier 127.0.0 je ne reviendrais donc pas dessus pour les premières lignes sauf pour le numéro de série. Par convention (sauf pour 127.0.0) les numéros de série sont basés sur la date, au format YYYYMMDD (année,mois,jour) suivi d'un nombre. A chaque modification de votre fichier, vous devez incrémenter ce numéro de série pour que la propagation se fasse correctement.

Passons directement aux lignes correspondants aux machines: elles commencent par le nom de la machine, tabulations, IN (internet), tabulations, et A (qui permet de donner une IP) suivi de l'IP.

En plus des noms de machines courants, nous avons ajouté localhost au cas où. Et nous comme il y a un serveur SMTP installé sur la machine serveur.sweethome.maison, nous avons ajouté une machine "smtp" (donc "smtp.sweethome.maison") qui pointe sur 10.0.0.2 (nous avons donc donné deux noms à la même machine ce qui ne pose pas de problème).

Le LAN mais du coté des IP (zone "0.0.10.in-addr.arpa")

Dernier fichier, il va permettre de trouver les noms de machine à partir d'une IP. Ce n'est pas le plus important sur un LAN mais puisqu'on est arrivé jusqu'ici, pourquoi pas, d'autant que ce n'est pas plus compliqué que le reste. Voici donc ce que nous allons avoir dans le fichier /var/named/master/10.0.0

$TTL	1D
@ IN	SOA	serveur.sweethome.maison.  root.sweethome.maison (
	2002121101
	8H
	2H
	1W
	1D )
@ IN	NS	serveur.sweethome.maison.

1 IN	PTR	gaming.sweethome.maison.
2 IN	PTR	serveur.sweethome.maison.
3 IN	PTR	travail.sweethome.maison.

Comme pour le fichier 127.0.0, vous remarquez le champ PTR (Pointer to Other Name) qui définit a quel nom une ip correspond. Notons au passage que nous n'avons pas renseigné le fichier au sujet du nom smtp.sweethome.maison qui est le second nom de serveur.sweethome.maison

C'est terminé pour les fichiers de configuration...

Pour finir, il faut contrôler la configuration à l'aide de la commande checkconf: (/usr/local/sbin/named-checkconf). Cette dernière ne doit pas renvoyer d'erreur. Si elle affiche quelque chose, vérifiez attentivement la syntaxe de votre named.conf.

Contrôlez également la syntaxe de chaque fichier de zone avec la commande checkzone (/usr/local/sbin/named-checkzone) que vous utiliserez ainsi:

# named-checkzone 127.0.0 /var/named/master/127.0.0
zone 127.0.0/IN: loaded serial 1
OK

Répétez l'opération pour chaque fichier de zone. Si vous n'obtenez pas d'erreur, lancez named et vous allez pouvoir procéder à quelques tests (les tests sont abordés dans la rubrique troubleshooting).

Deuxième cas: un DNS publique maître d'un domaine

Prenons le cas d'un serveur web avec IP publique fixe. Nous souhaitons que notre DNS soit public, nous permettant ainsi de gérer notre domaine Internet et de le mettre à jour quand nous le souhaitons sans passer par notre Registrar lorsque nous effectuons des modifications ou si nous mettons en place un service de mail sur la machine par exemple.

Cette configuration est aussi intéressante mais engage plus de responsabilités: en effet notre DNS sera public, il faut donc qu'il fonctionne proprement. Je vous invite à consulter le paragraphe sur la sécurité avant de laisser tourner un serveur de ce type.

Par ailleurs, pour que cet exemple soit applicable dans la vraie vie, il faut que votre registrar (celui chez qui vous avez enregistré votre nom de domaine) modifie le pointage du DNS: en effet le DNS principal de votre nom de domaine sera désormais l'ip fixe de votre serveur DNS.

Notre domaine pour cet exemple sera dacrepe.com (fictif!)

Le fichier /etc/named.conf

options {
directory "/var/named";
};

logging {
category "unmatched" { "null"; };
category "default" { "default_syslog"; "default_debug"; };
};


zone "." {
type hint;
file "named.root";
};

zone "0.0.127.in-addr.arpa" {
type master;
file "master/127.0.0";
};

zone "dacrepe.com" {
type master;
file "master/dacrepe.com";
};

key "rndc-key" {
algorithm hmac-md5;
secret "zQPQd5oyhUORVcARZx6Ajw==";
};

controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};

Rien de surprenant au niveau des options...

Viennent ensuite les paramètres de logging, eux aussi déjà vus.

Enfin les zones qui ne sont pas elles non plus franchement étonnantes:

la zone "."
pour que notre DNS soit un vrai DNS qui sait tout résoudre: cela permettra de l'utiliser en interne également.
La zone "0.0.127.in-addr.arpa"
pour le loopback
La zone "dacrepe.com"
elle contient ce qui nous intéresse le plus, notre REDOUTABLE domaine.
Les directives key et controls
pour rndc

Tout va donc de soi et vous pouvez vous reporter au premier cas pour l'ensemble des fichiers de zone à l'exception de dacrepe.com que nous allons maintenant voir en détail...

Le fichier /var/named/master/dacrepe.com

Attention: Toutes les informations dans cet exemple sont fictives, n'allez pas fourrer ces données brutes dans votre bind public! Adaptez les à votre configuration!

$TTL    3h
@               IN        SOA      dacrepe.com. root.dacrepe.com. (
                                   2002121101
                                   8h        
                                   2h        
                                   1w        
                                   3h)
                          NS       	dacrepe.com.
                          MX       	10 mail.dacrepe.com.
                          MX       	20 mail2.dacrepe.com.
localhost  		A        	127.0.0.1
www		  	A        	162.123.238.34
dacrepe.com.  		A        	205.201.102.22
mail		  	A        	205.201.102.22
mail2		  	A		205.201.102.23

Tout le début du fichier devrait vous être familier...

Les deux lignes MX

MX signifie qu'il s'agit du serveur de mail de ce domaine. La première ligne MX indique que quand on écrit à "toto@dacrepe.com" le mail ira à la machine "mail.dacrepe.com" (qui ici se trouve être également notre serveur DNS).

Mais vous avez pu remarquer le 10 devant le nom de la machine. Il indique la préférence MX. Cela signifie qu'on enverra en priorité le mail a cette machine par rapport à un serveur MX ayant une préférence supérieure à 10.

Par contre, si le serveur mail.dacrepe.com est indisponible, le mail ira vers le serveur ayant la préférence supérieure a 10. En l'occurence, nous avons précisé un second serveur de mail avec une préférence 20.

Le serveur "mail2.dacrepe.com" ne sera donc utilisé que si "mail.dacrepe.com" est indisponible.

Le champ localhost

Vous connaissez bien ce champ, nous n'y reviendrons pas.

La ligne www

La machine "www" (Bind la transforme en "www.dacrepe.com") est un serveur web. Ce dernier est sur une classe d'IP complètement différente, probablement hébergé ailleurs que sur le LAN.

dacrepe.com

Arrive enfin une ligne un peu bizarre: dacrepe.com. (avec le "." à la fin). Cette ligne permet à notre DNS de pouvoir répondre si on cherche à joindre le domaine "dacrepe.com" tout court. Il est redirigé sur notre DNS/Mailer.

Les serveurs de mail

Pour finir mail et mail2 qui deviennent "mail.dacrepe.com" et "mail2.dacrepe.com", nos deux serveurs de mail.

Pour être vraiment complet, il faudrait également ajouter une zone dans le named.conf pour gérer le reverse, mais ca ne devrait pas vous poser trop de problèmes si vous relisez le premier cas.

Comme nous l'avons déjà fait pour le premier cas justement, il va falloir tester sérieusement votre configuration... Nous allons aborder le troubleshooting maintenant.

Haut

9. Troubleshooting

Voyons maintenant comment diagnostiquer les problèmes

named-checkconf et named-checkzone

En lançant /usr/local/bin/checkconf, vous effectuez un contrôle de la syntaxe de /etc/named.conf et de différents paramètres. C'est la première chose à faire avant de lancer named après avoir modifié quelque chose, à fortiori lors du premier lancement.

/usr/local/bin/named-checkzone lui va vérifier plus spécifiquement la validité des fichiers de zone. On l'utilise ainsi:

named-checkzone nom-de-la-zone chemin-du-fichier-zone/nom-du-fichier-zone

Par exemple, pour le fichier de zone /var/named/master/127.0.0 on aura:

named-checkzone 127.0.0 /var/named/master/127.0.0

Ces deux utilitaires sont particulièrement utiles pour traquer les erreurs de syntaxe dans vos fichiers de configuration.

Les logs de named

Nous avons déjà vu comment demander à named de logguer dans /var/log/syslog. Lorsqu'on veut comprendre ce que fait named lors de son démarrage et éventuellement pourquoi il ne démarre pas ou ne fonctionne pas proprement, on peut faire un tail -f /var/log/syslog dans une console: en général les messages d'erreur sont assez parlant.

Pour rappel, voici les lignes à ajouter dans votre /etc/named.cf pour disposer de logs:

logging {
category "unmatched" { "null"; };
category "default" { "default_syslog"; "default_debug"; };
};

Utiliser dig

Il paraît que "nslookup is deprecated". Soit, utilisons dig. Admettons que votre named se lance et tourne correctement, il est important de vérifier que notre configuration est satisfaisante.

La commande suivante va interroger le DNS qui tourne sur votre machine et lui demander si il connaît la machine gaming.sweethome.maison

dig @127.0.0.1 gaming.sweethome.maison

Si votre réseau est sweethome.maison et que vous disposez d'une machine "gaming" dessus (c'était l'exemple de notre premier cas de configuration réelle) il doit vous renvoyer son IP (10.0.0.1)

La commande dig @127.0.0.1 10.0.0.1 doit vous renvoyer le nom de la machine gaming.

De même vérifiez que le serveur DNS est capable de résoudre les noms sur internet.

Enfin, dans le cas où votre serveur est public, vérifiez scrupuleusement chaque cas de figure concernant vos machines publiques. Si vous aviez jusqu'ici un pointage sur les serveurs DNS d'un registrar, n'hésitez pas à ouvrir un second terminal pour faire les requêtes dig sur le DNS de ce dernier en effectuant les mêmes sur votre serveur DNS. Les résultats doivent être identiques. C'est méthode est redoutable pour le débuggage.

Haut

10. Sécurité

Cacher le numéro de version

$ nslookup

> set class=chaos
> set q=txt
> version.bind
Server: localhost
Address: 127.0.0.1

VERSION.BIND text = "9.2.1"

CAI MAL !!!! On peut cacher le numéro de version avec le paramètre "version" dans la directive "options". Ca nous donne quelque chose comme cela:

options {
directory "/var/named";
version "Non disponible";
};

Désormais, le numéro de version affiché sera: "Non disponible".

Protéger la clé cryptée

Les fichiers /etc/rndc.conf et /etc/named.conf contiennent tous les deux la clé, il faut donc empêcher sa lecture par le tout venant. Un petit chmod 640 devrait faire l'affaire:

# chmod 640 named.conf rndc.conf
# ls -l named.conf rndc.conf
-rw-r----- 1 root root 563 Dec 11 03:35 named.conf
-rw-r----- 1 root root 479 Dec 11 01:44 rndc.conf

Named sans les droits root

Imaginons une attaque type DoS contre votre serveur DNS: le pirate récupère un shell disposant des droits de celui qui a lancé named. Or, jusqu'à preuve du contraire, c'est root ce qui est vraiment très dangereux. Il faudrait pouvoir lancer named sous une autre identité mais c'est impossible car ce dernier doit pouvoir ouvrir un socket sur un port inferieur à 1024, ce qui est interdit à tout le monde sauf à root. La solution est de lancer named en root puis de le faire passer en utilisateur dès que le port sera sous écoute. C'est possible graçe à l'option -u. On peut suivre par exemple la procédure suivante:

  • Créer un utilisateur named sans shell (/bin/false)
  • Créer un sous-répertoire /var/named/pid appartenant à l'utilisateur named
  • Ajouter la ligne suivante à /var/named.conf dans la directive options: directory "/var/named";
  • Lancer désormais named avec la commande named -u named

Attention: avec cette configuration, "killall -HUP named" ne marchera plus: il faudra passer par un "killall named && named -a idd" pour le relancer.

Comme toujours avec la sécurité, on a jamais fini. Il est possible de chrooter named par exemple. De même, certaines directives peuvent être travaillées pour filtrer quelles requêtes sont autorisées ou non. Consultez les liens utiles à la fin de ce tutoriel pour trouver plus d'informations à ce sujet.

Haut

11. Liens utiles

Haut

Une question ? Une remarque ou une correction à faire ? Postez sur le forum (sans inscription obligatoire).